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

François-Xavier Bourlet bombela at gmail.com
Sun Jun 29 12:06:38 PDT 2014


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


More information about the Rust-dev mailing list