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

Benjamin Striegel ben.striegel at gmail.com
Sun Jun 29 21:23:08 PDT 2014


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 <bombela at 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 <ben at 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 <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
> >>
> >
> >
> > _______________________________________________
> > Rust-dev mailing list
> > Rust-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140630/26a3aeb2/attachment.html>


More information about the Rust-dev mailing list