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

[H. S. Teoh]

On Tue, Nov 02, 2021 at 08:25:21PM +0000, Patrick Schluter via Digitalmars-d wrote:
> On Tuesday, 2 November 2021 at 18:18:56 UTC, H. S. Teoh wrote:
> > On Sat, Oct 30, 2021 at 10:17:56AM +0000, Patrick Schluter via
> > Digitalmars-d wrote:
[...]
> > > 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 [...].
> > 
> > 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.
> 
> Yes, pure should be transitive (+- escape hatch). What I meant by my
> "unthinkingly" was that in that case, the transitivity requirement
> pushed the author to do the wrong thing and mark malloc/free as pure.
> This would have not been that severe if these functions had remained
> private and not leaked out of the englobing purity scope. The
> primordial sin here is that the symbols, with their abominable purity,
> escaped of its locality.

These functions (malloc/free) should not have been marked pure in the
first place. Even the more they should not have been made *public*, or
made it into the standard library.  pureMalloc/pureFree are abominations
that ought to be killed with fire and extreme prejudice.

Instead, there should have been an escape hatch that the *caller* of
malloc/free should have used to indicate that it is pure. The compiler
cannot statically verify this, so it must be the purity equivalent of
@trusted: the compiler just has to take the programmer's word for it.

When pure is transitive (a good thing) but there's no escape hatch (a
bad thing), the result is abominations like pureFree.


T

-- 
Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton