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.
Niko
On 1/1/12 1:32 PM, Brian Anderson wrote:
----- Original Message -----
From: "Niko Matsakis"<[email protected]>
To: "Brian Anderson"<[email protected]>
Cc: [email protected]
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 [].
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
