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

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