What is the possibility that Rust allow certain traits for operators such as these to be implemented as libraries?
I can certainly see the benefits of stuff like that, although I don't think it might be a good idea to depend on such operators (I *love* overloaded operators in linear algebra and combinators, but they are questionable outside of specific niches, thus their introduction as traits would probably be best) On Wed, Sep 25, 2013 at 1:50 PM, Oren Ben-Kiki <[email protected]> wrote: > Not sure about $ but I sometimes miss the |> operator (which takes the > value from the left and inserts it as the 1st argument of the function call > to the right). > > foo(a, b) |> bar(c, d) |> baz(e, f) > == baz(bar(foo(a, b), c, d), e, f) > > This allows for easier "functional" decompsition of chains of operations. > I found it to be very useful when writing Elixir; in Rust there's the > OO-like traits which may make it less useful - it still might be worthwhile > for people writing more functional code. > > > On Wed, Sep 25, 2013 at 9:40 PM, Marvin Löbel <[email protected]>wrote: > >> We don't use the symbol in our syntax, but are using functional paradigm >> that sometimes result in a bit hard to read nested calls. >> >> I'd propose that it works similar to `do`, in that it allows to move the >> last expression of an function or method call after the parentheses, though >> they would still remain required for ambiguity reasons: >> >> ~~~ >> a(b(c(1,d(2,3,4,e())))) >> == a() $ b() $ c(1) $ d(2,3,4) $ e() >> >> let v: ~[uint] = from_iter() $ range(0, 100); >> ~~~ >> >> In that sense, it wouldn't really be an operator but syntactic sugar for >> a function call. >> It might even be possible to replace `do` with it, though the now >> required parentheses would make it longer: >> >> ~~~ >> do task::spawn { ... } >> task::spawn() $ || { ... } >> ~~~ >> >> Downside is of course that it adds another symbol, which could alienate >> more potentiall users, and it could mean a shift-away-from or at least an >> inconsistency-with methods and method chaining in general. >> >> Which would be ironic because I wanted it in some complicated Iterator >> chain. ;) >> >> It could of course always be implemented as a syntax extension, and in >> any case I don't expect this to get any attention before Rust 2.0. :) >> ______________________________**_________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >> > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > -- Andrés Osinski http://www.andresosinski.com.ar/
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
