On 03/24/2012 05:14 PM, H. S. Teoh wrote:
On Sat, Mar 24, 2012 at 12:34:56PM +0100, Timon Gehr wrote:
[...]
This solution creates unnecessary template bloat for every implicit
conversion, duplicates compiler logic, and I think it does not work
correctly because of other issues. I have refined my proof of
concept.
[...]
OK, I've implemented your changes in a branch, but found the following
problems:
- Doesn't work with const AA/array keys, e.g.
AA!(string[const int[]]) aa;
AA!(string[const AA!(int[int])]) meta;
(The AA!() template is basically just syntactic sugar that uses
reflection to map "real" AA types into AssociativeArray templates,
courtesy of Andrej Mitovic.)
I assumed the key type needs to be immutable. If you want to allow
instantiation with non-immutable key type, this should do it:
template AA(Key, Value) if(!is(Key==immutable(Key))){
alias AA!(immutable(Key), Value) AA;
}
- Doesn't work with static array keys with dynamic array lookups.
Doesn't that need some extra logic in order to be efficient anyway? You
could detect static array keys and provide appropriate overloads in a
static if declaration.
But I think I like your approach better. Creating a new template
instantiation for every implicit conversion leads to lots of code bloat,
and also breaks in many places due to bugs in IFTI. Using non-template
methods takes advantage of the compiler's implicit conversions, and
where necessary we can just add overloads for stuff like .idup, and
probably slicing for the static array key case.
This sounds good.
One concern, though: wouldn't cast(immutable) break immutable
guarantees? For example:
class C {
int x;
hash_t toHash() { ... }
}
AA!(int[C]) aa;
auto c = new C;
c.x = 123;
const d = c; // convert mutable C to const(C)
aa[d] = 123; // const(C) casted into immutable(C)
c.x = 321; // uh-oh: immutability broken
T
cast(immutable) is only there to make it compile with built-in AAs. Your
code should not need to perform it?
