Consider that under the current live (DIP1021) semantics, a mutable pointer must not reach the end of any given control flow without being consumed: This is effectively @nodiscard's cousin, i.e. we have to do something with the pointer to make it become considered not our problem anymore.

We seem to have consensus that D needs some way of properly dealing with ownership in memory safety. Pointer analysis alone is, however, not good enough - eventually other things will need to be tracked, or @live will only be useful for very short runs of code. Particularly, it will have to remain intraprocedural. This is clearly insufficient, and limiting.

Interprocedural analysis will probably require some changes/additions to the type system to accommodate the semantics, so that we can not only ascribe ownership semantics to things like (say) borrowing a subset of a range safely and cleanly while preventing unsafe behaviour.

The reason why I mention @nodiscard, is because if we move beyond merely borrowing (or even safety if you will), we could try to aim for (in-effect) dataflow guarantees in the type system (that is, @nodiscard would be an example of this behaviour, and pointer analysis would be a subset of the same semantics). This would obviously require the same conservative restrictions as ownership does now, but this is not too limiting (especially when combined with the quasi- abstract interpretation the implementation in ob.d does already).

I don't claim to have a concrete proposal, but this could claim to kill memory corruption, exceptions, and large amounts of GC use with one feature rather than lots of little DIPs (ARC probably needs to be a "factory" supported option for D to do well in the future)