On 13-07-25 08:34 AM, Simon Sapin wrote:
> Le 25/07/2013 01:56, Graydon Hoare a écrit :
>> for <pattern> in <expr> { ... }
>
> Yes please.
>
>
>> - The 'do' form starts to look a little lonely / incongruous. We use
>> it presently for passing-in-a-closure when a function takes an
>> optional value, such as:
>>
>> do hashmap.find_or_insert_with(k) {
>> def()
>> }
>>
>> Given we're discussing macro-izing the other main use of 'do' to
>> generate an owning thunk Trait object, It's not entirely clear to
>> me that this pattern alone warrants keeping 'do'.
>
> Aren’t there other uses of 'do'?
>
> do std::task::spawn {
> // ...
> }
That's what I alluded to above, where we're likely to switch that to a
macro call that passes explicitly-captured arguments into a thunk struct
that owns the explicit captures. This has been in meeting minutes for a
while but I guess it wasn't clear. Lambdas that capture-by-copy (=move)
are slated for removal. Or at least ... we've agreed to _experiment_
with replacing them with thunk-generating macros.
There are a few reasons for this:
- Capture-by-copy-or-move is ... counterintuitive for at least several
users. It's especially counterintuitive given that it's _inferred_
presently. But even without, users seem to have magical beliefs
about closures that seldom agree from user to user. We've got a lot
of "that didn't do what I expected" feedback about any closure
form other than simple by-ref, can-mutate-the-environment &fns.
- Structs already own their fields and have an extremely rich
language for describing the relationship between self and fields.
Notably:
- Trait bounds for things like Freeze, Clone, Send
- Region parameters on captured pointers
- Once-ness (by-val self)
- Freezing and thawing the owner
We've attempted to add all these things on to function types
in the past and wound up with function types like
once ~fn:Clone+'static<'a,T,U>(&'a T) -> U
which, while plausibly readable to someone very familiar with
rust code, feels to me a bit like "past the reasonable cognitive
budget". The syntax(es) for declaring these things on structs and
traits is similar, but a little more spacious, a little easier
to digest: the onceness, arg and return parts are moved to a method,
making it a bit easier to read uses of the thunk-type itself.
- Spawned tasks should get names and source coordinates for the
sake of backtraces and error reporting, so we want to macro-ize
spawning anyways.
- Spawned tasks may wind up needing dtors anyways, in which case they
would need to be named types, not an anonymous fn type.
So I think we'll try it, anyways. It naturally makes the delightful
looking 'do spawn { ... }' expression a little grottier, but that might
be the price we pay for eliminating confusion elsewhere.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
