On Sun, Apr 08, 2012 at 04:11:10PM +0200, Tove wrote:
> On Sunday, 8 April 2012 at 13:53:07 UTC, H. S. Teoh wrote:
> >On Sun, Apr 08, 2012 at 12:56:38AM -0500, Andrei Alexandrescu
> >wrote:
> >[...]
> >>1. What happened to the new hash project? We need to take that to
> >>completion.
> >[...]
[...]
> >The major outstanding issues are:
> >
> >- Qualified keys not fully working: the current code has a few corner
> > cases that don't work with shared/immutable/inout keys. One major
> > roadblock is how to implement this:
> >
> > alias someType T;
> > inout(T) myFunc(inout(T) arg, ...) {
> > int[inout(T)] aa;
> > ...
> > }
> >
> > The problem is that inout gets carried over into the AA template,
> > which breaks because it instantiates into something that has:
> >
> > struct Slot {
> > hash_t hash;
> > inout(T) key; // <-- this causes a compile error
> > Value value;
> > }
[...]
> doesn't this work?
> immutable std.traits.Unqual!(inout(T)) key;
I suppose so, but the problem is more with the return type of various AA
functions. If the user writes int[inout(T)] aa, then he would expect
that aa.keys should return inout(T)[]. But the problem here is that this
is impossible to express in the current system, because inout has a
different meaning when you write it in the AA method, than its meaning
in the context of the calling function. For example, this doesn't quite
work:
struct AA {
...
inout(Key) keys() {
...
// Problem: inout here doesn't mean what it
// means in the context of the caller
}
}
T
--
Tech-savvy: euphemism for nerdy.
