On Monday, 5 November 2012 at 09:10:41 UTC, Tobias Pankrath wrote:
Casting away const is okay as long as you don't change a single
bit of your data.
Yes, thanks. Makes sense. I need to know not only what I might be
mutating, but also code I call. In this specific case, though I
hope all of these things on assoc arrays are safe, const or not,
so my cast is harmless.
- length
- keys - returning dynamic array I won't change
- values - returning dynamic array I won't change
- foreach
I have not figured what to look at for associative arrays. For
example, in .../druntime/import/object.di there is a struct
called AssociativeArray which I imagine the [ "foo" : "goo" ]
syntactic sugar gets me to. It has the keys property as non-const
and internally it does a cast:
Key[] keys() @property
{
auto a = _aaKeys(p, Key.sizeof);
return *cast(Key[]*) &a;
}
I'm not even sure if this is the right code to look at when
dealing with associative arrays described in TDPL?
If not is there another way?
The code below works, too. But to be honest, I don't now why
the compiler complains that the postblit is not callable in
your version but does not actually get called in mine.
My theory: you must use this(this) without variation for postblit
to even get called until they hammer out the issues on the thread
you referred to. While the signature below gets called, it is
futile since incipient instance can not be patched which is the
purpose. I think <this(this) const> should not be allowed but
this(const ref this) or this(const this) should be allowed and
preferred. I don't understand how the compiler ends up with the
postblit message without the cast. I hope the lack of const on
assoc array properties and foreach are oversights rendering the
casts safe and on a future release of D rendering them
unnecessary.
Thanks
Dan
-----
alias Account[string] Map;
struct Account {
this(this) const { writeln("acct copied"); }
//this(this) { writeln("acct copied"); }
}