I like it. Lets go all the way down and make `T P` an abbreviation to `T<P>` and `f x` an abbreviation to `f(x)`
People will then start to write `f a b` instead of `f(a,b)` since unboxed closures make this possible. They will also write a macro `defun` to ease the definitions of such functions and request that feature to be integrated in the language Unfortunately `T P1 P2` will not come soon because we don't support type constructors Every thing after "i like it." was a joke. but i'm really sad to see rust adopting the current syntax for types 2014-06-28 23:48 GMT+01:00 Benjamin Herr <b...@0x539.de>: > So, I've been vaguely concerned that types in a less sigil-heavy Rust > inevitably devolve into what some call "spikey lisp", and tried to come > up with some more lightweight syntax. Of course, just removing syntax is > the easiest way to make it weigh less, and it seems like the following > doesn't actually break the grammar dramatically (only some macros!): > > In parsing a path, if a path segment is immediately followed by an > identifier, start parsing another type right away and use it as the only > element of the type parameter list for the current path segment. > > This is fairly limited: > > * It won't work for absolute paths as type parameters > (since they'll look like just another path segment) > * It also doesn't work for non-path types in type parameter lists > * It doesn't simplify multiple type parameters > > I think that's okay, since it's a simplification that applies well to a > lot of simple cases, and might still reduce the total depth of `<`, `>` > nesting in more complicated cases. > > So, for example, the following desugarings would apply: > > Vec String > => Vec<String> > > Arc RWLock Vec f64 > => Arc<RWLock<Vec<f64>>> > > Arc Exclusive Vec Box Buffer T > => Arc<Exclusive<Vec<Box<Buffer<T>>>>> // from libsync > > RefCell DefIdMap Rc Vec Rc TraitRef > => RefCell<DefIdMap<Rc<Vec<Rc<TraitRef>>>>> // from librustc > > HashMap<Vec String, Vec Rc Cell int> > => HashMap<Vec<String>, Vec<Rc<Cell<int>>>> > > Add<Complex T, Complex T> > => Add<Complex<T>, Complex<T>> > > std::mem::size_of RefCell String() // maybe a bit much? > => std::mem::size_of::<RefCell<String>>()) > > I've patched that into libsyntax and `make check` passes... > > ... after changing some macros, since it basically means that adjacent > identifiers parse as a single type (or expression, if we omit `::<>` > too) and some macros try to match `($x:ty fake_keyword_ident ...)`, or > have a case for `($x:expr)` and another for `(fake_keyword $x:expr)`, or > just `($t:ty)*`. Seems like just chomping down on all adjacent > identifiers makes the parser pretty aggressive... > > Yeah, okay, I don't know if this is really a good idea, and it's > probably not RFC-worthy at this point, but imo it does make the syntax a > bit easier on the eyes, and I think that's something we ought to look at > at some point. > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
