Why do we have transitive const, again?

[Peter Alexander]

On 25/09/11 2:52 AM, Walter Bright wrote:
> On 9/24/2011 6:39 PM, Peter Alexander wrote:
>> On 25/09/11 12:08 AM, Walter Bright wrote:
>>> 3. support for true functional programming
>>
>> Purity and (physical) immutability are separate concepts. Having
>> immutable
>> arguments is neither a necessary or sufficient condition for being pure.
>>
>> What do you mean by "true functional programming"? Just pure functional
>> programming?
>>
>> As I explained in my 'Thoughts on Immutability in D' post, physical
>> immutability
>> is far too restrictive for functional programming, so I would say that
>> immutable
>> in D restricts true functional programming rather than supporting it.
>> Supporting
>> functional programming would mean supporting logical immutability,
>> because
>> that's all functional programs care about.
>
> Functional programming means (in part) no side effects of functions,
> which means that global state cannot be modified through the parameters.
> Having the parameters be const/immutable is how this can be statically
> guaranteed.

It's easy to guarantee something. The difficult part is guaranteeing 
something without overly restricting it.

You could just as easily get the same guarantee by disallowing 
references and forcing people to copy data across threads all the time. 
That would be a terrible. Likewise, getting the guarantee by forbidding 
equality preserving mutations is also terrible, although to a lesser extent.