for initial release, limit two phase borrows to method-call autorefs #46747
Comments
|
cc #46037 |
|
To be clear, we do not think that this aspect of two-phase borrows needs to block the initial release of |
|
In my work on #46908, it seems like we have a choice: Either:
at this point we have a series of NLL milestones on the path to stabilization, so we should decide where this falls in that sequence anyway. |
|
Given the large number of tests affected, it seems pretty clear to me that we ought to make this change if we are going to make it. That is, unless we plan to make two-phase borrowing part of the model we expect to teach users -- which might be ok but seemed like something we wanted to be cautious about -- then I feel confident we need to impose restrictions, or else people will be stumbling across it all the time. In other words, I kind of think we should do this first so that we don't have to edit a bunch of tests. |
NLL: Limit two-phase borrows to autoref-introduced borrows This imposes a restriction on two-phase borrows so that it only applies to autoref-introduced borrows. The goal is to ensure that our initial deployment of two-phase borrows is very conservative. We want it to still cover the `v.push(v.len());` example, but we do not want it to cover cases like `let imm = &v; let mu = &mut v; mu.push(imm.len());` (Why do we want it to be conservative? Because when you are not conservative, then the results you get, at least with the current analysis, are tightly coupled to details of the MIR construction that we would rather remain invisible to the end user.) Fix #46747 I decided, for this PR, to add a debug-flag `-Z two-phase-beyond-autoref`, to re-enable the more general approach. But my intention here is *not* that we would eventually turn on that debugflag by default; the main reason I added it was that I thought it was useful for writing tests to be able to write source that looks like desugared MIR.
@nikomatsakis is concerned that two-phased borrows are a hazard. In particular, they are coupled to MIR code-generation, which means if we are too aggressive in how much code we accept today, it could mean that a later change to MIR construction will inject a regression.
Niko has suggested a simple strategy for fixing this that we should deploy before we stabilize two-phase borrows: We should thread through information about whether a borrow was introduced via method-call autoref, and then only do the two-phase borrow system for those autorefs.
That way we will be somewhat conservative in what code is deemed acceptable by two-phase borrows today, and therefore give us more breathing room in the future as we refine the system.
The text was updated successfully, but these errors were encountered: