Congratulations to the D Team!

[Timon Gehr]

On 07/11/2012 02:03 AM, Walter Bright wrote:
> On 7/10/2012 4:29 PM, Timon Gehr wrote:
>> On 07/11/2012 01:10 AM, Walter Bright wrote:
>>> On 7/10/2012 3:49 PM, Timon Gehr wrote:
>>>>> I understand, but the downside of not making these functions const
>>>>> is it
>>>>> will torpedo the use of functional style programming in D.
>>>>>
>>>>
>>>> Making these functions const will torpedo the use of OO style
>>>> programming in D.
>>>
>>> No, it won't, there are simple workarounds.
>>>
>>
>> In @safe code there are none.
>
> Right. That's what I meant when you have to add @trusted.
>
>
>> There are also simple workarounds for the functional style programming
>> case: just do not annotate.
>
> Functional means a guarantee against mutability.

Only guaranteed referential transparency is necessary. Eg, 'fun' in the
following code snippet has this property. Even though it mutates global
state and calls a function that does not have the property.

int x = 2;
int fun(){
     auto y = x;
     x = 3;
     auto r = gun();
     x = y;
     return r;
}

auto gun(){ return arbitrary_pure_computation(x); }


> Faith-based functional programming is not functional programming.
>

This program is functional-style:
http://pastebin.com/Vx4hXvaT

With some template/static assert/information hiding magic, it could be
adapted so that any pure-annotated code using the Lazy types for all
arguments&returns provides referential transparency guarantees.

>
>> I consider those points important.
>
> So do I. But all language design involves tradeoffs. I believe the
> advantages of const toHash etc. outweigh the disadvantage of less
> straightforward memoization.
>

I use unbounded data structures. Those have to be initialized lazily
and therefore the non-constness of their methods invades the entire
code base which is written in OO and functional styles (and a good
portion of Metaprogramming to remove the boilerplate). Most methods
that would be considered const cannot be, because they may trigger
extensions of the unbounded data structures somewhere down the road.

>
>>> Of course, you'd have to make this @trusted.
>>
>> It is not safe to do that. Marking it @trusted would be a lie. We
>> cannot build a type system on the premise that any OO code will break
>> it and at the same time claim that it provides actual guarantees.
>
> Consider that in the light of what logical const actually is - it offers
> no guarantees whatsoever.

The issue is that the guarantees need to apply to objects to which they
cannot apply if they are forced to implement functions that provide the
guarantees.

> At least with @trusted the code inspector
> knows that there's something unusual going on there that needs to be
> manually checked.

There will be non-trivial bugs that the code inspector won't see.
Most bugs are caught by testing or trying to formally prove correctness.