Re: [rust-dev] Syntax for custom type bounds

On Mon, Feb 3, 2014 at 11:33 AM, Niko Matsakis wrote: > On Sat, Feb 01, 2014 at 03:42:45PM -0800, Vadim wrote: > > Since &'a Foo currently means "the return value is a reference into > > something that has lifetime 'a", 'a Foo feels like a natural > extension > > for saying "the return value is

Re: [rust-dev] Will smart-pointer deref operator allow making iter::ByRef more generic?

Ah, I think I see. I was expecting that after the deref trait lands, that a type like Gc would transparently implement all of the traits that T implemented. I guess that is not the case. So, if you want to pass the pointer to a function that expects an instance of one of the traits implemented by T

Re: [rust-dev] Futures in Rust

On Tue, Feb 4, 2014 at 12:25 PM, Niko Matsakis wrote: > Within a single function we are more permissive, I think. I've been > debating if we should stop that, just for consistency. I think that'd be too annoying. I'd rather see Rust going the other way, and permit calling functions which borro

Re: [rust-dev] Faster communication between tasks

Thanks for the update! Once it's pushed a writeup about the design and performance might be well-receieved on r/rust. On 01/28/2014 06:05 PM, Simon Ruggier wrote: A small update: I've gotten a resizable version of my disruptor implementation working, and the performance looks pretty good so far

Re: [rust-dev] struct that has a field which is a ref

Thanks Eric. I thought it might change it (based on the presentation he gave). The blog post still requires (another) reread :-). On Tue, Feb 4, 2014 at 11:43 PM, John Grosen wrote: > Niko's DST changes may involve allowing bounds in type definitions, which > includes structs. You can read more

Re: [rust-dev] struct that has a field which is a ref

> Niko's DST changes may involve allowing bounds in type definitions, which > includes structs. You can read more here > (http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-take-5/). Okay, I guess it was part of DST, then. That proposal had a lot of content in it! -- John Grosen

Re: [rust-dev] struct that has a field which is a ref

Niko's DST changes may involve allowing bounds in type definitions, which includes structs. You can read more here . On Tue, Feb 4, 2014 at 1:31 PM, Marc Bowes wrote: > I see, thanks. Just to be clear, is this correct then? >

Re: [rust-dev] struct that has a field which is a ref

#2 is definitely correct — sorry, I forgot that part of it :) #1 is a little more nuanced. For the moment, it’s correct. The current line of thinking (at least, what I’ve gathered) is that you only require trait bounds on the methods that actually use that trait. For example, you could create a

Re: [rust-dev] struct that has a field which is a ref

I see, thanks. Just to be clear, is this correct then? ``` trait MyTrait { fn be_traity(&self); } struct MyImpl { my_field: u32 } impl MyTrait for MyImpl { fn be_traity(&self) {} } struct MyStruct<'a, T> { my_field: &'a T } impl<'a, T: MyTrait> MyStruct<'a, T> { fn new(my_f

Re: [rust-dev] struct that has a field which is a ref

The problem here is that you are using a trait object in the struct definition rather than a generic; at the moment, struct generics cannot have trait bounds, though, so the code for the struct would be simply: ``` struct MyStruct<‘a, T> { my_field: &’a T } ``` Then the `impl` code should

[rust-dev] struct that has a field which is a ref

Hello, I'm trying to implement a struct where one of the fields is a reference and therefore has bounded lifetime. The reason I would like it to be a reference is to encourage sharing of the value in question as setup of said value might be expensive. In my specific example, the value is a session

Re: [rust-dev] Futures in Rust

Within a single function we are more permissive, I think. I've been debating if we should stop that, just for consistency. There are also some bugs concerning closures. I hope to close those soon with my patch for #6801. On Wed, Jan 29, 2014 at 02:39:01PM -0800, Vadim wrote: > I've tried to simula

Re: [rust-dev] Nick Cameron joins the Rust team at Mozilla

Thanks all! Really looking forward to working with everyone and getting stuck in to Rust. Cheers, Nick On Tue, Feb 4, 2014 at 3:20 PM, Brian Anderson wrote: > Hi Rusties, > > I'm just thrilled to announce today that Nick Cameron (nrc) has joined > Mozilla's Rust team full-time. Nick has a PhD i

Re: [rust-dev] Handling I/O errors

Perhaps it would help if we actually had a static io::EOF static EOF: IoError = IoError { kind: EndOfFile, desc: "end of file", detail: None } Then we could use this in match patterns as in match w.write(buf) { Err(EOF) => handle_eof(), Err(e) => handle_other_error(), Ok(n) => ... }

Re: [rust-dev] Using Rust with LLVM's Sanitizers

On Tue, Feb 4, 2014 at 12:23 PM, Daniel Micay wrote: > On Tue, Feb 4, 2014 at 3:45 AM, Corey Richardson wrote: >> Hey all, >> >> As you are probably aware, we use LLVM for code generation and >> optimization. It is a large project, and one of its cooler features is >> the variety of "sanitizers"

Re: [rust-dev] Using Rust with LLVM's Sanitizers

On Tue, Feb 4, 2014 at 3:45 AM, Corey Richardson wrote: > Hey all, > > As you are probably aware, we use LLVM for code generation and > optimization. It is a large project, and one of its cooler features is > the variety of "sanitizers" it provides > (http://clang.llvm.org/docs/index.html#using-cl

[rust-dev] The rustpkg source lives on

Hi all, Some people have expressed unhappiness that rustpkg was removed rather than fixed, so I've extracted the last rustpkg source from mozilla/rust and thrown it up on github[1], keeping the git history. I'm personally not planning on doing any particular work on it, but I have copied the

Re: [rust-dev] Nick Cameron joins the Rust team at Mozilla

How exciting. Congratulations Nick! ~Brendan On 4 Feb 2014, at 1:20 pm, Brian Anderson wrote: > Hi Rusties, > > I'm just thrilled to announce today that Nick Cameron (nrc) has joined > Mozilla's Rust team full-time. Nick has a PhD in programming language theory > from Imperial College Londo

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

On Sun, Feb 02, 2014 at 10:30:51AM +0100, Benjamin Herr wrote: > ... while C# apparently compromises and puts the type parameters between > the function name and value parameter list, but leaves the bounds for > later: > > public static bool Contains(IEnumerable collection, T item) >

Re: [rust-dev] Handling I/O errors

0 is no necessarily EOF. E.g. it's not EOF - when you requested to read 0 bytes, which is perfectly legal - when your IO Object is in nonblocking mode (yes, that's currently not supported in Rust, but might be in Future) And the Result, IoError> will only create questions when the the Err Result w

Re: [rust-dev] Handling I/O errors

Hi, Awesome. I have been waiting for this for a long time :D On 04/02/2014 02:00, Alex Crichton wrote: 2. The new if_ok!() macro. This macro has a fairly simple definition [0], and the idea is to return-early if an Err is encountered, and otherwise unwrap the Ok value. Some sample usage looks

Re: [rust-dev] Deprecating rustpkg

On Tue, Feb 4, 2014 at 2:29 AM, Jordi Boggiano wrote: > I just hope whoever starts working on a new spec announces it clearly THIS -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Deprecating rustpkg

On 28/01/2014 12:23, Matthew Frazier wrote: Have you ever used Composer ? I know that Jordi Boggiano, one of the authors, has been involved with the Rust community in the past. Some Composer features that I think are critical for the new Rust package manager include: >

[rust-dev] Using Rust with LLVM's Sanitizers

Hey all, As you are probably aware, we use LLVM for code generation and optimization. It is a large project, and one of its cooler features is the variety of "sanitizers" it provides (http://clang.llvm.org/docs/index.html#using-clang-as-a-compiler). These are not clang-specific, but indeed can be

Re: [rust-dev] Handling I/O errors

On 04/02/14 03:47, Bill Myers wrote: Are we sure that this is the correct design, as opposed to having read return 0 for EoF or perhaps returning None with a Result, IoError> return type? After all, EOF is unlike all other I/O errors, since it is guaranteed to happen on all readers, and the fa

Re: [rust-dev] Handling I/O errors

On 04/02/14 03:49, Bill Myers wrote: it is guaranteed to happen on all readers I meant all finite readers, such as those for normal disk files. What are you getting at here, Bill? I thought you intended the opposite: to hint that could happen a lot on (async) infinite streams. -- Lee ___