[rust-dev] names needed for function types

Niko Matsakis niko at alum.mit.edu
Sun Jan 1 15:49:38 PST 2012

Ah, I see.  That's interesting, not how I thought of it.  To me the 
capture clause and environment kind bound go together, as the kind bound 
affects the things that can legally be captured (in that sense, I rather 
like the way that a capture clause mirrors a parameter list: it's like a 
set of implicit parameters that get carried with the closure).  The type 
parameters (and their associated kind bounds) seem like a separate thing.


On 1/1/12 1:32 PM, Brian Anderson wrote:
> ----- Original Message -----
>> From: "Niko Matsakis"<niko at alum.mit.edu>
>> To: "Brian Anderson"<banderson at mozilla.com>
>> Cc: rust-dev at mozilla.org
>> Sent: Sunday, January 1, 2012 9:37:26 AM
>> Subject: Re: [rust-dev] names needed for function types
>>> Here is how it would look with square brackets:
>> It occurs to me that the "capture clause" could (and probably should)
>> go
>> before the name, if we allowed it on nested fn item declarations:
>>       fn no_env(a: A, b: B) {...}
>>       fn<copy>  boxed_env_1(a: A, b: B) {...}
>>       fn<copy a; move b>  boxed_env_2<A,B>(a: A, b: B) {...}
>>       fn<send; copy a; move b>  unique_env<A,B>(a: A, b: B) {...}
>> In this way there is no ambiguity at all.  (Note that we don't allow
>> function types to have generic parameters at the moment)
> I was thinking that 'copy' and 'send' are kind bounds that apply to the environment instead of a parameter, so it would make sense to write
>      fn boxed_env_1<copy>(...) { ... }
>      fn boxed_env_2<copy, copy A, send B>(a: A, b: B) { ... }
> The capture clause seems like a different kind of thing, so could still use [].

More information about the Rust-dev mailing list