On Nov 30, 2013, at 7:54 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On Sat, Nov 30, 2013 at 10:50 PM, Kevin Ballard <ke...@sb.org> wrote:
>> 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
>
> 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.
At this point, given that stack closures no longer work with do, it seems to me
that do is just Rust's attempt at providing a syntactical nicety analogous to
Go's `go` operator.
If we can't have `do` working with stack closures, my feeling is we should just
remove it. Keeping around special syntax purely for the case of heap closures
seems like unnecessary complexity. Although my preference is still for
restoring `do`'s ability to work with stack closures.
-Kevin
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
