Re: [rust-dev] Is our UdpSocket misbehaving?

I left a XXX about this here. I'm pretty sure libuv drops the remainder of the packet, but I haven't confirmed that. I think the best way to deal with this is to raise a PartialPacketRead condition. On Mon, Sep 16, 2013 at

Re: [rust-dev] Rust session at Seattle CodeCamp, Sep 28th 2013

Sorry I'm only getting to this now; I've been busy moving. I won't be able to make the presentation, but I can look over slides or something today if you like. Good luck! Eric On Wed, Sep 18, 2013 at 10:34 AM, Jeffery Olson wrote: > > > > On Wed, Sep 18, 2013 at 9:45 AM, Luis de Bethencourt <

Re: [rust-dev] copying pointers

I'd suggest extra::list, but it looks a little dated. On Tue, Nov 12, 2013 at 6:21 AM, Oren Ben-Kiki wrote: > For linked lists with no cycles, why not use Option> (or RcMut)? > > > On Tue, Nov 12, 2013 at 4:06 PM, spir wrote: > >> PS: What would be, in fact, the rusty way for a simplissim link

Re: [rust-dev] "Implementation Inheritance" / mixins

Here's how I would do it using just existing Rust (assuming this hasn't all changed under me in the past couple months). NB: I haven't actually tried compiling this, but I'm pretty sure it (or something like it) would work. Nice properties over this solution: - Doesn't require language extensions

Re: [rust-dev] Greenlets in Rust (was: Abandoning segmented stacks in Rust)

The big issue I see right away (assuming I read this correctly and greenlets can still access the stack that existed when they were created), is that now mutable state on the stack is *shared* between greenlets and therefore can experience *data races* (impossible for tasks b/c they don't share mem

Re: [rust-dev] "Implementation Inheritance" / mixins

late methods? > > The key weakness is that (I think) the compiler can't inline the accesses > to "super" so that you end up with a chain of virtual function calls every > time it is accessed, so performance would be pretty bad. > > > On Wed, Nov 13, 2013 at 10:2

Re: [rust-dev] "Implementation Inheritance" / mixins

invoke any trait function, I pay double the > cost of a virtual function call instead of one... I suppose it isn't _too_ > bad, but it still hurts. > > > > On Wed, Nov 13, 2013 at 12:21 PM, Eric Reed wrote: > >> I'm not clear on why LLVM wouldn't be able t

Re: [rust-dev] "Implementation Inheritance" / mixins

sting to look at the > generated binary code and see if it actually work this way... > > On Wed, Nov 13, 2013 at 8:08 PM, Eric Reed wrote: > >> I'm not sure I follow. >> My implementation doesn't use any trait pointers, so the only time there >> were would b

Re: [rust-dev] Placement new and the loss of `new` to keywords

I think the 'new(place) expr' or 'box(place) expr' is pretty confusing syntax. To me, it's not at all clear that "new(varA) varB" means "eval varB and put it into varA" instead of "eval varA and put it into varB". I'd much prefer syntax that makes it very clear which is the expression and which is

Re: [rust-dev] Placement new and the loss of `new` to keywords

to be considered a 'place' (some sort of trait I assume) by the typechecker. Ending in_tail with an expr shouldn't be a problem (lambda_expr does it). The parser can unambiguously tell if there is an in_tail present by simply checking for the "in" keyword. On Mon, Dec 2,

Re: [rust-dev] Can traits define instance vars?

Hi Oliver, Glad you're liking Rust so far :) Currently traits can only have methods (functions that have a self parameter) and associated functions (functions without a self parameter). There's a proposal to add inheritance on structs to Rust, which would allow a trait to extend a struct and gain

Re: [rust-dev] Placement new and the loss of `new` to keywords

This is my new favorite idea, especially expr@place. It's concise. It reads "expr at place", which is exactly what it does. It goes along with Rust's putting the type after the value. "expr in place" could be good too. On Mon, Dec 2, 2013 at 2:57 AM, Kevin Ballard wrote: > With @ going away ano

Re: [rust-dev] Placement new and the loss of `new` to keywords

But it's nothing like a pointer sigil. @ doesn't appear in the types at all. It's just the placement allocation operator. On Mon, Dec 2, 2013 at 10:23 AM, Patrick Walton wrote: > Anything with @ feels like it goes too close to pointer sigils for my > taste. > > Patrick > > spir wrote: >> >> On

Re: [rust-dev] Placement new and the loss of `new` to keywords

I think the idea was to have the syntax desugar into method calls just like other existing operators. There'd be a trait like: trait Box { fn box(val: T) -> Self } and something like "box expr in place" would desugar into "place::box(expr)". One question this poses is why are we requiring th

Re: [rust-dev] Placement new and the loss of `new` to keywords

And @ even makes sense for what it's doing (placing something at somewhere) when compared with most operators. On Mon, Dec 2, 2013 at 12:04 PM, Kevin Ballard wrote: > ~ would still be the unique default. @ would require a place (because > there's no placement without a place). Just because C++

Re: [rust-dev] Rust forum

Well there's always r/rust/ . It usually works pretty well. On Mon, Dec 2, 2013 at 9:45 PM, David Piepgrass wrote: > On 02/12/2013 16:21, David Piepgrass wrote: > >> > That would be so. much. better. than a mailing list. >> >> Hi. Could you expand on this? I don?t

Re: [rust-dev] method overloading and generic

I think you're running into issue #8075which has to do with generic impls conflicting with all the other impls present. The typechecker tries to ensure that impls are coherent, i.e. that impls do not overlap (otherwise the compiler wouldn't know which on

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

FYI, there's already a method on Option that is unwrap() with an error message: expect(). Personally, I prefer making functions that don't fail and use Option or Result and then composing them with functions that fail for certain outputs, but I think I'm in the minority there. On Fri, Dec 6, 201

Re: [rust-dev] Trait container return types

I'm on a phone so I haven't tested this, but I'd suggest removing the T parameter of Field and replacing uses of T with Self. In case you don't already know, Self is a implicit type parameter representing the type of self, i.e. the type you impl the trait for. Would that work for your use case? On

Re: [rust-dev] RFC: Iterator naming convention

I prefer the 'no suffix' option and generally agree with Alex. Iterators aren't special and their iterator behavior is already denoted by implementing the Iterator trait. Frankly, aside from documentation where it is clear that something is an iterator, I'm not sure when a user would even see conc

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

IMO the best alternative for a non-blocking send on a bounded channel is returning an Option. If you send successfully, you return None. If you can't send because the channel is full, you return Some(message). This lets the sender recover the message (important for moveable objects) and decide how

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

. On Sat, Dec 21, 2013 at 10:48 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > Eric, thats exactly why I suggested the use of the Result or Either type. > Some is a bit misleaning, because the Nothing case is usually means a > failure rather than a success. > >

Re: [rust-dev] RFC: New Rust channel proposal

I'm skeptical about combining Chan and SharedChan. Maintaining that distinction is useful for expressing the programmer's intent and would certainly make any analysis that cared to distinguish between single and multiple producers easier to implement (off the top of my head, knowing you're the only

Re: [rust-dev] RFC: New Rust channel proposal

Good point. Make `Chan` a trait with implementers `UniqueChan` and `SharedChan`? On Tue, Jan 14, 2014 at 4:52 PM, Jack Moffitt wrote: > > I'm skeptical about combining Chan and SharedChan. Maintaining that > > distinction is useful for expressing the programmer's intent and would > > certainly

Re: [rust-dev] RFC: New Rust channel proposal

How would that make us lose stack allocated return values? On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt wrote: > > Good point. Make `Chan` a trait with implementers `UniqueChan` and > > `SharedChan`? > > I suppose the main downside of that solution is that you lose stack > allocated return val

Re: [rust-dev] RFC: New Rust channel proposal

eratable trait > object. > > jack. > > On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed > wrote: > > How would that make us lose stack allocated return values? > > > > > > On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt wrote: > >> > >> >

Re: [rust-dev] RFC: New Rust channel proposal

As a follow up, what situation would arise where you'd have to actually return a Chan trait object? Constructors are going to return the concrete type UniqueChan/SharedChan. Functions acting on channels can just use generics, which will allow returning. On Tue, Jan 14, 2014 at 9:21 PM, Eric

Re: [rust-dev] RFC: New Rust channel proposal

han/SharedChan. > > Functions acting on channels can just use generics, which will allow > > returning. > > > > > > On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed > wrote: > >> > >> fn foo() -> T > >> > >> > >> On Tue, Jan 14, 2014 at

Re: [rust-dev] Compile-time function evaluation in Rust

Looks pretty reasonable to me at first glance. Out of curiosity, what's the rationale behind forbidding unsafe functions/blocks? On Tue, Jan 28, 2014 at 2:15 PM, Pierre Talbot wrote: > Hi, > > The Mozilla foundation proposes research internships [1] and the CTFE > optimization in the Rust compi

Re: [rust-dev] Compile-time function evaluation in Rust

That's what I figured. Forbidding unsafe is definitely a good way to keep things simple starting out. Compile time evaluation can always be extended later on. On Tue, Jan 28, 2014 at 3:21 PM, Pierre Talbot wrote: > On 01/28/2014 11:26 PM, Eric Reed wrote: > >> Looks pretty re

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

Responses inlined. > Hey all, > > bjz and I have worked out a nice proposal[0] for a slight syntax > change, reproduced here. It is a breaking change to the syntax, but it > is one that I think brings many benefits. > > Summary > === > > Change the following syntax: > > ``` > struct Foo { ...

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

atch makes its way into the Rust language spec, I'm going to consider it an implementation detail for rustc. On Sat, Feb 1, 2014 at 3:31 PM, Corey Richardson wrote: > On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed > wrote: > > Responses inlined. > > > >> > >> H

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

kes size_of like other intrinsic operators (+, ==, etc.). I seriously don't see what downside this could possibly have. On Sat, Feb 1, 2014 at 6:43 PM, Daniel Micay wrote: > On Sat, Feb 1, 2014 at 9:27 PM, Eric Reed > wrote: > > > > I wasn't aware of mem::size_of before,

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

is valid for all types. > > I also think we should guarantee parametricity for safe code and make > `size_of` an unsafe fn. Its legitimate uses in unsafe code (e.g. smart > pointers) are well encapsulated and don't expose parametricity violations, > and I don't believe safe c

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] error: cannot pack type `~PtrStruct`, which does not fulfill `Send`, as a trait bounded by Send

~Trait is really sugar for ~Trait: Send, so you're putting an implicit Send bound wherever you use ~Trait. A type meets the Send bound if it's safe to send over channels (which really means that it contains no aliasable data or references [alternatively, it owns all of its parts]). Rc can never mee

Re: [rust-dev] error: cannot pack type `~PtrStruct`, which does not fulfill `Send`, as a trait bounded by Send

Oh, just to be clear: you should change `tr: ~Trait1' to `tr: ~Trait1: ' in the function signature of use_mon_trait and change `ptr_struct as ~Trait1' to `ptr_struct as ~Trait1: '. On Fri, Feb 7, 2014 at 1:54 PM, Eric Reed wrote: > ~Trait is really sugar for ~Trait: Sen

Re: [rust-dev] RFC: Stronger aliasing guarantees about mutable borrows

I'm in favor. I guess if there's some giant use case for the current &mut then we could keep it and add this new version as &move, but I agree that that probably isn't the case. On Tue, Feb 25, 2014 at 10:32 AM, Niko Matsakis wrote: > I wrote up an RFC. Posted on my blog at: > > > http://small

Re: [rust-dev] RFC: Stronger aliasing guarantees about mutable borrows

Well, you can if you can construct a dummy value to swap in temporarily. I'm pretty sure that's not always possible without venturing into unsafe code (like making an uninit block of the proper size or something). Moreover, nothing stops you from forgetting to swap the value back in so you could ju

Re: [rust-dev] RFC: Stronger aliasing guarantees about mutable borrows

True. I guess I was thinking less unsafe code as opposed to no unsafe code. On Tue, Feb 25, 2014 at 4:47 PM, Kevin Ballard wrote: > > On Feb 25, 2014, at 4:04 PM, Eric Reed wrote: > > > > Would a &mut that could move enable us to write insertion into a > growable

Re: [rust-dev] Alternative to Option types

Turns out Rust's Option type already has all this behavior, so I think we're all on to something :) Option is a little more powerful than nullable pointers because you can have Options of non-pointer values. IIRC, Option<~T> is actually compressed to be a nullable pointer. I actually really like t

Re: [rust-dev] Alternative to Option types

Turns out Option.and_then is literally Option's monadic bind. Both do-notation and Haskell's list comprehensions (which generalize to monads and I think are equivalent to Scala's for-comprehensions) actually just desugar into calls to the monad's bind and return functions (Option's return is just |

Re: [rust-dev] Alternative to Option types

r HKTs a much better choice than MPTCs (even if MPTCs theoretically subsume HKTs). They're *way* easier to use. [note] Strictly speaking, you can have a type "monad" if you have a sufficiently powerful type system (i.e. some level of dependent types). On Fri, Feb 28, 2014 at 2:54 PM, Tobia

Re: [rust-dev] Work week minutes and upcoming RFCs

Wow! Great job all. I think the only major concern I had after one read-through is how we could make downcasting safe. I can't see a way without runtime type tags on structs, which is a non-starter. I guess I'll wait for the RFC on that one. On Sun, Mar 9, 2014 at 8:27 PM, Brian Anderson wrote:

Re: [rust-dev] Rust automation downtime

The Mountain View office outgrew their old location and they're moving to a larger one. On Thu, Mar 13, 2014 at 6:21 AM, Thad Guidry wrote: > Curious, Whole Mozilla moving ? or just some teams ? and why ? making > room for others ? kicked out by grumpy landlord or mayor ? :-) > > > On Wed, M

Re: [rust-dev] impl num::Zero and std::ops::Add error

In addition, mathematicians typically use the symbol '0' to refer to the additive identity of a ring anyway. On Apr 9, 2014 10:47 AM, "Kevin Ballard" wrote: > Why? Zero is the additive identity. It's only bad if you want to denote a > value that contains zeros that doesn't support addition, but t

Re: [rust-dev] impl num::Zero and std::ops::Add error

If you implement Add on a type, then you should implement Zero to specify the identity of the + operation on that type. If you simply want to specify a default value, then you should implement Default. On Apr 9, 2014 11:25 AM, "Tommi Tissari" wrote: > > On 09 Apr 2014, at 20:46, Kevin Ballard w

Re: [rust-dev] impl num::Zero and std::ops::Add error

I think part of the confusion here is that "matrix addition" isn't actually a binary operator, but rather a family of binary operators parametrized over the matrix dimensions. There's +<2,2> for 2 x 2 matrices, +<2,3> for 2 x 3 matrices, etc. Similarly, the "zero matrix" is actually parametrized ov

Re: [rust-dev] Specifying lifetimes in return types of overloaded operators

Could you provide a code sample that causes this error? On Tue, Apr 15, 2014 at 6:28 AM, Artella Coding < artella.cod...@googlemail.com> wrote: > > Currently if I try to specify lifetimes in the return types of overloaded > operators like Index ([]), I get an error message : > > "method `index`

Re: [rust-dev] Seattle Rust Meetup interest?

I'm down for a meetup. I may be able to bring some others from UW CSE with me. On Thu, May 15, 2014 at 1:46 PM, Paul Nathan wrote: > Hi, > > It looks like two people have expressed interest in this. I think that's > enough to get together and talk. > > My suggestion for scheduling is next Thursd

Re: [rust-dev] Function overloading is necessary

Rust *does* have function overloading. That's *exactly* what traits are for. If you want to overload a function, then make it a trait and impl the trait for all the types you want to overload it with. On Thu, May 29, 2014 at 4:01 PM, Tommi wrote: > Function overloading is a language feature tha

Re: [rust-dev] Function overloading is necessary

- You can only vary on one type. Long term, this can be fixed by making our traits MultiParameterTypeClasses instead of just regular Type Classes. Short term, you can avoid this by impl'ing on a tuple of the varying types. On Thu, May 29, 2014 at 5:52 PM, Tommi wrote: > On 2014-05-30,

Re: [rust-dev] Function overloading is necessary

n't > it lead to a conflict? > > On Thu, May 29, 2014 at 6:02 PM, Eric Reed > wrote: > > You have to make the varying type the type implementing the trait. > > > > trait Foo { > > fn foo(arg: Self, some_int: int); > > } > > > > impl Foo fo

Re: [rust-dev] Bring Back Type State

I'm not going to claim canonicity, but I used the type system to encode the socket state machine (see std::io::net::{tcp,udp}). TcpListener consumes itself when you start listening and becomes a TcpAcceptor. UdpSocket can "connect" (i.e. ignore messages from other sources) and become a UdpStream, w