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

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Oct 30 02:40:32 UTC 2021


On Sat, Oct 30, 2021 at 12:29:00AM +0000, Paul Backus via Digitalmars-d wrote:
> On Friday, 29 October 2021 at 21:16:49 UTC, H. S. Teoh wrote:
> > Array operations are OK if we view them as intrinsic, opaque
> > operations that the pure abstraction grants us.
> 
> My point is that in a systems-level language like D, where the side
> effects of memory allocation are directly observable from normal code
> [1][2], operations that allocate memory are *not* opaque, pure
> abstractions, and cannot possibly be "viewed" as such.

It can be, if such operations cannot be marked pure (they are certainly
not pure). I.e., if code marked `pure` is restricted to a subset of
operations, then it can be consistently optimized based on purity
assumptions.

It's the same idea as @safe.  D as a whole cannot be considered safe due
to operations like pointer arithmetic and untagged unions, but code
restricted to the @safe subset can.


> I understand that, historically, this kind of argument has
> (successfully) been used to justify things like `pureMalloc` and pure
> array concatenation, but the argument is based on a false premise, and
> always has been.
> 
> [1] https://dlang.org/phobos/core_memory.html#.GC.stats
> [2] https://dlang.org/phobos/core_memory.html#.GC.query

GC.stats / GC.query are impure operations, as are memory (de)allocation
operations, and should not be allowed in pure code.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG


More information about the Digitalmars-d mailing list