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,
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 rusty.ga...@icloud.com wrote:
Function overloading is
...@icloud.com wrote:
On 2014-05-30, at 3:42, Eric Reed ecr...@cs.washington.edu wrote:
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
, wouldn't
it lead to a conflict?
On Thu, May 29, 2014 at 6:02 PM, Eric Reed ecr...@cs.washington.edu
wrote:
You have to make the varying type the type implementing the trait.
trait Foo {
fn foo(arg: Self, some_int: int);
}
implT: Iterator Foo for T {
fn foo(arg: T
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 pnathan.softw...@gmail.comwrote:
Hi,
It looks like two people have expressed interest in this. I think that's
enough to get together and talk.
My suggestion for
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` has an
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 ke...@sb.org 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
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 rusty.ga...@icloud.com wrote:
On 09 Apr 2014, at
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
over
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 thadgui...@gmail.com wrote:
Curious, Whole Mozilla moving ? or just some teams ? and why ? making
room for others ? kicked out by grumpy landlord or mayor ?
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
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, Tobias Müller trop...@bluewin.ch wrote:
Eric Reed ecr...@cs.washington.edu wrote
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 n...@alum.mit.edu wrote:
I wrote up an RFC. Posted on my blog at:
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
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 ke...@sb.org wrote:
On Feb 25, 2014, at 4:04 PM, Eric Reed ecr...@cs.washington.edu wrote:
Would a mut that could move enable us to write insertion into a
growable
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
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
AM, Eric Reed ecr...@cs.washington.eduwrote:
I'm going to respond to Any and size_of separately because there's a
significant difference IMO.
It's true that Any and trait bounds on type parameters in general can let
function behavior depend on the passed type, but only in the specific
at 3:31 PM, Corey Richardson co...@octayn.net wrote:
On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed ecr...@cs.washington.edu
wrote:
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
seriously don't see what downside this could possibly have.
On Sat, Feb 1, 2014 at 6:43 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Feb 1, 2014 at 9:27 PM, Eric Reed ecr...@cs.washington.edu
wrote:
I wasn't aware of mem::size_of before, but I'm rather annoyed to find out
we've
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 ptal...@hyc.io wrote:
On 01/28/2014 11:26 PM, Eric Reed wrote:
Looks pretty reasonable
How would that make us lose stack allocated return values?
On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im 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
trait
object.
jack.
On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed ecr...@cs.washington.edu
wrote:
How would that make us lose stack allocated return values?
On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im wrote:
Good point. Make `Chan` a trait with implementers
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 Reed
.
On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed ecr...@cs.washington.edu
wrote:
fn fooT: Trait() - T
On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt j...@metajack.im wrote:
You can't do `foo() - Trait`. It would have to be `foo() - ~Trait`.
Well, unless DST fixes this. I assume
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
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
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.
On Sat, Dec 21, 2013 at 9:33 PM, Eric Reed ecr...@cs.washington.eduwrote:
IMO the best
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
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,
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 the
) 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, 2013 at 12:56 AM, Ziad Hatahet hata...@gmail.com wrote:
On Mon, Dec 2, 2013 at 12:43 AM, Eric
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
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 ke...@sb.org wrote:
With @ going
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 pwal...@mozilla.com wrote:
Anything with @ feels like it goes too close to pointer sigils for my
taste.
Patrick
spir
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 BoxT {
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 the
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 ke...@sb.org wrote:
~ would still be the unique default. @ would require a place (because
there's no placement without a place). Just
Well there's always r/rust/ http://www.reddit.com/r/rust/. It usually
works pretty well.
On Mon, Dec 2, 2013 at 9:45 PM, David Piepgrass qwertie...@gmail.comwrote:
On 02/12/2013 16:21, David Piepgrass wrote:
That would be so. much. better. than a mailing list.
Hi. Could you expand on
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
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
) 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:27 AM, Eric Reed ecr...@cs.washington.eduwrote:
Here's how I would do it using just existing Rust
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 ecr...@cs.washington.eduwrote:
I'm not clear on why LLVM wouldn't be able to inline super() calls. It's
static
be interesting 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 ecr...@cs.washington.eduwrote:
I'm not sure I follow.
My implementation doesn't use any trait pointers, so the only time there
were would be a trait pointer
I'd suggest extra::list, but it looks a little dated.
On Tue, Nov 12, 2013 at 6:21 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
For linked lists with no cycles, why not use OptionRcT (or RcMut)?
On Tue, Nov 12, 2013 at 4:06 PM, spir denis.s...@gmail.com wrote:
PS: What would be, in fact,
I left a XXX about this
herehttps://github.com/mozilla/rust/blob/master/src/libstd/rt/uv/uvio.rs#L958.
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
45 matches
Mail list logo
