@nodiscard and @live have something in common
Max Haughton
maxhaton at gmail.com
Fri Dec 11 23:19:30 UTC 2020
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)
More information about the Digitalmars-d
mailing list