Opt-in builtin traits

[nikomatsakis]

As originally proposed in my blog post.

[nikomatsakis]

ping @brson @alexcrichton @pcwalton, to best of my memory, this is what we discussed in the work week.

[flaper87]

@cmr I know you had some thoughts to share about this.

[emberian]

So after thinking about it and re-reading the RFC, I think it's good, but the second downside concerns me a lot. OIBIT also means that in one's own programs extra annotations are needed to use their own types. My first thought was to have a #[deriving(builtins)], which would act like today's behavior, but explicitly annotated.

My other thought was to allow implementations of built-in traits, but not require them. But if you specify any of them, none of the others would be inferred. Additionally, anything marked stable wouldn't have builtins inferred ever. This needs no extra annotations for simple uses, but loses the (very nice) pedagogy and simplicity properties.

I wouldn't mind this RFC being accepted but I still worry a lot about 3rd party libraries being sloppy and making life very hard for certain users.

[pcwalton]

I'd prefer to do it all the way or not do it at all rather than halfway do
it.

On Monday, March 24, 2014, Corey Richardson [email protected]
wrote:

So after thinking about it and re-reading the RFC, I think it's good, but
the second downside concerns me a lot. OIBIT also means that in one's own
programs extra annotations are needed to use their own types. My first
thought was to have a #[deriving(builtins)], which would act like today's
behavior, but explicitly annotated.

My other thought was to allow implementations of built-in traits, but not
require them. But if you specify any of them, none of the others would be
inferred. Additionally, anything marked stable wouldn't have builtins
inferred ever. This needs no extra annotations for simple uses, but loses
the (very nice) pedagogy and simplicity properties.

I wouldn't mind this RFC being accepted but I still worry a lot about 3rd
party libraries being sloppy and making life very hard for certain users.

—
Reply to this email directly or view it on GitHub.<
https://ci5.googleusercontent.com/proxy/ghgjjMUQ9iUgH6cgQMUK_vgjoRlDzGTSfX2tOFcg0hqSznz_GrOjMBhL0QgPb9BVpY9uLEP0uV-hRv_IjpfiaPDi6D_WeIzKbD9IPT_r_KseuzlbEP1aQVVgaUpfIRhT4MlsMKQtdiowFwuLTCKlqBjTX-JeOA1CQMKq6i_bbPb2VWMwKYtvnen49d1so2hKZITpC68sAYGhUzOy61EuylQuAUXv3v_C55gC6VEq0osYa9VIVPE1XfMV_D0jRsAwbgOg6Lbj8XtMM4gzwXyoYh-mMzk-=s0-d-e1-ft#https://github.com/notifications/beacon/157897__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMTI5Njc4MywiZGF0YSI6eyJpZCI6MjgzNzIzNzh9fQ==--99bc149cfe055d4dd63f311c8b091c193e251e81.gif

[alexcrichton]

This has my humble +1, I don't think this is a silver bullet, but when weighing the tradeoffs between today's system and this proposal, I believe that this proposal wins out.

[flaper87]

Finally got the time to read through the proposal. I was already pretty convinced of the benefits of having opt-in traits, despite the downsides this brings. The RFC is well written and the remaining open questions can be addressed with follow-up enhancements to this RFC. FWIW, this gets my +1

[bill-myers]

I think this RFC gives way too little attention to the issues of verbosity of declarations and libraries forgetting to implement traits, which are at least as important as consistency, API stability, pedagogy and safety, and are not really satisfactorily addressed, since after this RFC making a "simple" struct is far more verbose than right now.

In general, while making Copy explicit seems a good idea, it doesn't really seem clear that there are many use cases for explicitly not having Share or Send in any type defined outside core libraries.

The fact that Clone and Eq are opt-ins is merely the current situation, and while making everything explicit is a way of making things consistent, making Clone and Eq implicit as well (at least in some cases) would make things consistent as well.

Perhaps we need several types of structs where one type has all implicit by default, and other types have less things or nothing implicit (maybe one for pure data aggregation, another for objects with invariants, another for objects with invariants and methods with unsafe side effects, etc.), where the "types" could either be built-in concepts or traits inheriting a bunch of kinds allowing to declare all of them at once, or perhaps names for groups of kinds to implicitly implement, but only if possible.

And at any rate, the syntax should be minimal and without additional alphanumeric tokens, like struct Foo : Copy, Share, instead of using impl or deriving.

[pcwalton]

They are satisfactorily addressed. We already need this for deriving.

On Tuesday, March 25, 2014, bill-myers [email protected] wrote:

I think this RFC gives way too little attention to the issues of
verbosity of declarations and libraries forgetting to implement traits,
which are at least as important as consistency, API stability, pedagogy and
safety, and are not really satisfactorily addressed, since after this RFC
making a "simple" struct is far more verbose than right now.

In general, while making Copy explicit seems a good idea, it doesn't
really seem clear that there are many use cases for explicitly not having
Share or Send in any type defined outside core libraries.

The fact that Clone and Eq are opt-ins is merely the current situation,
and while making everything explicit is a way of making things consistent,
making Clone and Eq implicit as well (at least in some cases) would make
things consistent as well.

Perhaps we need several types of structs where one type has all implicit
by default, and other types have less things or nothing implicit (maybe one
for pure data aggregation, another for objects with invariants, another for
objects with invariants and methods with unsafe side effects, etc.), where
the "types" could either be built-in concepts or traits inheriting a bunch
of kinds allowing to declare all of them at once, or perhaps names for
groups of kinds to implicitly implement, but only if possible.

And at any rate, the syntax should be minimal and without additional
alphanumeric tokens, like struct Foo : Copy, Share, instead of using impl
or deriving.

—
Reply to this email directly or view it on GitHub.<
https://ci5.googleusercontent.com/proxy/41e-Kh_8yzC-7O19m1M4-cHWGjZUDLJUUSpDG3tSNOPGxTflnILQeJKGHhhi2BPONvWimtvouUpvjlGeljv9jZAsZ8o7tYHgS6wrBMkjmox7M4GEFCwPFDf7d_1vVXBM9Gcdq-HGGUVzQqBEe2VzshkbloXBhTOMjANX7CSCT4Gs6HVgiXWzOpzR3Ho0JrLmkv-NacZZK2vPBn0YM4MewmbqTfMsFPGFc53EWl7OAu7iMvRUTPNCfQXW_BiUlBYlSF1ux4uaCefxTBsHF9KyjZOAgHb0=s0-d-e1-ft#https://github.com/notifications/beacon/157897__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMTQwMjQzMSwiZGF0YSI6eyJpZCI6MjgzNzIzNzh9fQ==--0210a8e2bb4af778f2b9d27ff6bdc2766300cd21.gif

[pcwalton]

Err, we already have this issue with deriving. I really want opt-in because
it's very confusing to hunt down the thing that didn't cause something to
implement Send.

On Tuesday, March 25, 2014, Patrick Walton [email protected] wrote:

They are satisfactorily addressed. We already need this for deriving.

On Tuesday, March 25, 2014, bill-myers [email protected] wrote:

I think this RFC gives way too little attention to the issues of
verbosity of declarations and libraries forgetting to implement traits,
which are at least as important as consistency, API stability, pedagogy and
safety, and are not really satisfactorily addressed, since after this RFC
making a "simple" struct is far more verbose than right now.

In general, while making Copy explicit seems a good idea, it doesn't
really seem clear that there are many use cases for explicitly not having
Share or Send in any type defined outside core libraries.

The fact that Clone and Eq are opt-ins is merely the current situation,
and while making everything explicit is a way of making things consistent,
making Clone and Eq implicit as well (at least in some cases) would make
things consistent as well.

Perhaps we need several types of structs where one type has all implicit
by default, and other types have less things or nothing implicit (maybe one
for pure data aggregation, another for objects with invariants, another for
objects with invariants and methods with unsafe side effects, etc.), where
the "types" could either be built-in concepts or traits inheriting a bunch
of kinds allowing to declare all of them at once, or perhaps names for
groups of kinds to implicitly implement, but only if possible.

And at any rate, the syntax should be minimal and without additional
alphanumeric tokens, like struct Foo : Copy, Share, instead of using impl
or deriving.

—
Reply to this email directly or view it on GitHub.<
https://ci5.googleusercontent.com/proxy/41e-Kh_8yzC-7O19m1M4-cHWGjZUDLJUUSpDG3tSNOPGxTflnILQeJKGHhhi2BPONvWimtvouUpvjlGeljv9jZAsZ8o7tYHgS6wrBMkjmox7M4GEFCwPFDf7d_1vVXBM9Gcdq-HGGUVzQqBEe2VzshkbloXBhTOMjANX7CSCT4Gs6HVgiXWzOpzR3Ho0JrLmkv-NacZZK2vPBn0YM4MewmbqTfMsFPGFc53EWl7OAu7iMvRUTPNCfQXW_BiUlBYlSF1ux4uaCefxTBsHF9KyjZOAgHb0=s0-d-e1-ft#https://github.com/notifications/beacon/157897__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMTQwMjQzMSwiZGF0YSI6eyJpZCI6MjgzNzIzNzh9fQ==--0210a8e2bb4af778f2b9d27ff6bdc2766300cd21.gif

[emberian]

(Not that the error reporting couldn't be improved without this. But I'm in
favor)

On Tue, Mar 25, 2014 at 5:35 PM, Patrick Walton [email protected]:

Err, we already have this issue with deriving. I really want opt-in
because
it's very confusing to hunt down the thing that didn't cause something to
implement Send.

On Tuesday, March 25, 2014, Patrick Walton [email protected] wrote:

They are satisfactorily addressed. We already need this for deriving.

On Tuesday, March 25, 2014, bill-myers [email protected]
wrote:

I think this RFC gives way too little attention to the issues of
verbosity of declarations and libraries forgetting to implement traits,
which are at least as important as consistency, API stability, pedagogy
and
safety, and are not really satisfactorily addressed, since after this RFC
making a "simple" struct is far more verbose than right now.

In general, while making Copy explicit seems a good idea, it doesn't
really seem clear that there are many use cases for explicitly not having
Share or Send in any type defined outside core libraries.

The fact that Clone and Eq are opt-ins is merely the current situation,
and while making everything explicit is a way of making things consistent,
making Clone and Eq implicit as well (at least in some cases) would make
things consistent as well.

Perhaps we need several types of structs where one type has all
implicit
by default, and other types have less things or nothing implicit (maybe
one
for pure data aggregation, another for objects with invariants, another
for
objects with invariants and methods with unsafe side effects, etc.), where
the "types" could either be built-in concepts or traits inheriting a bunch
of kinds allowing to declare all of them at once, or perhaps names for
groups of kinds to implicitly implement, but only if possible.

And at any rate, the syntax should be minimal and without additional
alphanumeric tokens, like struct Foo : Copy, Share, instead of using impl
or deriving.

—
Reply to this email directly or view it on GitHub.<

https://ci5.googleusercontent.com/proxy/41e-Kh_8yzC-7O19m1M4-cHWGjZUDLJUUSpDG3tSNOPGxTflnILQeJKGHhhi2BPONvWimtvouUpvjlGeljv9jZAsZ8o7tYHgS6wrBMkjmox7M4GEFCwPFDf7d_1vVXBM9Gcdq-HGGUVzQqBEe2VzshkbloXBhTOMjANX7CSCT4Gs6HVgiXWzOpzR3Ho0JrLmkv-NacZZK2vPBn0YM4MewmbqTfMsFPGFc53EWl7OAu7iMvRUTPNCfQXW_BiUlBYlSF1ux4uaCefxTBsHF9KyjZOAgHb0=s0-d-e1-ft#https://github.com/notifications/beacon/157897__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMTQwMjQzMSwiZGF0YSI6eyJpZCI6MjgzNzIzNzh9fQ==--0210a8e2bb4af778f2b9d27ff6bdc2766300cd21.gif

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/19#issuecomment-38624000
.

http://octayn.net/

[sfackler]

I am concerned that this will be another thing that library authors will forget to do, but I guess we can try it and see how it turns out. There is the Unsafe escape hatch worst-case I guess.

[alexcrichton]

This proposal has been in discussion for quite some time now, and the core team is all in favor of merging this. This is not meant to be a magical fix and solve all problems, this is a question of tradeoffs.

Merged as 79992d6

[alexcrichton]

Relevant discussion in today's meeting: https://github.com/mozilla/rust/wiki/Meeting-weekly-2014-03-25#opt-in-traits

[nikomatsakis]

On Tue, Mar 25, 2014 at 02:33:50PM -0700, bill-myers wrote:

And at any rate, the syntax should be minimal and without additional
alphanumeric tokens, like struct Foo : Copy, Share, instead of
using impl or deriving.

I just saw this portion of your comment now, sorry. I initially found
this syntax appealing, but it fails to take generic types into
account. For example, being able to write impl<T:Send> Share for Mutex<T> is valuable. Moreover, I do think there is value in treating
Copy and friends exactly like other traits. I suspect most structs
that use (e.g.) Copy might also make use of Eq eventually, and
hence they will have a #[deriving] block regardless.

[bill-myers]

@nikomatsakis Well, we could remove #[deriving] and make struct T: Foo do what #[deriving] does now, and thus also work for Eq, etc.

You could still impl manually like now with deriving.

[nikomatsakis]

On Wed, Mar 26, 2014 at 12:28:07PM -0700, bill-myers wrote:

@nikomatsakis Well, we could remove #[deriving] and make struct T: Foo do what #[deriving] does now, and thus also work for Eq, etc.

You could still impl manually like now with deriving.

We could. That seems like a separate RFC. I personally prefer the
attribute syntax, which emphasizes to me that this is "just a macro".

Niko