On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote:
> On 12 January 2014 04:52, Adam D. Ruppe
>> It shouldn't be here though... the reason it is implicitly convertable is
>> that pure means the result is unique.
> Can you explain how this is true?

I touched on the topic in a short section of my old purity article: http://klickverbot.at/blog/2012/05/purity-in-d/#_and___again

David

On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote:
> On 12 January 2014 04:52, Adam D. Ruppe <destructionator@gmail.com> wrote:
>
>> On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:
>>
>>> It is legal exactly because function is marked as pure. Result of pure
>>> function is implicitly convertible to immutable.
>>>
>>
>> It shouldn't be here though... the reason it is implicitly convertable is
>> that pure means the result is unique.
>
>
> Can you explain how this is true? I can't see anything about the concept of
> purity that suggests the result should be unique...
> Pure just means given the same inputs, it will produce the same outputs;
> external state can't affect the calculation.

How could the result not be unique, or at least immutable? Pure functions cannot read mutable global state, so any global state returned must be immutable. Strong pure functions can also only have immutable arguments, so anything returned from those will be immutable. The only other thing that can be returned must be created within the function, which will be unique, and safely converted to immutable.

On 12 January 2014 11:05, Peter Alexander <peter.alexander.au@gmail.com>wrote:

> On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote:
>
>> On 12 January 2014 04:52, Adam D. Ruppe <destructionator@gmail.com> wrote:
>>
>>  On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote:
>>>
>>>  It is legal exactly because function is marked as pure. Result of pure
>>>> function is implicitly convertible to immutable.
>>>>
>>>>
>>> It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique.
>>>
>>
>>
>> Can you explain how this is true? I can't see anything about the concept
>> of
>> purity that suggests the result should be unique...
>> Pure just means given the same inputs, it will produce the same outputs;
>> external state can't affect the calculation.
>>
>
> How could the result not be unique, or at least immutable? Pure functions cannot read mutable global state, so any global state returned must be immutable. Strong pure functions can also only have immutable arguments, so anything returned from those will be immutable. The only other thing that can be returned must be created within the function, which will be unique, and safely converted to immutable.
>

But pure functions can (and do) return their arguments, and it's obviously
not a 'strongly pure' function. So I just can't see how the assertion that
it should be unique stands?
Also, I was under the impression a 'strongly pure' function's arguments
only need to be const, not necessarily immutable. Purity says something
about the transformation performed by the function, nothing about the data
it operates on.
Why should all arguments need to be immutable?

On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:
> But pure functions can (and do) return their arguments, and it's obviously
> not a 'strongly pure' function. So I just can't see how the assertion that
> it should be unique stands?

That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable.


> Also, I was under the impression a 'strongly pure' function's arguments
> only need to be const, not necessarily immutable. Purity says something
> about the transformation performed by the function, nothing about the data
> it operates on.
> Why should all arguments need to be immutable?

You don't need immutable arguments for purity, just strong purity. It's a stronger guarantee, more than normally guaranteed. Think of strong purity as pure + referentially transparent.

Sorry, yes you're right, they only need to be const. And it is only if you return a mutable value that the result becomes convertible to immutable.

int* f(const(int)* x); // convertible
const(int)* f(const(int)* x); // not-convertible

This is safe in the first instance because the result could not have come from x due to x being const. In the second instance, the result could have come from x, so it cannot be implicitly converted to immutable.

On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:
> Also, I was under the impression a 'strongly pure' function's arguments
> only need to be const, not necessarily immutable. Purity says something
> about the transformation performed by the function, nothing about the data
> it operates on.
> Why should all arguments need to be immutable?

Your definition of purity states it clearly that the purity depends on the mutability of the input data.

On 1/12/14 2:49 AM, Peter Alexander wrote:
> On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:
>> But pure functions can (and do) return their arguments, and it's
>> obviously
>> not a 'strongly pure' function. So I just can't see how the assertion
>> that
>> it should be unique stands?
>
> That's the bug. Your function isn't strongly pure, so the result
> shouldn't be convertible to immutable and isn't necessarily unique. Only
> strongly pure functions can have results convertible to immutable.

Yep. Has this been placed in bugzilla? It's rather hi-pri.

Andrei

"Andrei Alexandrescu"  wrote in message news:laugbo$2jcq$3@digitalmars.com...
> Yep. Has this been placed in bugzilla? It's rather hi-pri.

If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause. 

On 13 January 2014 02:37, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/12/14 2:49 AM, Peter Alexander wrote:
>
>> On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote:
>>
>>> But pure functions can (and do) return their arguments, and it's
>>> obviously
>>> not a 'strongly pure' function. So I just can't see how the assertion
>>> that
>>> it should be unique stands?
>>>
>>
>> That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable.
>>
>
> Yep. Has this been placed in bugzilla? It's rather hi-pri.


I wasn't sure if it was definitely a bug. Certainly seemed like one though.

https://d.puremagic.com/issues/show_bug.cgi?id=11908

On 1/12/14 8:46 AM, Daniel Murphy wrote:
>
> "Andrei Alexandrescu"  wrote in message
> news:laugbo$2jcq$3@digitalmars.com...
>> Yep. Has this been placed in bugzilla? It's rather hi-pri.
>
> If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it
> most likely has the same cause.

Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function

Andrei

On 01/12/2014 11:49 AM, Peter Alexander wrote:
>> Also, I was under the impression a 'strongly pure' function's arguments
>> only need to be const, not necessarily immutable. Purity says something
>> about the transformation performed by the function, nothing about the
>> data
>> it operates on.
>> Why should all arguments need to be immutable?
>
> You don't need immutable arguments for purity, just strong purity. It's
> a stronger guarantee, more than normally guaranteed. Think of strong
> purity as pure + referentially transparent.
>
> Sorry, yes you're right, they only need to be const. And it is only if
> you return a mutable value that the result becomes convertible to
> immutable.
>
> int* f(const(int)* x); // convertible
> const(int)* f(const(int)* x); // not-convertible
> ...

(I assume you meant those to be pure.)

> This is safe in the first instance because the result could not have
> come from x due to x being const. In the second instance, the result
> could have come from x, so it cannot be implicitly converted to immutable.

Well, currently things are supposed to be as follows:

1. A strongly pure callable is a pure callable whose parameter types implicitly convert to immutable.

2. The result of a call to a strongly pure callable implicitly converts to immutable.


The following vastly more general rule would still be sound and also capture your case:

- The result of a call to a pure callable, where all arguments whose corresponding parameter types are incompatible with the result type implicitly convert to immutable (shared), implicitly converts to immutable (shared). (Incompatibility should probably just be incompatibility of qualifiers.)