Whitespace dependency is painful in the long term. This looks nice, the only downside is that changing between one and two traits requires editing in two places.. Perhaps if parens were merely optional with one trait and <T:(Eq)> was valid this would be mitigated somewhat.
On 11 January 2013 18:50, Niko Matsakis <[email protected]> wrote: > Hi, > > Right now we use no delimiter at all to separate multiple trait bounds for > a single type variable: > > fn foo<T: Ord Eq Hash>(...) {...} > > Originally we thought to use commas, but inserting commas into the list > creates an ambiguity between the comma that separates type parameters, as > illustrated here: > > fn foo<T: Ord, Eq, Hash, U: Hash, V>(...) {...} > > Marijn and I hashed through all kinds of delimeters and failed to find > one, and hence he settled on spaces. It seemed like a good idea at the time. > > However, over time, I have found that this syntax is very hard for me to > parse, visually speaking. Moreover, Patrick recently observed that there is > an ambiguity when the trait names are multi-component paths: > > fn foo<T: Ord ::Eq>(...) {...} > > Does this indicate one bound `Ord::Eq` or two bounds `Ord` and `::Eq`? The > current fix for this is to make the tokenizer treat `id::` differently from > `id ::` (note the separating space in the latter example). The first is 1 > token. The second is 2 tokens. Actually, I think this behavior already > existed, and I can't remember why—I think it had something to do with the > flexible treatment of keywords that we used to have. @brson, do you > remember? > > Anyway, it was proposed on IRC today that we could do something like this > instead: > > fn foo<T:Eq>(..) {...} // One bound is the same > fn foo<T:(Ord, Eq, Hash)>(...) {...} // Multiple bounds require parentheses > > I find this visually appealing. It's easier for my eye to read, > particularly if the bounds are complicated. > > I know it's a syntax change, and we're trying to avoid those, but I > thought I'd throw it out for a wider audience to ponder, particularly as it > would eliminate a rather surprising whitespace dependency. > > > > Niko > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
