Getting the const-correctness of Object sorted once and for all

[Chris Cain]

On Tuesday, 15 May 2012 at 21:18:11 UTC, Chad J wrote:
> On 05/15/2012 03:32 PM, Chris Cain wrote:
>> On Tuesday, 15 May 2012 at 18:07:12 UTC, Chad J wrote:
>>> An idea I thought of is to introduce a method local 
>>> declaration that
>>> allows a method to access instance-specific-state that isn't
>>> accessible to the rest of the class:
>>
>> This is an interesting idea (as it seems to really try to keep
>> the state changes internal to the function, which can be seen 
>> as
>> how D handles purity)... however, it breaks the point of 
>> purity due to
>> this:
>>
>> pure nothrow hash_t toHash() const {
>> @instance hash_t bad = 0;
>> ++bad;
>> return hashfn(field) + bad;
>> }
>>
>> Now it violates everyone's definition of purity and we can no
>> longer make our sweet optimizations and reasoning about the 
>> code.
>> Sure, we could "trust the programmers to not do this" ... but
>> that's another debate entirely.
>
>
> Yes.  I intend to "trust the programmers to not do this".
>
> Otherwise we need to find some way to ensure that a function 
> that alters external state will always return the same value as 
> long as the rest of the program doesn't change the state it 
> looks at.

It still wouldn't work though. Your @instance variables couldn't
be stored with the object (and, thus, would have to be a pointer
to mutable memory). So it'd require some backend work to make
sure that's even feasible (it is, you could have an immutable
pointer to a mutable pointer to the int, but let's face it:
that's further spitting in the face of the way D's type system
has been designed).

So, you'd have invisible indirections, additional complexity, and
you'd have to trust the programmers to be responsible. In other
words, C++ + the slowness of indirections.

On Tuesday, 15 May 2012 at 22:33:56 UTC, Era Scarecrow wrote:
>  Perhaps an alternate workaround... a thought coming to mind, 
> is that the constructor for a const object lets you set it once 
> in the constructor (but not touch it again after) So.... 
> Maybe...?

This is a good approach, but I think a lot of people want 
something that's lazy ... if they don't need a hash, they don't 
want it to be calculated for them.


FWIW, my idea: the thing we really need to do is to R&D some
design patterns & idioms for D. There's solutions for using const
and caching and such, but formalizing them and working out the
kinks to make sure it's optimal for everyone's circumstances
would be helpful. And people will have to accept that C++'s
particular idioms can't be used with D (and vice versa ... some
things you can do easily in D is infeasible or incorrect/invalid
with C++).

Book idea? :) I'd do it, but I'm just a student, so I haven't
seen even a decent subset of all possible software engineering
problems.