Congratulations to the D Team!

[Walter Bright]

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.



> 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.


>> 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.

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.