> I guess the comma should be allowed to be consistent with tuples and
> vectors.
+1
jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 04/19/2013 11:57 AM, John Clements wrote:
This program illustrates a small but irritating inconsistency between
tuple-shaped enum variants and tuple-shaped structs:
// trailing comma allowed here:
struct F1(int,int,);
struct F2(int,int);
// trailing comma disallowed here:
/*enum G1 {
H1
This program illustrates a small but irritating inconsistency between
tuple-shaped enum variants and tuple-shaped structs:
// trailing comma allowed here:
struct F1(int,int,);
struct F2(int,int);
// trailing comma disallowed here:
/*enum G1 {
H1(int,int,)
}*/
enum G2 {
H2(int,int)
}
I
Here's a demonstration using flatpipes:
extern mod std;
use std::flatpipes;
fn main() {
let (server_chan, server_port) = flatpipes::serial::pipe_stream();
do task::spawn {
let val: @[int] = server_chan.recv();
io::println(fmt!("Value: %?", val));
}
let value = @
On 4/19/13 7:44 AM, Alexander Stavonin wrote:
Do we have any possibility to do something like this or only owned
values can be send?
You can mark your data as serializable and use flatpipes. This gives you
the ability to send managed values, at the cost of a copy on send.
Essentially it's the
On Fri, Apr 19, 2013 at 10:44 AM, Alexander Stavonin
wrote:
> Do we have any possibility to do something like this or only owned values
> can be send?
>
> 11 fn task_with_shared_pointers() {
> 12 let value = @[1, 2, 3, 4, 5];
> 13 let (server_chan, server_port) = stream();
> 14
> 15
On 13-04-19 07:44 AM, Alexander Stavonin wrote:
Do we have any possibility to do something like this or only owned
values can be send?
Only owned values.
-Graydon
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust
Do we have any possibility to do something like this or only owned values
can be send?
11 fn task_with_shared_pointers() {
12 let value = @[1, 2, 3, 4, 5];
13 let (server_chan, server_port) = stream();
14
15 do task::spawn {
16 let val: @[uint] = server_chan.recv();
I think it's fine to remove this test, just because it's old and cruft and
not hard to reproduce. *However* it should eventually be possible to
implement the same interface for the same type multiple times with
different type parameters, it's just that our current trait implementation
has accidenta
