Feature gate box patterns

[ghost]

Rendered view

---

Update: RFC was accepted, text: https://github.com/rust-lang/rfcs/blob/master/text/0469-feature-gate-box-patterns.md

[Thiez]

I see no real advantage to moving box patterns behind a feature gate now. Either there is a breaking change in the future if the other RFC is accepted, or there is a breaking change now even if no box-renaming related RFC is accepted.

If box is renamed fixing code will be a simple find and replace. If we feature gate box that fix will still be required in the event of a renaming.

[steveklabnik]

If this does not get fixed at 1.0, it will only be available in night lies, allowing for a breaking change. If it's not behind a gate, no breaking change will be possible.

[ftxqxd]

I’m not sure that feature gating is necessary here. The Box type already has a lot of special casing, and it doesn’t look like we’re trying to remove that before 1.0. So I don’t think that having a special case of box pattern for Box would be a problem post-1.0, even if box patterns were extended to other library types. In other words: I don’t see why we’d need to treat Box the same as other pointers with regard to box patterns.

[zwarich]

@P1start The goal for 1.0 is to remove / feature-gate any special-case behavior for Box that couldn't be implemented for a user-defined type. Even though it will still be special-cased in the compiler, the hope is that it will be possible to remove all special cases in the compiler after 1.0.

[ftxqxd]

@zwarich That’s certainly the first I’ve heard of that. Does that mean that moving out of Boxes will be feature-gated as well (or DerefMove added)? If so, I would personally expect such a mass feature-gating to be done in a single RFC, not spread out among multiple RFCs that on their own seem rather lacking in motivation (at least from my perspective).

[zwarich]

@P1start RFC 130 limited dereferencing and moving out of boxes so that it could be implemented by a future DerefMove trait. I implemented that RFC, so if you know of a hole in it please let me know.

As far as I know, this PR represents the only open issue with Box futureproofing that requires an RFC. And even then it isn't because of any particular issue that was found, just that people haven't had enough time to think about the future-proofing of box patterns before 1.0.

[ftxqxd]

@zwarich Well, there is rust-lang/rust#14270, which isn’t related to DerefMove but still could not be done by a library type unless we got &uniq pointers and DerefUniq post-1.0, adding extra complication to the language. That’s been recently re-nominated, so it’s not so bad, but it still hasn’t had much attention paid to it.

I interpreted your original comment as saying that any feature at all that Box has that’s not currently implementable by a library type should be feature-gated, but your recent comment seems to suggest that you mean any feature of Box that could not be extended backwards-compatibly to library types post-1.0. In that case, my second comment above is irrelevant (apart from my point about rust-lang/rust#14270, which will hopefully be dealt with separately).

[zwarich]

@P1start I've been working on a PR for rust-lang/rust#14270, although it is turning out to be more annoying than I expected. And yes, I meant things that we could implement in a backwards compatible way after 1.0. Obviously, there is more risk of not actually being backwards compatible when speaking hypothetically, but that's something we have to live with.

[zwarich]

We discussed this RFC this week in the Rust weekly meeting. Everyone present was in favor of feature-gating box patterns so that we can spend more time in the future to develop a solution that works correctly with user-defined types. This is not expected to result in a significant decrease of expressiveness in the stable language.

As per the evolving changes to the RFC process, the discussion is being summarized here before merging the RFC so that anyone can comment if they feel that their opinion was not properly represented (by me, in this case).

[nikomatsakis]

I'm taking over this RFC. Given the previous discussion I think the time is ripe to accept this RFC.

[sanmai-NL]

@steveklabnik: The link to the RFC in the OP is broken. Am I correct to assume you would be the one to fix it? Not sure how you could, since the poster’s account has been deleted.

[pnkfelix]

One can fix it by pointing to the blob that remains in the local repo instead of the poster's. Which I will do now.

[pnkfelix]

Also, for RFCs that have been accepted, a more traditional useful fix is to add a link to the text file in the rfcs repo itself, so that people who follow the link will see any future amendments/updates to that text.

Which I will do now.