Congratulations to the D Team!

[Walter Bright]

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.