Autoreferencing copy types

[nikomatsakis]

This is a specific issue to track the changes proposed by @cramertj in RFC 2111. We decided to roll this into a larger experiment around coercions, generics, and Copy type ergonomics and are therefore ready to implement (but not yet stabilize).

[emberian]

I'd like to experiment with this.

[nikomatsakis]

@cmr woot! Let me know if you'd like some kind of mentoring help.

[H2CO3]

Will it be at all possible to opt out of this if stabilized? I recently saw that this is planned in 1.27, and I'm sharing very strong concerns with arielb1, repax, and est31 about the loss of explicitness and readability.

[est31]

I recently saw that this is planned in 1.27

Where did you see that? That would be a pretty hasty addition.

The last I've heard was that this feature is going to be added on an experimental basis during the impl period. Now that the impl period is long over, I hope we can put this matter at rest now and close the issue.

[H2CO3]

@est31 page 17 in these slides: https://twitter.com/jdub/status/978253005198782464

[est31]

I hope there is a mistake or misunderstanding somewhere... I just can't believe that they have agreed onto doing this behind closed doors and are now pulling it through without asking the community or even an accepted RFC. It doesn't even seem to be implemented yet. New features always must go through one version as a nightly feature before they become stable.... And the 1.26 release is branched on beta or close to being branched. So the release where it is unstable must be the 1.27 one, with 1.28 the first release where it can be stable. This won't happen unless not just one, but multiple policies are violated. So I believe there is a mistake somewhere, I really hope.

[H2CO3]

Sure, I might have misunderstood the meaning of that spreadsheet — still, my comments hold regardless of when these features are intended to be rolled out.

[aturon]

@est31 You are correct not to believe that, since of course no such thing could or would happen.

We've recently been putting together a tracking spreadsheet for Rust 2018, which has a lot of moving parts, and trying to triage these things weekly. The entries on this sheet are aspirational; almost all of them involve some level of consensus process (around stabilization at least), and a couple still need RFC work. I'm not sure why 1.27 was listed as the aspirational release here, since (I agree) that's not really feasible at this point.

[H2CO3]

@aturon thanks for the clarification!

[nikomatsakis]

Hello all! I'm the one who put 1.27 there. I believe what I had in mind was that this was when I hoped to some experimental impl available -- though tbh, I think I was quite confused, because I was really referring to #45683, the lint for undesirable copies, and not to the changes in this line.

[nikomatsakis]

In any case, sorry for the confusion, I shouldn't have overloaded the field. =)

[H2CO3]

@nikomatsakis I guess it's OK as long as you include a discriminant field too 😉

[steveklabnik]

So, visiting this for triage; none of this ended moving forward, right? What do we do about this ticket?

[pwnorbitals]

Triage again; @steveklabnik @nikomatsakis It looks like this issue is not going forward. A decision should be taken

[scottmcm]

Given the op mentions rolling this into #44619 (comment), I'll close this based on the FCP close in that other issue.

If anyone else shows up here, lang is still potentially interested in experiments in this area, but since nothing's happening right now this issue being open doesn't help. Feel free to drop by zulip and chat about things!