Congratulations to the D Team!

[Walter Bright]

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.


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