I come to the same conclusion as John, but from a slightly different angle.
First, I'm not thrilled with the idea of specifying TWR via desugaring at all; it means that accidental artifacts of specification end up being weighted too seriously. But I also think that TWR suffers from failure of imagination (it is too IO-specific) and also that it suffers from other accidental issues (such as, using an interface for AC, which forces us to pick a name that might be great for IO but lousy for arbitrary resources. A type class would be better, when we have them.)
So I would prefer to raise our sights on TWR towards the construct we would like to work towards (just as we raised up switch from the gutter of byte-stream parsing).
I think the opposite on this one. It seems to me that using |_| is an excellent way to mute that warning. I find it annoyingly opinionated: Why shouldn’t I expect to use TWR to simulate the RAII-style open/close events from C++, without lint bumping my elbow?If we allow '_', it means that we are in a way able to call _.close().The documentation for desugaring TWR can just introduce a new name if necessary; the JLS introduces unnamed temps all the time and this is just another place for one.The other case is the case (2), should we allow '_' in a middle of an init list, i think that like with 'var' we should not allow '_' in an init list. So reject int x, _; I agree.
