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.
