immutable bug?

[Manu]

On 12 January 2014 11:05, Peter Alexander <peter.alexander.au at 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 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140112/830fccd1/attachment-0001.html>