If you could make any changes to D, what would they look like?

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Nov 2 18:18:56 UTC 2021


On Sat, Oct 30, 2021 at 10:17:56AM +0000, Patrick Schluter via Digitalmars-d wrote:
> On Friday, 29 October 2021 at 21:56:10 UTC, Adam Ruppe wrote:
> > On Friday, 29 October 2021 at 21:16:49 UTC, H. S. Teoh wrote:
> > > Long story short, pureFree makes no sense
> > 
> > What about:
> > 
> > void foo() pure {
> >    int* a = malloc(5);
> >    scope(exit) free(a);
> > }
> foo is pure, but malloc and free aren't individually. If the
> declaration of the purity of foo is curtailed because malloc and free
> have to be marked as pure, then it is a failure of the language. In
> fact there should be an equivalent of @trusted for purity, telling the
> compiler "trust me, I know that that combination of impure functions
> is on a whole pure". Marking malloc/free as pure doesn't cut it as
> these functions cannot, by definition, be pure individually.

Exactly, we need an escape hatch to tell the compiler "this sequence of
operations are individually impure, but as a whole they are pure".  Just
like a sequence of pointer arithmetic operations are individually
unsafe, but if properly constructed they may, as a whole, be @safe, so
we have @trusted for that purpose.


> But I start to understand where this abomination of purity comes from.
> Transitivity. I suspect that applying transitivity unthinkingly is not
> such a good idea as can be seen also with const (immutable is
> transitive as it describes a property of the data, const is not as it
> is a property of the means to access the data, not the data itself).

But how else can pure be implemented?  If we remove transitivity from
pure, then it essentially becomes an anemic recommendation for
programming by convention, rather than something enforceable by the
compiler.  Sometimes an escape hatch is needed, but that doesn't mean
the rest of the time we can just get away with whatever we want.


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth


More information about the Digitalmars-d mailing list