Currently my AA implementation supports automatic key conversion (as
suggested by Andrei), for example:
AA!(string,int) aa;
char[] key = "abc".dup;
aa[key] = 1;// automatically converts char[] to
// string via .idup
The way this
Why do you not just do the conversion and then compute the hash, even if
the representation is the same?
On Fri, Mar 23, 2012 at 07:01:46PM +0100, Timon Gehr wrote:
> Why do you not just do the conversion and then compute the hash, even
> if the representation is the same?
Because Andrei says that the .idup shouldn't be performed unless it's
necessary (e.g., you should be able to lookup char[] in a s
On 03/23/2012 07:10 PM, H. S. Teoh wrote:
On Fri, Mar 23, 2012 at 07:01:46PM +0100, Timon Gehr wrote:
Why do you not just do the conversion and then compute the hash, even
if the representation is the same?
Because Andrei says that the .idup shouldn't be performed unless it's
necessary (e.g.,
On Fri, Mar 23, 2012 at 07:18:05PM +0100, Timon Gehr wrote:
> On 03/23/2012 07:10 PM, H. S. Teoh wrote:
> >On Fri, Mar 23, 2012 at 07:01:46PM +0100, Timon Gehr wrote:
> >>Why do you not just do the conversion and then compute the hash,
> >>even if the representation is the same?
> >
> >Because Andr
On 3/23/12 12:54 PM, H. S. Teoh wrote:
Currently my AA implementation supports automatic key conversion (as
suggested by Andrei), for example:
AA!(string,int) aa;
char[] key = "abc".dup;
aa[key] = 1;// automatically converts char[] to
On Fri, Mar 23, 2012 at 01:31:28PM -0500, Andrei Alexandrescu wrote:
[...]
> Let's see what requirements need to be satisfied by []. Say k is a
> value of the key type and x is a value being looked up.
>
> First, we need to be able to evaluate k == x. So the types must be
> comparable.
>
> Second
On 3/23/12 1:48 PM, H. S. Teoh wrote:
How do we check at compile time whether the hash function resolves to
the same entity?
int fun(T)(T x) {
return 42;
}
void main() {
static assert(&fun!int != &fun!double);
}
This actually reveals a compiler bug:
Assertion failed: (d->purity != PU
On Fri, Mar 23, 2012 at 02:06:15PM -0500, Andrei Alexandrescu wrote:
[...]
> A cast would be needed anyway because they have different types,
> too. Anyway upon more thinking maybe this is too restrictive a rule.
> It won't catch e.g. functions that are, in fact, identical, but come
> from distinct
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depend on Phobos, and I don't see why it is necessary.
What kind of functionality do you want to provide that depends on
std.conv.to
On 3/23/12 2:30 PM, H. S. Teoh wrote:
Wouldn't that require moving std.conv into druntime? And std.conv does
depend on std.traits as well...
Not sure how it's best to address this.
Andrei
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depend on Phobos, and I don't see why it is necessary.
What kind of functionality do you want t
On 03/23/2012 09:05 PM, Andrei Alexandrescu wrote:
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depend on Phobos, and I don't see why it is
On 3/23/12 3:23 PM, Timon Gehr wrote:
On 03/23/2012 09:05 PM, Andrei Alexandrescu wrote:
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purposes. You
must use to.
Andrei
druntime mustn't depe
On 03/23/2012 09:43 PM, Andrei Alexandrescu wrote:
On 3/23/12 3:23 PM, Timon Gehr wrote:
On 03/23/2012 09:05 PM, Andrei Alexandrescu wrote:
On 3/23/12 2:28 PM, Timon Gehr wrote:
On 03/23/2012 08:06 PM, Andrei Alexandrescu wrote:
Casting is very different from to, and useless for your purpose
On 03/23/2012 10:07 PM, Timon Gehr wrote:
I see. An alternative solution (one that does not make AAs depend on
Phobos and is more slick) would be to use the const qualified key type
for lookup (that is what const is for) and to have immutable keys for
stores. For types that define .idup, there w
On Fri, Mar 23, 2012 at 10:53:10PM +0100, Timon Gehr wrote:
> On 03/23/2012 10:07 PM, Timon Gehr wrote:
> >
> >I see. An alternative solution (one that does not make AAs depend on
> >Phobos and is more slick) would be to use the const qualified key type
> >for lookup (that is what const is for) and
On 03/24/2012 01:20 AM, H. S. Teoh wrote:
On Fri, Mar 23, 2012 at 10:53:10PM +0100, Timon Gehr wrote:
On 03/23/2012 10:07 PM, Timon Gehr wrote:
I see. An alternative solution (one that does not make AAs depend on
Phobos and is more slick) would be to use the const qualified key type
for lookup
On 03/24/2012 12:34 PM, Timon Gehr wrote:
else static if(is(T _ == shared(U),U)) alias const(getConstQual!U) r;
should be
else static if(is(T _ == shared(U),U)) alias
shared(const(getConstQual!U)) r;
But it does not matter for the AA implementation because it only uses
getConstQual with im
On 03/24/2012 12:34 PM, Timon Gehr wrote:
static if(is(typeof(getConstQual!Key.init.idup):Key)){
Better:
static if(is(typeof(getConstQual!Key.init.idup):Key) &&
!is(getConstQual!Key: Key)){
On Sat, Mar 24, 2012 at 12:34:56PM +0100, Timon Gehr wrote:
> On 03/24/2012 01:20 AM, H. S. Teoh wrote:
[...]
> >Hmm. I decided that perhaps the full-fledged std.conv.to is a bit of
> >an overkill, so I revised the AA code to compromise between needing
> >std.conv.to and still deliver what Andrei w
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 im
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
23 matches
Mail list logo
