www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - nodiscard and live have something in common

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)
Dec 11 2020