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

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.

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