On Saturday, 13 November 2021 at 09:37:41 UTC, Timon Gehr wrote:
> On 11/13/21 10:06 AM, tsbockman wrote:
>>  [...]
>
> Yes, the documentation around qualifiers is pretty incomplete in general, which is one of the problems plaguing this discussion. The specification does clearly state that Paul's trick is not allowed though.
>
> NB: This is the relevant bit of DMD source code:
> https://github.com/dlang/dmd/blob/master/src/dmd/dcast.d#L856-L872

Who can improve the documentation?

On 13/11/2021 11:06 PM, Imperatorn wrote:
> Who can improve the documentation?

Anyone.

The only problem is figuring out if the compiler is correct or the docs.

I think ultimately, the main problem is that d hasn't strictly-defined pointer provenance semantics.  So we end up with these ad-hoc rules like 'a pure function's result may be immutable'.  The C memory model was a great accomplishment on the part of boehm, and it should probably not be emulated; nevertheless, deviating from it has annoying implications for code generation from gdc and ldc.

On Saturday, 13 November 2021 at 09:06:23 UTC, tsbockman wrote:
> On Saturday, 13 November 2021 at 08:32:42 UTC, Timon Gehr wrote:
>> On 13.11.21 09:30, tsbockman wrote:
>>>>
>>> 
>>> That's a compiler bug.
>>
>> Nonsense. Results of strongly pure function calls implicitly convert to immutable. Your "fix" just avoided purity inference.
>
> I see. This does not appear to be documented anywhere in the spec at the moment.

The conversion itself is not documented, but the spec does explain why the original code is not allowed:

> A pure factory function is a strongly pure function that returns a result that has mutable indirections. All mutable memory returned by the call may not be referenced by any other part of the program, i.e. it is newly allocated by the function. Nor may the mutable references of the result refer to any object that existed before the function call.

So, having a strongly-pure function return a mutable pointer to an existing object is forbidden.

I guess this is what we get for trying to make memory allocation count as "pure."

On Saturday, 13 November 2021 at 10:08:27 UTC, rikki cattermole wrote:
>
> On 13/11/2021 11:06 PM, Imperatorn wrote:
>> Who can improve the documentation?
>
> Anyone.
>
> The only problem is figuring out if the compiler is correct or the docs.

Well, yeah, what I mean was who can "figure out if the compiler is correct or the docs" :)

On Saturday, 13 November 2021 at 12:59:41 UTC, Imperatorn wrote:
> On Saturday, 13 November 2021 at 10:08:27 UTC, rikki cattermole wrote:
>>
>> On 13/11/2021 11:06 PM, Imperatorn wrote:
>>> Who can improve the documentation?
>>
>> Anyone.
>>
>> The only problem is figuring out if the compiler is correct or the docs.
>
> Well, yeah, what I mean was who can "figure out if the compiler is correct or the docs" :)

The compiler is correct; see https://forum.dlang.org/post/rimxulakeebqfnuzeidw@forum.dlang.org

On Saturday, 13 November 2021 at 13:01:08 UTC, Paul Backus wrote:
> On Saturday, 13 November 2021 at 12:59:41 UTC, Imperatorn wrote:
>> On Saturday, 13 November 2021 at 10:08:27 UTC, rikki cattermole wrote:
>>>
>>> On 13/11/2021 11:06 PM, Imperatorn wrote:
>>>> Who can improve the documentation?
>>>
>>> Anyone.
>>>
>>> The only problem is figuring out if the compiler is correct or the docs.
>>
>> Well, yeah, what I mean was who can "figure out if the compiler is correct or the docs" :)
>
> The compiler is correct; see https://forum.dlang.org/post/rimxulakeebqfnuzeidw@forum.dlang.org

Oh, didn't see that post

On 13.11.21 13:42, Paul Backus wrote:
> 
> I guess this is what we get for trying to make memory allocation count as "pure."

How else are you going to represent your values? I really don't get this trend of questioning whether memory allocation should be `pure`. I think it may be caused by thinking at the wrong level of abstraction.

On Saturday, 13 November 2021 at 13:11:05 UTC, Timon Gehr wrote:
> On 13.11.21 13:42, Paul Backus wrote:
>> 
>> I guess this is what we get for trying to make memory allocation count as "pure."
>
> How else are you going to represent your values? I really don't get this trend of questioning whether memory allocation should be `pure`. I think it may be caused by thinking at the wrong level of abstraction.

In a language where valid programs cannot distinguish between different pointers to the same value, or observe the side effects of memory allocation, it is natural to define `pure` such that it allows memory allocation.

D is not that kind of language. A valid D program can very easily distinguish between different pointers to the same value, and observe the side effects of memory allocation. In a language like D, defining `pure` such that it allows memory allocation means that (a) you can't, in general, assume a strongly-pure function has no observable side effects and is referentially transparent [1], which makes `pure` less useful for static analysis and optimization; and (b) some functions that do have no observable side effects and are referentially transparent nevertheless cannot be `pure`, which is weird and unintuitive.

[1] Actually, the spec says that the compiler is allowed to assume referential transparency anyway, which turns this from an unfortunate limitation into a loaded foot-gun.