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. Faith-based functional
programming is not functional programming.
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.
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. At least with @trusted the code inspector knows that
there's something unusual going on there that needs to be manually checked.
