On Sat, Nov 30, 2013 at 10:50 PM, Kevin Ballard <[email protected]> wrote: > On Nov 30, 2013, at 7:28 PM, Patrick Walton <[email protected]> wrote: > >> On 11/30/13 7:25 PM, Michael Letterle wrote: >>> I've got to say that the "do" syntax is one of the things that >>> appeals to me about Rust, and will probably appeal to the people >>> that Steve Klabnik is drawing to the language with Rust for Rubyists. >>> >>> It might seem like a small thing but the effects on the type of >>> programs you can write, it actually has a pretty profound effect, IMO. >>> >>> -- >>> Tony Arcieri >>> >>> >>> I agree actually, I was using do to implement some convenience logic and >>> my code went from: >>> >>> do function { someotherFunction() }; >>> >>> to >>> >>> function(|| someotherFunction()); >>> >>> Maybe I'm abusing something here, but I found the first format more >>> intuitive and elegant... >>> >>> I know there's rumblings about io conditions going away, but the change >>> also makes that more awkward... :/ >> >> The point of this change was to got rid of closure type inference. With the >> old rules it was not possible to see whether you were allocating without >> looking at the type signature of the function you're calling. Moreover the >> capture rules are extremely different depending on the type of closure it >> is. It's too much magic for Rust. > > Can we not simply allow `do` to work with both stack closures and heap > closures? With the current proc() stuff that would be > > do spawn proc() { > .. > } > > And yes, I know do originally existed to make spawning nicer, but that's not > really that ugly, and allows for using `do` with stack closures (which, in > code I've seen, has been by far the majority of use-cases for `do`). Also, > IMO making the existence of a proc more obvious seems like a good idea (given > the effect it has on captured values). Similarly, if this change were made, > then a nullary stack closure would be called like > > do some_func || { > .. > } > > which I think is fine, as it makes the stack closure obvious, although the > potential confusion of the || with the logical-OR operator is very slightly > worrisome (but not terribly so, especially because pushing RAII should mean > that functions that take nullary stack closures in tail position shouldn't be > common). > > -Kevin
I don't understand the point of `do` beyond making zero-parameter closures look a bit better. If it doesn't even do that, why bother? If an editor isn't indenting it properly, that's an editor issue. As far as I can tell, the vim indent file now handles it fine. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
