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.
