On Nov 30, 2013, at 7:28 PM, Patrick Walton <pcwal...@mozilla.com> 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
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
