Congratulations to the D Team!

[Timon Gehr]

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. There are also simple workarounds for the
functional style programming case: just do not annotate.

>
>> OO is all about data encapsulation, aliasing and
>> mutation.
>>
>> Also consider that:
>>
>> - Functional style programs use structs and delegates, not class
>> objects. Classes are an OO abstraction.
>>
>> - The most well-known functional programming language, Haskell, mutates
>> existing state a great deal at runtime, since almost _everything_ is
>> lazily initialized. I have written some Haskell-style D code, and
>> could not use the 'const', 'immutable' or 'pure' qualifiers.
>>
>> - what actually harms functional style programming in D the most is the
>> lack of tail calls. (I have some other gripes, but this is the most
>> important one.)
>>
>> - D is multi-paradigm. A program can be functional style in many ways,
>> and still mutate state. (Functional programming languages have to
>> invent idioms and syntactic sugar to provide an abstraction for
>> mutation. The compiler has to detect those and optimize them into
>> mutation.)
>>

I consider those points important.

>>> A straightforward workaround is to use PIMPL to encapsulate the logical
>>> const stuff, and then cast the reference to const to use inside the
>>> opEquals.
>>
>> I didn't get that.
>
> PIMPL means pointer to implementation.  Your const struct is just a
> wrapper around a pointer, and that pointer can be cast to mutable before
> calling member functions on it.
>
> Or:
>
> bool opEquals(const Object p) const
> {
>     Object q = cast() p;
>     Object r = cast() this;
>     return r.non_const_equals(q);
> }
>
> 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.