Congratulations to the D Team!

[Timon Gehr]

On 07/11/2012 03:14 AM, Walter Bright wrote:
> On 7/10/2012 6:04 PM, Timon Gehr wrote:
>>> 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); }
>
> Purity also means not reading mutable global state. Also, it is not
> practical for a compiler to ensure that x has the same value upon exit
> as entry if it is being assigned to.
>

It could in principle ensure it by providing a language feature that
carries out this operation. When the abstraction level gets higher,
stuff usually gets much simpler for a verifier.

>
>
>> 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.
>
> You do have another option - don't use toHash, opEquals, etc., with
> those structures.
>

With the entire code base. The structures are fundamental.
What can be const today will call into a method that uses one of those
tomorrow. But why should I sprinkle my code with 'const' anyway? Almost
none of its classes will actually be instantiated with the immutable
qualifier.

>
>>> 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.
>
> I cannot reconcile that with a desire for logical constness, which is
> completely uncheckable.
>

I do not desire logical const as a language feature. But conservative
type systems are not good for everything. The root of the class
hierarchy needs to be good for everything. Object is not an adequate
root any more.

> Anyhow, the point of @trusted is to notify the maintainer that "here be
> dragons". Logical const doesn't even go that far - it's purely ornamental.

I see. I was under the impression that the point of @trusted was to be
able to subvert the type system without actually subverting its
guarantees.