Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 29/05/13 13:59, Steven Schveighoffer wrote:
>
> You can't use const elements.  And for good reason -- the elements are
> not const, and cannot be considered const by the set.
>
> Use mutable data, and make the *key* part of the data const.

My first implementation does that and it's great for that one 
application.  All the complications arose when I went back to try and 
bulletproof it and make a set implementation that is generally useful 
rather than just for the application it was designed for.

I may just have to accept that two separate implementations are needed 
and that I have to give some thought about how to maximise the shared 
code between them.

>  If you
> wish, you can place inout on the indexing function, which should
> guarantee that during that function the data is not molested.  Then you
> basically have to hand-verify the insertion function does not change the
> data.

I always (try to) do hand verification :-).  Once I even toyed with code 
proofs (a la Gries, ISBN 0-387-90641-X) but that rapidly becomes boring 
in practice even when you have language constructs (such as Eiffel's 
loop) which are designed with such proofs in mind.

>
> That's the best D can do, and it's pretty good considering what other
> alternatives there are.

Yes. I agree - a type attribute system that could say everything we want 
to say would be very complex.  Nevertheless, D has room for improvement 
e.g. more expressive contracts are possible.

Peter
PS There seems to be a reluctance to fix problems in D if it will break 
existing code.  I would opine that the code that would be broken is 
already broken.  I would also opine that fixing the problems now will 
break less code than fixing them later.