Don't keep complicating the syntax (soft post, maybe off topic, maybe irrelevant)

[Ixrec]

I’m also not really following the argument here. I feel like some of these comments are implying that just reading the titles of RFCs in TWiR should be enough to tell you if there’s something in the RFCs you might want to object to, which seems wildly unrealistic. If you actually read or even just skim the impl Trait RFC (well, the recent one that got stabilized) you can’t really miss the argument position thing. Likewise, if you skim/read the type ascription one, you can’t really miss that it affects function signatures. And if you want to not be surprised by Rust language changes, skimming accepted RFCs feels like the bare minimum to me.

[Centril]

Symmetry isn’t always good, or else we’d all be programming with SK combinators. We don’t do that as a concession that too much generality, applied too broadly, eventually hits a point of diminishing returns. (If we were using SK combinators, we may as well be writing code in binary.)

Granted, we don’t want to write in SKI / STLC (not because the symmetry is bad, but because they are useless languages – for practical general purpose work – that don’t offer enough abstractions or communication with the outside world), but that does not mean that various “subcomponents” of a system/language shouldn’t be internally consistent or compose well.

Functions being the core abstraction offered by Rust, they are a great place to break symmetry and do things differently.

I don’t agree. It makes the language less ergonomic, more surprising, encourages longer function definitions (less readability imo), keeps redundant information, and it is inconsistent with the grammar in closures.

[phaylon]

I think the discussion is relevant to this thread because it gets to what constitutes “complicating the syntax”… I’m arguing that syntax is simplified by a large amount and that extraneous concepts are removed from the language; but you don’t seem to agree?

If you follow the thread, it started with @kornel mentioning ? as a counter example. I objected that ? semantics had a very long trial period with try!, and the main concern was lower control flow visibility.

I then contrasted that with impl Trait and the type ascription change to function signatures, which aren’t widely known, and can only be tested on nightly. Those don’t have trial runs on stable, and are far removed from how ? came to be.

The problem is that “surprising” is in the eye of the beholder; what is surprising to you is just a natural conclusion / bug-fix to me.

So? We’re still at the point of “some things might be worth specifically calling out to the community”. Criteria can be established afterwards if there’s agreement that that is true. Language team members could just get in the habit of posting to internals or the subreddit to gather more eyeballs if they think something might surprise people, for example.

But to repeat, I’m just at the point of pointing out that it might be useful.

Uniformity with what? There’s nothing to be uniform with… The only place where you must write pat: type is in formal function parameters, nowhere else (to my knowledge). The cited RFC is what makes the situation uniform…

Uniformity with each other.

I’m not too bothered by it. I can simply avoid using that one, since it’s not an invisible feature. I just used it as an example of something that might be a surprising aspect.

[phaylon]

And if you want to not be surprised by Rust language changes, skimming accepted RFCs feels like the bare minimum to me.

Then why were people surprised by impl Trait in argument position? The whole impl Trait story is spread wide, since in return position in traits is something everyone wanted. Why did the argument position aspect never make it to those discussions?

[Ixrec]

If we really want to dig into the impl Trait example more, it’s important to point out that “argument position impl Trait” is not at all unique in its surprise. For example, I’ve seen a lot of people on other forums react to news about (return position) impl Trait with “can’t we already do this with generics?” or “can’t we already do this with trait objects?”, both of which make it pretty clear they simply never read even the most basic description of what the motivation or functionality of the feature is. Which I don’t mean as an insult; the reality is most people don’t have time to keep up with all these design discussions, so most new features are at least a little surprising to them. Most of those posts were appropriately answered with 2-3 sentence explanations of what makes impl Trait usefully different, but those of course didn’t go into detail about argument position vs return position and all the alternate syntax suggestions and so on.

[scottmcm]

My point here was that the more controversial and/or surprising parts of an RFC could use more publicity.

I don’t think that’s actionable. What are authors supposed to do, post places saying “My RFC in controversial”?

Anyone with strong opinions is encouraged to write blog posts or RFCs of their own, which will also get publicity in TWiR.

[phaylon]

I don’t think that’s actionable. What are authors supposed to do, post places saying “My RFC in controversial”?

Anyone with strong opinions is encouraged to write blog posts or RFCs of their own, which will also get publicity in TWiR.

Like I said above, if someone on the language team things some things could be surprising or have unexplored problem space, post them to internals or the subreddit. Maybe there’s relevant examples pro or against in the wild.

I want to point out that I responded to

Speaking as a member of the language team: this is emphatically not our approach. There is always a default presumption of not changing the language, and that holds especially true for new syntax. We think heavily about the teachability of the language, about the total complexity budget and “divergence from anything people have seen before” budget, and about the cost of new features.

in saying that I think more exposure can help with that. And again, this is all in the context of contrast with the amount of scrutinity ? was able to get.

[Ixrec]

Speaking of ?, I never read the original ? RFC back when ? was added to the language, and later on I was shocked to learn that try {} blocks were part of that RFC and had already been accepted into the language, even though they seemed very undermotivated to me (and as it turns out, quite a few other people on later RFC threads).

I’m not sure there’s any specific actionable lesson to draw from this. After all, I don’t want us to start stabilizing half-features just because we’re worried about public reaction to the second half. My point is that the general implication here that the way ? was added to the language is somehow more responsible than the way impl Trait was added just doesn’t seem true to me. All the problems being pointed out seem very real, but also inevitable and not new.

I feel like I should probably make some kind of constructive suggestion at this point, but I’m struggling to come up with anything we aren’t already doing. TWiR is as thorough as it can get; there’s no point asking TWiR to summarize the RFCs’ content because every RFC already comes with a summary. There was a Help test impl Trait! thread all the way back in January, which even includes argument position usage in the opening post’s example. So… I’m out of ideas.

---

To me, this whole thing feels to me like a symptom of the trust erosion caused by (among other things) the bizarre ergonomics RFC crunch time we had last year, rather than an actual downward trend in Rust design quality. Do we need to talk more about that?

[notriddle]

Just to be clear, what you’re describing is called a rider in traditional politics-speech. What kinds of solutions have been proposed for other governments to try to reduce them?

[skysch]

Line-item veto.

[Centril]

I then contrasted that with impl Trait

To be clear, impl Trait in argument position had its own RFC and wasn’t mixed with the return position one and later on there were a lot of discussions on the tracking issue…

RFC: Finalize syntax and parameter scoping for `impl Trait`, while expanding it to arguments

the type ascription change to function signatures, which aren’t widely known, and can only be tested on nightly.

Most likely because the RFC is still in the PFCP stage so that’s not very surprising.

Those don’t have trial runs on stable, and are far removed from how ? came to be.

I’m not sure anything can be done about that or I would be interested to know about your solutions… but we do have multiple steps before a change goes from RFC to being in the stable compiler and thus part of the “spec”.

Criteria can be established afterwards if there’s agreement that that is true.

But usually there isn’t agreement? that seems to be the problem… and TWiR editors shouldn’t try to editorialize to find out what the controversial bits are either cause that puts them in an awkward spot.

Language team members could just get in the habit of posting to internals or the subreddit to gather more eyeballs if they think something might surprise people, for example.

I mean… we do do this from time to time; I think especially @aturon and @withoutboats have been incredibly careful to make sure that we follow “no new rationale” and that we publically discuss modules and such on internals. I must say however that I don’t always find the subreddit the most friendliest of places and I know people from other teams agree.

Uniformity with each other.

That seems… like a very limited uniformity? -> impl Trait is also uniform with itself, – what’s the value of that? I think uniformity here would be to uniformly have static/const X: impl Trait = ... and type Foo = impl Trait; and so on.

[phaylon]

``

To be clear, impl Trait in argument position had its own RFC and wasn’t mixed with the return position one and later on there were a lot of discussions on the tracking issue…

But, if we look at the TWIR issues 174, 180 and 181 we see that it was run as simply "Expand and stabilize impl Trait".

But usually there isn’t agreement?

I mean once there is agreement that it makes sense for some discussions to be published more widely.

That seems… like a very limited uniformity? -> impl Trait is also uniform with itself, – what’s the value of that? I think uniformity here would be to uniformly have static/const X: impl Trait = ... and type Foo = impl Trait; and so on.

A function signature has only one return type, but it can have multiple arguments. I like the arguments in the signature to look uniform. The first argument with the next and so on.

[Centril]

But, if we look at the TWIR issues 174, 180 and 181 we see that it was run as simply "Expand and stabilize impl Trait ".

Yes, because it was a package deal.

Line-item vetoes were mentioned, but I hope no one is suggesting that we have those because that would quite seriously negatively impact my ability to ensure the consistency of the language and to prevent too ad-hoc things from happening.

Remember that when a parliament is voting through a national budget, people usually don’t get to veto out certain bits and pieces because that could lead to the taxes being removed and the spending being kept.

A function signature has only one return type, but it can have multiple arguments. I like the arguments in the signature to look uniform. The first argument with the next and so on.

Function arguments already allow you to have a pattern in there (so idk if there’s so much uniformity), for example, you can already write fn foo(Wrapping(x): Wrapping<u8>) { .. }.

[phaylon]

Yes, because it was a package deal.

But the title didn’t really invite a closer look.

Function arguments already allow you to have a pattern in there (so idk if there’s so much uniformity), for example, you can already write fn foo(Wrapping(x): Wrapping<u8>) { .. } .

I’m quite aware of that. I have no idea where you’re now going with this.

Like I said above, I’m not really interested in joining that design discussion. There’s a reason I stopped participating in the RFC PRs and it’s because of exactly this forever merry-go-round where you don’t stop. I simply like if arguments look like pattern: Type instead of just pattern. I find it more readable. Can we please, just for once, leave it at that?

[phaylon]

My point is that the general implication here that the way ? was added to the language is somehow more responsible than the way impl Trait was added just doesn’t seem true to me. All the problems being pointed out seem very real, but also inevitable and not new.

Note that I didn’t actually make that point. My point was simply that ? is a bad example for new syntax that turns out great, due to historical reasons of how it came about.

[OZ_]

I can’t remember any syntax complication. Example would be interesting. Speaking of ? - I don’t like and I just don’t use it. But it’s pretty simple to read and understand.

[Fiedzia]

Regarding pure syntax sugar, I think the solution would be to have compile-to-rust languages a’la CoffeeScript to experiment with the additions.

Those are called “macros” and work a lot better for this role comparing to completely separate language. The usecase for some “rustscript” may exist, but macros limit it significantly.

As for C++ - the problem with it is not that it adds a lot of things, but that it never removes them. I hope that the concept of epochs will allow Rust to be different in this aspect and clean up some garbage eventually.

[spease]

Just popping in to +1 the original post.

I find even little subtle things matter in my subjective feeling of how ‘hard’ it is to program in a language. eg underscores vs dashes, :: vs dot, having to specify a trait and argument types instead of just remembering the function name, etc.

A lot of the stuff I’ve written in Rust isn’t necessarily more conceptually complex than the Python equivalent, but sometimes the syntax makes it look a lot harder, which can be deceptive when I try to show it off. And sometimes there’s extra boilerplate which is only useful in a small number of cases (certain associated types on traits for the error value).

The comparison here is a bit unfair as Rust intentionally more explicit than other languages. But I suspect there’s significant syntax fat that’s rarely necessary to understand the programmer intent but alienates a lot of newbies.

It would be interesting to see something that kept the performance and type-safety but sacrificed a little flexibility to simplify the grammar/syntax. Perhaps that’s what was talked about earlier about compiling stuff to Rust. But I’d also hate to split the language.

[burjui]

As a side note, patterns in function parameters are great for passing flags as opposed to opaque bare bool:

    struct Warnings(bool);
    fn compile(code: ..., Warnings(warnings_enabled): Warnings);
    ...
    compile(code, Warnings(true));

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.