Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opt-in builtin traits #19

Closed
wants to merge 3 commits into from

Conversation

Projects
None yet
7 participants
@nikomatsakis
Copy link
Contributor

commented Mar 24, 2014

As originally proposed in my blog post.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Mar 24, 2014

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

@flaper87

This comment has been minimized.

Copy link

commented Mar 24, 2014

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

@cmr

This comment has been minimized.

Copy link
Member

commented Mar 24, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Mar 24, 2014

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 notifications@github.com
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 comment has been minimized.

Copy link
Member

commented Mar 24, 2014

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

This comment has been minimized.

Copy link

commented Mar 24, 2014

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

This comment has been minimized.

Copy link

commented Mar 25, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2014

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

On Tuesday, March 25, 2014, bill-myers notifications@github.com 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

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2014

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 pcwalton@mimiga.net wrote:

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

On Tuesday, March 25, 2014, bill-myers notifications@github.com 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

@cmr

This comment has been minimized.

Copy link
Member

commented Mar 25, 2014

(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 notifications@github.comwrote:

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 pcwalton@mimiga.net wrote:

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

On Tuesday, March 25, 2014, bill-myers notifications@github.com
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

This comment has been minimized.

Copy link
Member

commented Mar 25, 2014

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 comment has been minimized.

Copy link
Member

commented Mar 25, 2014

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

This comment has been minimized.

Copy link
Member

commented Mar 25, 2014

@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2014

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

This comment has been minimized.

Copy link

commented Mar 26, 2014

@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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 28, 2014

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

pnkfelix added a commit to pnkfelix/rfcs that referenced this pull request Oct 8, 2014

Fixed typos and format inconsistencies in headers of various RFCs.
In particular:

* The RFC associated with rust-lang#127 should have had a link to rust-lang#19 as well
  (and has been assigned RFC rust-lang#19); it also was revised to match the
  markdown href style of other RFCs.

* RFC rust-lang#34 needed its header entries filled in,

* RFC rust-lang#123 had a typo in its header, and

* RC rust-lang#155 was revised to match the markdown href style of other RFCs.

@chriskrycho chriskrycho referenced this pull request Dec 30, 2016

Closed

Wrong link in #0019 #1837

@chriskrycho chriskrycho referenced this pull request Feb 10, 2017

Closed

Document all features in the reference #38643

0 of 17 tasks complete

@chriskrycho chriskrycho referenced this pull request Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete

cramertj pushed a commit that referenced this pull request Mar 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.