Raising the bar for introducing new syntax

[SheepKey]

The guideline should be “perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.”

I largely agree with this sentiment. This is also why I am particularly opposed to changes like impl Trait in argument position.

We now have 3 syntaxes to do exactly the same thing:

fn my_func(x: impl MyTrait)

fn my_func<T: MyTrait>(x: T)

fn my_func<T>(x: T)
    where T: MyTrait

This feels incredibly redundant. It is useless complexity in the language. Beginners have to learn multiple ways of doing the same thing.

I personally find the where syntax to be the best. It allows expressing trait bounds of arbitrary complexity without cluttering up the function signature. They are not sprinkled all over the argument list of the function, but rather clearly grouped and listed afterwards. It also has the highest level of flexibility; both of the other syntaxes have practical limitations that the where syntax does not.

Even for a single type parameter (as in the example above), I think it looks very clean and elegant. I think it is the most readable of the three.

I think all the other syntaxes are redundant and useless and should be removed (not possible due to stability guarantees).

I personally use it universally throughout my code, because I believe it is the right thing to do. I do not use the other syntaxes, since they are semantically equivalent, but either less readable (inline trait bounds at the definition of the type parameter) or have other limitations (impl Trait).

Of course, it requires a little more typing. However, most of the software development time is spent thinking, not typing. Also, it is far more important for code to be easier and clearer to read, than to be quick to write. I am personally very much against this whole idea of “shaving characters”. Introducing any language changes purely because you are too lazy to type a few extra characters is a bad decision IMO.

This might seem a little hypocritical at first glance, since I love the ? operator syntax. However, the main benefit that I see is not the fact that it is a single character, but rather that it makes code clearer and more readable (being a postfix operator, as opposed to try!) with no downsides. Hence, it goes along well with my philosophy that I outlined previously and is not hypocritical.

[gbutler]

Also, it is far more important for code to be easier and clearer to read, than to be quick to write.

Number 1 criteria if you ask me. I couldn’t agree more.

[rpjohnst]

I personally find the where syntax to be the best.

I also prefer where syntax. In fact, I would not be entirely opposed to removing (edit: as in deprecating) the <T> part of that syntax entirely, along the lines of in-band lifetimes. This tends to work well in other polymorphism-heavy languages. And though of course there would be obstacles around Rust’s particular design, just as with in-band lifetimes, it would de-clutter function signatures without adding a new syntactic form with its own limitations.

[Latrasis]

The guideline should be “perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.”

I was wondering, is there any discussion in terms of establishing a policy of trimming features down the road? Similar to editions?

To elaborate: is there any discussion on what steps must be taken when the community wishes to deprecate a feature in stable? Akin to a Negative RFC?

[CAD97]

It is possible to lint against certain syntactic forms, and after an edition gate, forbid them.

However, the compiler has to support previous editions, so no compiler complexity gains are gained by removing a syntactic form in later editions, and the compiler would want to still parse it and recommend the proper form anyway.

I think the way to go about soft deprecating syntactic forms would be rustfmt rewriting to the preferred form and/or rustfix-able clippy lints. Potentially after consensus has been proven in one of those two avenues, the lint could graduate to the compiler, but I doubt there’ll be any benefit to removing syntactic forms in future editions.

Hiding deprecated stdlib functions might happen, though.

[Centril]

I personally find the where syntax to be the best. It allows expressing trait bounds of arbitrary complexity without cluttering up the function signature

This depends on what you see as important; I find that some trait bounds are essential to the semantics of a particular piece of code. The Rust syntax is a bit more verbose… But the Haskell version is quite neat:

sort :: Ord a => [a] -> [a]

From the signature alone (even without the function name), it is quite easy to tell what this function does, so it makes sense to me that Ord a is front and center. I think the where syntax should be reserved for when you have other bounds that are less important.

It also has the highest level of flexibility; both of the other syntaxes have practical limitations that the where syntax does not.

The limitations of the <T: Foo, ..> syntax are as far as I know not fundamental and can all be eliminated.

In fact, I would not be entirely opposed to removing the <T> part of that syntax entirely, along the lines of in-band lifetimes.

We can’t just go about removing the <T: Bound> syntax; It is used incredibly often and removing it would break a tonne of code. Not to mention that there isn’t universal support that where is better in all cases.

Besides… we just introduced impl Trait in argument position; I find it unlikely that we’d undo this move.

[Ixrec]

To elaborate: is there any discussion on what steps must be taken when the community wishes to deprecate a feature in stable? Akin to a Negative RFC?

There’s no special policy of RFC flavor required for this. The dyn Trait RFC is essentially an example of deprecating stable syntax in favor of a supposedly better new syntax.

The big debate over what exactly “editions” should and should not allow happened in parallel with the dyn Trait RFC, and the community arrived at more or less the conclusion @CAD97 accurately summarized:

It is possible to lint against certain syntactic forms, and after an edition gate, forbid them.

[SheepKey]

Yeah, it would be great if all of this stuff is deprecated (with sufficient advance notice) and replaced with a single uniform syntax in a future Edition.

[SheepKey]

The limitations of the <T: Foo, ..> syntax are as far as I know not fundamental and can all be eliminated.

Yes, the technical limitations can be eliminated.

However, my problem is with readability. It only looks nice in simple cases, like 1-2 type parameters with maybe 1-2 trait bounds. Anything more complex than that will really clutter the function signature and looks unreadable. That is a practical, not technical, limitation, which is solved by the where syntax. Also, arguably, since the impl Trait syntax was introduced precisely to cover these simple cases … is the <T: Foo, ...> syntax even necessary at all (assuming limitations like not being able to turbofish with impl Trait are lifted in the future)? It feels redundant. Need something simple and upfront and center? Use impl Trait. Need something more complex? Use where.

Besides… we just introduced impl Trait in argument position; I find it unlikely that we’d undo this move.

Yeah. I wish it wasn’t stabilized, but it’s too late for that now. Might as well live with it and make the best of it.

your Haskell Ord example

Yes, I can see how in these simple cases, a simple syntax that puts the trait bound upfront and visible is a good thing. As much as I love to hate on impl Trait in argument position, it accomplishes that perfectly. The trait bound in these simple cases is exactly where it is supposed to be: in the most upfront and center position, with the argument that uses it. If anything, as I said previously, it is the old <T: Foo, ...> syntax that feels redundant now. If you need something more complex than impl Trait, use where.

[Centril]

Anything more complex than that will really clutter the function signature and looks unreadable

It’s exactly those cases I’m talking about where you have 1-2 important type parameters and bounds; in that sort of situation, <T: Foo, ..> fits really well and highlights what is important and not. You can even use <T: Foo, ..> and where .. together to showcase the important bounds and “hide” the less important ones in the where-clause.

Also, arguably, since the impl Trait syntax was introduced precisely to cover these simple cases …

As soon as you need to repeat the same type variable, impl Trait becomes useless. To fix this, you’d need some sort of typeof(argument) construct; which, to me, is less readable. It is pretty common to have two arguments using the same type variable I’d say (think anything resembling a generic binary operator). So impl Trait + where doesn’t cut it for me.

[SheepKey]

Yeah, OK, thank you for explaining your view.

I think this discussion also helped me clarify in my head why exactly we have these syntaxes in the first place and how they are intended to be used.

I might adjust my coding style

[ExpHP]

Oddly enough, I put important bounds in where and reserve the <T: Trait> syntax almost exclusively for trivialities like T: ?Sized or bounds that come from the struct definition. Why? Because generic parameter lists mix two different kinds of information (making them harder to read), and can’t even hold all the important bounds.

Or I try at least. Sometimes I throw consistency into the wind and inline a where bound because it is “short” and there is only one type parameter, meaning it’s not unreadable.

[twmb]

Besides… we just introduced impl Trait in argument position; I find it unlikely that we’d undo this move.

What was the reason it was introduced again? I vaguely remember detractors essentially saying “why?” and proponents saying “to cover the bases of the possible ways people may want to do this”.

[Ixrec]

The RFC that included the argument position change argues for it in this subsection: https://github.com/rust-lang/rfcs/blob/master/text/1951-expand-impl-trait.md#motivation-for-expanding-to-argument-position

[Centril]

Oddly enough, I put important bounds in where and reserve the <T: Trait> syntax almost exclusively for trivialities like T: ?Sized or bounds that come from the struct definition.

Well; to each their own

[iopq]

Structs by definition don’t have a set order. In fact, I would argue their canonical order should be alphabetical, not in the order of declaration.

I even proposed unnamed structs along this line of thinking with an implementation-defined layout.

[iopq]

This is why I don’t like calling functions with more than one argument of the same type. Multiple arguments of the same type add potential mistakes. I’d rather newtype everything.

[SheepKey]

In terms of the low-level / in-memory layout, Rust structs are already unspecified / implementation-defined. The Rust compiler is allowed to reorder the fields of your struct in memory in order to make them more compact or to optimize performance. If you need a strictly-defined layout for your structs, you have to annotate them #[repr(C)]. If you annotate your struct, because you care about the layout, then you clearly need to have full control over it, so alphabetical ordering would be useless. You would use order of declaration to specify your desired memory layout, so it matters.

In terms of source code, Rust already does not force any order onto you. You can specify the fields of your struct in any order you want when constructing them.

struct MyStuff {
    b: i32,
    a: f32,
}

impl MyStuff {
    fn new() -> MyStuff {
        MyStuff { a: 0.0, b: 0 }
    }
}

^ this is already valid Rust code

[iopq]

Yes, I actually proposed structural structs so you don’t have to define them. That way they are easy to pass between crates (since you don’t have to import definitions from another crate)

[system]

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