If the vast majority of types take only a single type parameter, then it could potentially be worth considering using a unary sigil. (I think D does something like this.)
Choosing the tilde as the arbitrary symbol here, your example would look like Arc~Exclusive~Vec~Box~Buffer~T. If you have multiple type parameters, you would need to wrap them in parens like ~(T, U). Just something to consider. Whether or not we want something like this, I'd be fascinated if someone managed to gather stats on how many types take only a single type parameter. On Sun, Jun 29, 2014 at 3:06 PM, François-Xavier Bourlet <bomb...@gmail.com> wrote: > Isn't: > > type my_convonluted_type = Arc<Exclusive<Vec<Box<Buffer<T>>>>>; > > The most common way to avoid retyping long definition? one could also > pretty indent the type definition for readability, since it will be > defined once. > > On Sun, Jun 29, 2014 at 9:56 AM, Benjamin Herr <b...@0x539.de> wrote: > > I realize that, but simplifying > > > > Arc<Exclusive<Vec<Box<Buffer<T>>>>> > > > > into > > > > Arc (Exclusive (Vec (Box (Buffer T)))) > > > > wouldn't really buy us that much. > > > > > > On Sun, 2014-06-29 at 09:50 -0700, Cameron Zwarich wrote: > >> This is pretty confusing to me because it’s associative in the opposite > direction that function application is associative in functional languages > with automatic currying. > >> > >> Cameron > >> > >> On Jun 28, 2014, at 3:48 PM, Benjamin Herr <b...@0x539.de> wrote: > >> > >> > 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 > _______________________________________________ > 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
