Destructors and wild-card patterns (when do destructors run?)

[catamorphism]

Context: #2735

I added a special-case to trans for let _ = e; where e has a destructor, so this gets treated the same way as e;. However, @nikomatsakis points out that this isn't an entirely satisfactory solution, because for consistency, we'd also want to drop the RHS of the tuple in let (x, _) = e; early, or indeed, any sub-component of a data structure that's bound to a pattern with a deeply-nested _ in the corresponding position.

Since we don't have a semantics for when destructors run, it's a little hard to say what the right thing is, but whatever we do should be consistent.

[eholk]

In general, I like the idea of always running destructors when the variable goes out of scope, although I don't think this will work so well for destructors in the heap. One of my common uses for destructors is to add some code that I want to be sure runs at function exit or failure. We get that now with let _x = e; but a lot of times I don't want to think of a name for this variable, so I'd rather write let _ = e.

[brson]

I also would prefer that the pattern acted as a variable that you can't refer to and it's scoping behaves like other variables.

[brson]

Oh, but I guess then in patterns you would end up with a bunch of extra copies.

[bblum]

@eholk I always use _z as the name for those. I'd go to _z1, _z2, etc if needed. :P

related #2735. it would be cool to be able to write do util::defer { ... code to run at end ... } and have it do as expected, instead of having to explicitly bind the result. i don't care all that much about this (and think we shouldn't provide util::defer if it has cryptic semantics)... but i expect people will try to do it anyway.

[nikomatsakis]

In general, @pcwalton wants destructors to run when a value is "dead" rather than explicitly at the end of scope. The reason for this being primarily to deal with moves, which currently require a hokey extra field in structs to record whether the struct was moved or not---though I could imagine a hybrid version where destructors ran at the end of scope, unless you move the value, in which case they would be destroyed as soon as you enter a path where the value is dead but will not be moved. For example, if you had an if and you move the value in the then branch but not the else, then upon entering the else branch the value would be destructed.

My feeling however is that D probably does this better than C++. Destruction in D, as I understand it, occurs sometime between the variable being dead and it going out of scope. If you want to tie the destructor execution to the scope, you use a scope keyword rather than giving the variable a name. This seems more reliable than C++, where it is common to do

AutoLock(theLock)

in place of

AutoLock lock(theLock)

the former of course creates a temporary and is probably not what you intended.

[eholk]

I like the idea of destroying a value when it becomes dead also. It'd be great not to have to zero things out to know whether to run the destructors.

[graydon]

This is reminiscent of the sequence-points and temporary-lifetimes issue we were discussing on IRC the other day. Needs a rigorous definition and rationale (including study of other languages), not things picked-at-random. It'll have far-reaching implications.

[bblum]

Revisiting this for triage. I feel like this is something that needs a group meeting to decide. Either options seems feasible:

• drop immediately only if the value is bound to _. Users can write let _z = thing if they want _z to persist.
• Force the user to make their value live as long as they need. A user would have to write let z = thing; intermediate code; z.finalize(); (with the understanding that z is finalized anyway if the task fails and unwinds).

I think the pros/cons between those two are all aesthetic.

[alexcrichton]

Nominating for closure, it sounds like the work from #11585 has fixed this, perhaps this is a dupe of #10488 now, or it's a subset of the remaining work on #3511

[pnkfelix]

@nikomatsakis can you weigh in on this matter? (deferring from this week's triage).

[pnkfelix]

as @alexcrichton summarized, work has already been done or is subsumed by #10488. Closing.