On Sat, Mar 1, 2014 at 9:07 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote:
I'm also slightly concerned that #[deriving(Data)] gives the
impression that there's a trait Data, so maybe that should be
lowercased as in
On Sat, Mar 1, 2014 at 8:24 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Fri, Feb 28, 2014 at 10:36:11PM +0100, Gábor Lehel wrote:
I don't see the difference here. Why do you think this should be handled
differently?
To be honest I hadn't thought about it before. I agree there is no
On 01/03/14 07:23, Kevin Ballard wrote:
I'm also slightly concerned that #[deriving(Data)] gives the impression that
there's a trait Data, so maybe that should be lowercased as in
#[deriving(data)], or even just #[deriving(builtin)], but this is a lesser
concern and somewhat bike-sheddy.
I
On Fri, Feb 28, 2014 at 10:36:11PM +0100, Gábor Lehel wrote:
I don't see the difference here. Why do you think this should be handled
differently?
To be honest I hadn't thought about it before. I agree there is no
fundamental difference, though there may be a practical one. I have to
mull this
On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote:
I'm also slightly concerned that #[deriving(Data)] gives the
impression that there's a trait Data, so maybe that should be
lowercased as in #[deriving(data)], or even just
#[deriving(builtin)], but this is a lesser concern and
I like this
2014年3月2日 上午4:07于 Niko Matsakis n...@alum.mit.edu写道：
On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote:
I'm also slightly concerned that #[deriving(Data)] gives the
impression that there's a trait Data, so maybe that should be
lowercased as in #[deriving(data)], or
I must admit I really like the *regularity* this brings to Rust. There is
nothing more difficult to reason about that an irregular (even if
reasonable) interface simply because one must keep all the rules in mind at
any time (oh and sorry, there is a special condition described at page 364
that
On Fri, Feb 28, 2014 at 09:38:18PM +0100, Matthieu Monrocq wrote:
The main issue with the lint as you proposed is that if I *want* a linear
type without any property, the lint will continuously bug me. Thus the idea
of #[deriving(None)] (or whatever name) to shut the lint down, because once
On Friday, February 28, 2014 at 11:15 AM, Matthieu Monrocq wrote:
Maybe one way of preventing completely un-annotated pieces of data would be a
lint that just checks that at least one property (Send, Freeze, ...) or a
special annotation denoting their absence has been selected for each
(My idea for the lint was `#[allow_kind(Name)]`
, which someone on IRC remarked as opt-out opt-in builtin traits
On Fri, Feb 28, 2014 at 4:36 PM, Gábor Lehel glaebho...@gmail.com wrote:
I think this is a really great idea.
There's another potential compromise that would preserve most of its
On Feb 28, 2014, at 8:10 PM, Kang Seonghoon some...@mearie.org wrote:
2014-03-01 6:24 GMT+09:00 John Grosen jmgro...@gmail.com:
On Friday, February 28, 2014 at 11:15 AM, Matthieu Monrocq wrote:
Maybe one way of preventing completely un-annotated pieces of data would be
a lint that just
11 matches
Mail list logo
