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