On 01/11/2013 11:50 AM, Brian Anderson wrote:
On 01/11/2013 10:50 AM, Niko Matsakis 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>(...) {...}
Supertraits share the same syntax, so we should consider them
together. If or when impls can implement multiple traits they may also
need a similar syntax.
trait Foo: 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?
No, but it's the ugliest part of the lexer. Let's make it go away.
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
As an example, this is why the parens are needed:
fn foo<T:(Ord, Eq, Hash), U>(...) {...}
so you _could_ still allow `foo<T: Ord, Eq, Hash>` since there's no
ambiguity, but that's more complex that necessary.
Of course, there _is_ an ambiguity, this would just be requiring parens
to add the second type parameter, so not a good idea.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
