From MCP 77: Charter for Deref Patterns Project Group

[chorman0773]

From MCP #77.

This proposes the charter for the Deref Patterns Project Group.

[joshtriplett]

Could you please inline a brief discussion of the exhaustiveness issue directly in the charter, rather than having it only in a linked document? The full details (including potential solutions) can still be off in the linked document, but the charter should clearly state the problems or potential problems.

[nikomatsakis]

Thanks for writing this up. I'm feeling torn. I think that this is an important ergonomic win -- it's a small, frustrating scenario.

On the other hand, I'm a bit concerned because I'm not sure if want to tackle the question of DerefPure at this time, but it seems to me that any real solution to this problem is going to have to have some ingredient like that.

This seems to be the key question for us:

• Who will be the liaison? (Is this @scottmcm?)
• Will we have the bandwidth to really look into the DerefPure design, and who needs to be involved in that?
• One thing that's coming to my mind -- what are the other uses for DerefPure?

[chorman0773]

Thank you for the feedback.
I have updated the charter accordingly.

[scottmcm]

Thanks for the updates! We had a long discussion (https://youtu.be/KNemhVm8kgA?t=35) about this in this week's lang team meeting (https://github.com/rust-lang/lang-team/blob/master/minutes/2021-02-09.md#mcp-deref-patterns-lang-team77).

There's some concern about how big a rabbit hole this might be opening with all the possible implications and tendrils. We'd like, before chartering this to know what it would mean to do this without DerefPure (https://youtu.be/KNemhVm8kgA?t=743). What are the objections that people would have to doing a version of this without that? What might we still be able to support without that? (For example, maybe it could still work for patterns that are irrefutable in the part being derefed, or support non-exhaustive patterns for things like if let.) Would the feature still be worth doing with just that? Are there any doors that we'd be closing if a version using just existing mechanisms where stabilized, keeping us from doing something "better" later?

[chorman0773]

So, DerefPure is one of the three possible solutions that were considered prior to the charter. It is the one that would allow for exhaustive matching with deref patterns for user-defined types. If it is not being pursued at this time, then that leaves either not having exhaustive deref patterns, or restricting deref patterns to standard library types or a subset thereof (or a possible combination of the two).
It would not leave persuing DerefPure or a different fourth option off the table forever; sometime after the first stage of the feature is complete and added by rfc, the project could be revisted and could be expanded to include DerefPure when the requirements for exhaustiveness are better understood.

[nikomatsakis]

@chorman0773 that sounds right -- the question I guess is whether you have interest in pursuing the parts of this that don't involve DerefPure? I would be ok with special-casing Box for sure, we already do that in the borrow checker so there is precedent. I'd probably be ok with special-casing other std types too, but not sure how others in the team feel.

[chorman0773]

I do not see an issue pursuing it for only standard library types at this time, as long as there is intent to expand it beyond there in the future. Ideally, in my opinion, it would extend further than just Box, but the exact subset is a question to be answered by the project (possibly consulting with T-libs).

[nikomatsakis]

We discussed this in the lang team meeting yesterday, and our consensus from the meeting was:

• We would like to see deref patterns pursued, and we think they should apply only to types whose deref is "pure".
• We want to limit the scope of this particular project to deref patterns, and not to figuring out a general notion of "pure deref". Therefore, it would be ok for now to use an attribute or some kind of private, perma-unstable trait that can be applied to types in the standard library. Later on, we might charter a group to expand this attribute/trait/whatever into a general mechanism that can be used for third-party types.
• We would also want to avoid trying to address "deref move" in this group, although we should not rule out the possibility of patterns that move out from a deref'able thing.
  • (We didn't specifically address whether patterns ought to be able to move from Box; my inclination would be yes, for consistency with the borrow checker, but that's not something we discussed in the meting.)
• We would prefer for now to leave types that are not known to have pure deref out of scope, rather than (for example) requiring an _. This is for a few reasons:
  • Capturing the standard library types is still very useful.
  • Being forced to add _ would be annoying and confusing. It's easier to explain to folks that, for now, this only works with types in the standard library.
  • That would also introduce the precedent of "impure" code running during pattern matching, which we have avoided thus far. It's not that having impure code run during pattern matching is necessarily a problem, but it's a step we'd prefer to consider later on (if at all).

@chorman0773 how does that sound to you?

[chorman0773]

That seems reasonable.
So then, would the question of how to ensure soundness be reduced to "which standard library types should qualify", and then the project group would answer that as well as the syntax question?

[chorman0773]

I've updated the charter to reflect that deref patterns for user-defined types are not being persued in this initial project.

[nikomatsakis]

@chorman0773 the project group would be writing up a plan for what the criteria are and some types that meet it. But going forward, new types will be added, so the criteria would be needed to decide if they too should support it.

(And of course, the final decision is made by lang/libs in the form of an RFC.)

[chorman0773]

Alright, thank you. I've reworded it to reflect that.