On Tuesday, 5 February 2013 at 11:51:40 UTC, Maxim Fomin wrote:
On Tuesday, 5 February 2013 at 04:03:06 UTC, Andrej Mitrovic
wrote:
Yeah, it's still not very helpful. And I have no idea where
"Slot" comes from.
This is sub struct inside object.AssociativeArray.
Is it the case that this is a D compiler (or library) problem and
there is no issue with the code? Or is there really a problem
with it that I am not seeing? I gather from the responses the
code looks fine, otherwise any misunderstanding would come up
quickly.
I feel like I have painted myself in a corner a bit. I love D's
templates and am a fan of the compile time reflection. I have
mixins that support things like OpEquals, OpCmp, toHash, etc. I
try very hard to work with const correctly.
mixin template OpEquals() {
bool opEquals(const ref typeof(this) other) const {
return typesDeepEqual(this, other);
}
bool opEquals(const typeof(this) other) const {
return typesDeepEqual(this, other);
}
}
This OpEquals in the sample was just this signature (which I have
mixed in all over successfully) but with a 'return true'. I think
this is the correct signature to use. If I understand correctly,
were I to remove the const, then const instances may no longer
call it - which is not a good change.
Transitive const is more than just simple const, and obviously
more is better ;-). Since "Slot" is mentioned and
"object.AssociativeArrray" it sounds like there may be a
const-correctness issue with associative array itself rather than
this code? Before the move to 2.061 I had to cast away const on
const(V[K]) to get length and to iterate over them. But why the
link between History!double and RC[int] when they are totally
unrelated? Well, the only relation is their aggregation in
BSItem. Baffling.
Any suggestions appreciated.
Thanks
Dan
