On Wed, May 18, 2011 at 11:09 AM, Graydon Hoare <[email protected]> wrote:
> fn push(v: &T[], e: T) : T[] {
> let u: T[] = v + [e];
> ret u;
> }
No fist fights have broken out yet so I'll push the bike shedding a
bit further and suggest that you make all types constructor operator
right associative. This would solve the issue of indecipherable types
that C++ has (see the paper "A Modest Proposal : C++ resyntaxed" for a
lot reasoning around this, with examples etc.).
E.g. what does this mean "@ int []"? I wouldn't know without looking
it up (which is the same issue C++ has). Is it a box with an array of
ints, or an array of boxes of ints? If everything's always right
associative the former would be "@ [] int", and the latter "[] @ int".
How would you write the type for "a mutable box of array of boxes of
mutable ints"? Well with right associativity it would transcribe
trivially to: "mutable @ [] @ mutable int". Just read it left to right
like you would in English and that's what it is.
Of course, you could choose to forego associativity for some things if
grouping is natural due to the constructor being a set of brackets
(e.g. you might want [T], {x:T}, (T,U) for vectors, records and tuples
respectively). This makes it less consistent but possibly without
introducing too much confusion, and maybe even improving clarity a
bit.
In fact, in that case all you'd need to change, as far as I can tell,
is the vector type constructor syntax to be "[T]" instead of T[] which
would avoid any ambiguous associativity issues (that last example
would then be "mutable @ [ @ mutable int ]").
--
Sebastian Sylvan
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
