Presumably these issues could be detected at runtime by having the compiler add checking logic into dev/debug builds.
The static approach used here may have the advantage of giving a more categorical assurance, i.e. one that doesn't depend on the particular behaviour exercised at runtime, but it requires annotations, meaning that:
1. It can't be used on an existing codebase lacking these annotations
2. It trusts the programmer to get the annotations right
(I'm not particularly well informed of recent developments in C++, perhaps such runtime instrumentation already exists?)
Does anyone actually want to clutter their code with such annotations? The example looks like something that should always warn or always generate an error, which makes this whole exercise seem that much worse.
You put it in library code so the callers don't have to see it.
I am always amused when a new C++ standard issues how many people complain "why did they add this obscure stuff and not my favourite feature?". Many of those changes are for library writers and don't have a lot of applicability for use in "normal" code. But everybody gets the benefit when the standard library speeds up or handles a non-obvious corner case.
I'm glad I could amuse you but your smugness is unwarranted. I am well aware that this is aimed at library writers but everyone probably should be getting warnings for this crap anyway. Tell me when you can opt me into the warning some other way besides polluting the code with more Byzantine compiler-specific annotations. Are there really so many false positives and legitimate uses of this behavior that you have to opt in on a function by function basis? I could accept that possibility but inquiring minds want to know that there isn't a better way to do this that truly maximizes the benefit of the new feature. I don't want to create more work for myself reading or writing annotations because there are already so many things to think about. The only time I could see myself using this annotation is if the code is so complex (possibly due to crap like this) that I can't tell if this one specific error can happen and I somehow remember this obscure feature that day.
Agreed, it's a day late and a dollar short for the kind of footgun that has been cocked and ready to shoot since forever. At least it's a small step in the right direction.
The static approach used here may have the advantage of giving a more categorical assurance, i.e. one that doesn't depend on the particular behaviour exercised at runtime, but it requires annotations, meaning that:
1. It can't be used on an existing codebase lacking these annotations
2. It trusts the programmer to get the annotations right
(I'm not particularly well informed of recent developments in C++, perhaps such runtime instrumentation already exists?)