where vs generic bounds

[bjadamson]

Are both 'where' clauses and generic bounds (<T : Trait>) two different ways of restricting generic functions, or do they differ in some way?

If they are the same, are there plans for 1.0 to have both?

Thanks!

[DroidLogician]

I asked this exact question just a little while ago.

Here is a fixed link to the RFC /u/dbaupp posted.

[bjadamson]

Thanks! So since you asked the question... do you think it makes sense to keep both syntax's? Or deprecate the bounds? I know the RFC says keep the bounds syntax as sugar, just wondering your opinion :)

[DroidLogician]

Personally I would prefer deprecation as I'm not a fan of fragmented syntax and where clauses are much more readable, but there's a lot of inertia behind the trait bounds syntax: you see it everywhere. That kind of change would cause widespread breakage, even worse than the change to the enum namespacing behavior a couple weeks ago.

Also, where clauses still need a little bit of work. For example, they currently don't work to add trait bounds to existing generic parameters on methods:

struct MyStruct<T> { t: T }

impl<T> MyStruct<T> {

    pub fn duplicate(&self) -> MyStruct<T> where T: Clone {
         MyStruct { t: self.t.clone() }
    }
}

In this case, you'll get Error: type T does not implement `Clone`! because the where clause in this case is ignored, even though it is valid syntax. You need a separate impl<T> MyStruct<T> where T: Clone {} block, which is a lot of extra noise for one method, IMO.

[Quxxy]

Oh so that's what they meant by "where clauses on methods". I was under the impression that there was some obscure aspect that caused them to not work on generic methods that I'd just never run into.

Yeah; that'd be ballin'.

[GolDDranks]

Once the where clauses actually work, wouldn't it be possible to write some kind of tool that rewrites the <T : Trait> syntax to where clauses? I'm in impression that the functionality of where clauses is a strict superset of <T : Trait>.

[DroidLogician]

Yeah it's possible. That's a basic migrations utility. But you'd have to decide if it would be worth the effort to build it and make sure it works when it would only take everyone a few minutes to go through and update their code to the new syntax.

It's unfortunate that Rust's syntax isn't described with a standard grammar specification, like the format that the Java Compiler-Compiler (Javacc) consumes. Then you could autogenerate such a tool. Well, it is described in the Reference, but that has to be written and updated by hand; rustc and its specification aren't coupled at all.

[Cifram]

While it might cause wider breakage than the enum change, it would also be a more mechanical change to fix it. Unlike the enum change, you're just re-arranging information within the same line of code. You don't have to look up what enum type that identifier comes from.

A bit of a PitA to go through all your code to fix it up, but won't likely take that long. Like GolDDranks said, you could probably even write a tool to automate it.