2014-02-02 Thomas Leonard tal...@gmail.com:
[ I don't want to start another argument, but since you guys are discussing
0install, maybe I can provide some useful input... ]
I don't follow this. Whether the developer uses 0install to get the build
dependencies doesn't make any difference to
Just because Any is a trait doesn't mean it doesn't break parametricity.
Look at this:
http://static.rust-lang.org/doc/master/src/std/home/rustbuild/src/rust-buildbot/slave/doc/build/src/libstd/any.rs.html#37-63
Because we have `implT: 'static Any for T`, it can be used with *any
type* (except
Hello rust-dev,
I imagine there are reasons I've not considered for why proc
declaration syntax is the way it is, but I couldn't find any
discussion on this list or in the issues so thought I'd make a
proposal.
I think it would be nice if procs and closures had a more similar syntax.
It might be good to revisit proc syntax, but I don't think that it's yet
time for that. There's a nebulous plan in the works involving
reimplementing closures as traits (or... something?) and how that shakes
out would likely impact the syntax that we want to provide.
On Mon, Feb 3, 2014 at 11:26
On Mon, Feb 3, 2014 at 8:41 AM, Gábor Lehel glaebho...@gmail.com wrote:
On Mon, Feb 3, 2014 at 7:55 AM, Corey Richardson co...@octayn.net wrote:
Default typarams are awesome, but they're gated, and there's some
concern that they'll interact unpleasantly with extensions to the type
system
Possibly, but it's not particularly well-trodden ground (I think Ur/Web
might have something like it?).
And would you really want to write `HashMapKey: int, Value: ~str`?
On Mon, Feb 3, 2014 at 6:34 PM, Matthieu Monrocq matthieu.monr...@gmail.com
wrote:
On Mon, Feb 3, 2014 at 8:41 AM,
On Sat, Feb 01, 2014 at 03:42:45PM -0800, Vadim wrote:
Since 'a FooT currently means the return value is a reference into
something that has lifetime 'a, 'a FooT feels like a natural extension
for saying the return value is a reference-like thing whose safety depends
on something that has
Actually this isn't the case.
fn fooT: Any(t: T) - TypeId {
t.get_type_id()
}
compiles just fine, but
fn barT(t: T) - TypeId {
t.get_type_id()
}
fails with error: instantiating a type parameter with incompatible type
`T`, which does not fulfill `'static`. Just T does not imply T:
On Mon, Feb 3, 2014 at 5:20 PM, Eric Reed ecr...@cs.washington.edu wrote:
Actually this isn't the case.
fn fooT: Any(t: T) - TypeId {
t.get_type_id()
}
compiles just fine, but
fn barT(t: T) - TypeId {
t.get_type_id()
}
fails with error: instantiating a type parameter with
On Mon, Feb 3, 2014 at 11:20 PM, Eric Reed ecr...@cs.washington.edu wrote:
Actually this isn't the case.
fn fooT: Any(t: T) - TypeId {
t.get_type_id()
}
compiles just fine, but
fn barT(t: T) - TypeId {
t.get_type_id()
}
fails with error: instantiating a type parameter with
Greetings Rustaceans!
Upon updating your nightly builds tonight some of you may realize that
all I/O code will fail to compile. Fear not, this simply means that
#11946 has landed! The summary of this change is the same as its
title, remove io::io_error. This is quite a far-reaching change,
By returning a Result from all function calls, it's not much cleaner
to handle errors
Oops, wrong word there, I meant to indicate that it *is* much cleaner
to handle errors with Result rather than conditions.
___
Rust-dev mailing list
Welcome Nick!
I can't wait to see that 1.0 issue count go down!
On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson bander...@mozilla.com 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
Hi,
I was looking at some structs in Rust that implement the Decorator pattern
- structs that take some value, wrap it, and then provider the same
interface as the value that they are wrapping while providing some extra
behavior. BufferedReader is an example here - it takes another Reader and
Fantastic! Good luck, Nick!
On Mon, Feb 3, 2014 at 6:51 PM, Alex Crichton a...@crichton.co wrote:
Welcome Nick!
I can't wait to see that 1.0 issue count go down!
On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson bander...@mozilla.com
wrote:
Hi Rusties,
I'm just thrilled to announce
it is guaranteed to happen on all readers
I meant all finite readers, such as those for normal disk files.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I don't think so, because the fact that the particular instance of T implements
the Deref trait cannot have any effect on the decorator code, since it's not in
the bounds for T.
What instead would work is to change the language so that if type Type
implements Trait and all Trait methods take
Congratulations!
On Mon, Feb 3, 2014 at 10:11 PM, Tim Kuehn tku...@cmu.edu wrote:
Fantastic! Good luck, Nick!
On Mon, Feb 3, 2014 at 6:51 PM, Alex Crichton a...@crichton.co wrote:
Welcome Nick!
I can't wait to see that 1.0 issue count go down!
On Mon, Feb 3, 2014 at 6:20 PM, Brian
18 matches
Mail list logo
