I agree, this is the best solution to the problem I think.
On Fri, Jul 19, 2013 at 4:28 PM, Niko Matsakis wrote:
> On Thu, Jul 18, 2013 at 03:28:02PM -0400, Benjamin Striegel wrote:
>> I think at the least we should offer a #[deriving(Basics)] for use on
>> public types so that people aren't forc
On Thu, Jul 18, 2013 at 03:28:02PM -0400, Benjamin Striegel wrote:
> I think at the least we should offer a #[deriving(Basics)] for use on
> public types so that people aren't forced to memorize "Eq Ord TotalOrd
> TotalEq IterBytes Clone" (unless we can find a silly SFINAE-esque
> acronym... http:/
On 19/07/13 05:39, Corey Richardson wrote:
On Thu, Jul 18, 2013 at 3:33 PM, Daniel Micay wrote:
Plenty of types can't actually be ordered, and in *many* cases not all
fields should be considered for equality/ordering and they may or may
not be listed in the order the comparison should try.
I'
On Thu, Jul 18, 2013 at 3:39 PM, Corey Richardson wrote:
> On Thu, Jul 18, 2013 at 3:33 PM, Daniel Micay wrote:
>> Plenty of types can't actually be ordered, and in *many* cases not all
>> fields should be considered for equality/ordering and they may or may
>> not be listed in the order the comp
On Thu, Jul 18, 2013 at 3:33 PM, Daniel Micay wrote:
> Plenty of types can't actually be ordered, and in *many* cases not all
> fields should be considered for equality/ordering and they may or may
> not be listed in the order the comparison should try.
>
I've wanted like #[deriving(Ord(a, b), Eq
On Thu, Jul 18, 2013 at 3:28 PM, Benjamin Striegel
wrote:
> I think at the least we should offer a #[deriving(Basics)] for use on public
> types so that people aren't forced to memorize "Eq Ord TotalOrd TotalEq
> IterBytes Clone" (unless we can find a silly SFINAE-esque acronym...
> http://www.wor
I think at the least we should offer a #[deriving(Basics)] for use on
public types so that people aren't forced to memorize "Eq Ord TotalOrd
TotalEq IterBytes Clone" (unless we can find a silly SFINAE-esque
acronym... http://www.wordsmith.org/anagram/anagram.cgi?anagram=eottic ).
On Thu, Jul 18,
On Thu, Jul 18, 2013 at 3:06 PM, Corey Richardson wrote:
> On Thu, Jul 18, 2013 at 2:15 PM, Brian Anderson wrote:
>>
>> I disagree with the premise. There are any number of valid traits that
>> library authors can forget to implement. Clone isn't special here.
>>
>
> Thinking about it more over l
On 7/18/13 12:06 PM, Corey Richardson wrote:
Thinking about it more over lunch I came to the same conclusion: we
need a generic way to automatically derive trait implementations for
types which are eligible. #[deriving(Eq, Ord, TotalOrd, TotalEq,
IterBytes, Clone)] should be the default. Almost e
On Thu, Jul 18, 2013 at 2:15 PM, Brian Anderson wrote:
>
> I disagree with the premise. There are any number of valid traits that
> library authors can forget to implement. Clone isn't special here.
>
Thinking about it more over lunch I came to the same conclusion: we
need a generic way to automa
On 07/18/2013 04:24 AM, Corey Richardson wrote:
So with decopy landed we now have no way to copy things that does not
require author intervention. And I am ok with this! Clone is much more
flexible, less magic, etc. I see one problem with this though: we have
no way to copy things that does not r
On Thu, Jul 18, 2013 at 7:24 AM, Corey Richardson wrote:
> So with decopy landed we now have no way to copy things that does not
> require author intervention. And I am ok with this! Clone is much more
> flexible, less magic, etc. I see one problem with this though: we have
> no way to copy things
Right, we already have opt-out, and having elementary functions like Clone
predefined also has precedence in other languages. See java and the
overwritable clone() method on Object for example.
Am 18.07.2013 15:36 schrieb "Benjamin Striegel" :
> I agree that this is a huge headache waiting to happ
> I'm hitting this in workcache and json now. Stuff that the author didn't
> think to make cloneable or comparable impls for. Since I'm in the same
> source tree now I can fix it, but if it was in a different crate I didn't
> control, I'd be out of luck.
After converting Servo to Rust 0.6, I had t
On 13-07-18 06:36 AM, Benjamin Striegel wrote:
I agree that this is a huge headache waiting to happen. It's our own
version of the const-correctness problem.
It also occurs with other "obvious utility impls" like totalord and
iterbytes, when someone decides to use a struct as a key in a hash o
I agree that this is a huge headache waiting to happen. It's our own
version of the const-correctness problem.
We do already have a notion of "opt-out" kinds via #[no_freeze] and
#[no_send], so this isn't entirely unprecedented.
It would also be good to know how often one needs custom copy behavi
So with decopy landed we now have no way to copy things that does not
require author intervention. And I am ok with this! Clone is much more
flexible, less magic, etc. I see one problem with this though: we have
no way to copy things that does not require author intervention.
For example, I ran in
17 matches
Mail list logo
