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

[Patrick Schluter]

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:
>> 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.
>

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.