Congratulations to the D Team!

[Timon Gehr]

On 07/11/2012 12:05 AM, Walter Bright wrote:
> On 7/9/2012 3:27 PM, Jakob Ovrum wrote:
>> This opEquals is only logically constant, not bitwise constant, hence
>> it must
>> not be const; similar to the caching scenario. Just trying to
>> demonstrate that
>> the issue is bigger than just caching - it's any logically constant
>> comparison
>> function.
>
> 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. 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.