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

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?

Line-item veto.

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...

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

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".

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.

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.

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.

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".

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

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.

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.

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>) { .. }.

6 Likes

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

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?

3 Likes

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.

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.

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.

1 Like

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.

1 Like

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));
8 Likes

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