[rust-dev] Syntax sugar: Vec Rc RefCell Box Foo -> Vec<Rc<RefCell<Box<Foo>>>>

Cameron Zwarich zwarich at mozilla.com
Sun Jun 29 09:50:49 PDT 2014

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.


On Jun 28, 2014, at 3:48 PM, Benjamin Herr <ben at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

More information about the Rust-dev mailing list