What is the way forward with @nogc and hash tables?
At the moment it is - AFAICT - not possible to insert an
element into a hash table in @nogc code. Aggregate types work
since you can always implement a @nogc toHash and look for
that, but other types don't. Or do I miss something?

-- 
Marco

On Friday, 9 September 2016 at 10:16:09 UTC, Marco Leise wrote:
> it is - AFAICT - not possible to insert an
> element into a hash table in @nogc code.

It is with http://code.dlang.org/packages/emsi_containers

Am Fri, 09 Sep 2016 10:52:54 +0000
schrieb Guillaume Piolat <first.last@gmail.com>:

> On Friday, 9 September 2016 at 10:16:09 UTC, Marco Leise wrote:
> > it is - AFAICT - not possible to insert an
> > element into a hash table in @nogc code.
> 
> It is with http://code.dlang.org/packages/emsi_containers

It does not /allocate/ with the GC, but the methods are
not /annotated/ @nogc, e.g. insert():
https://github.com/economicmodeling/containers/blob/master/src/containers/hashmap.d#L338
It's plain simple not possible out of the box* at the moment.

* writing your own hash function that covers every type is NOT
  "out of the box" :p

-- 
Marco

On Friday, 9 September 2016 at 11:16:19 UTC, Marco Leise wrote:
> It does not /allocate/ with the GC, but the methods are
> not /annotated/ @nogc, e.g. insert():
> https://github.com/economicmodeling/containers/blob/master/src/containers/hashmap.d#L338
> It's plain simple not possible out of the box* at the moment.
>
> * writing your own hash function that covers every type is NOT
>   "out of the box" :p

But they are template functions.
Maybe this is a case of https://p0nce.github.io/d-idioms/#Automatic-attribute-inference-for-function-templates then?

On Friday, 9 September 2016 at 11:35:58 UTC, Guillaume Piolat wrote:
> On Friday, 9 September 2016 at 11:16:19 UTC, Marco Leise wrote:
>> It does not /allocate/ with the GC, but the methods are
>> not /annotated/ @nogc, e.g. insert():
>> https://github.com/economicmodeling/containers/blob/master/src/containers/hashmap.d#L338
>> It's plain simple not possible out of the box* at the moment.
>>
>> * writing your own hash function that covers every type is NOT
>>   "out of the box" :p
>
> But they are template functions.
> Maybe this is a case of https://p0nce.github.io/d-idioms/#Automatic-attribute-inference-for-function-templates then?

Strangely you seemed to know, 1 month ago, about the annotation problem !
Wasn't this you "ponce" that opened this Q https://github.com/economicmodeling/containers/issues/60 ?

Am Fri, 09 Sep 2016 11:35:58 +0000
schrieb Guillaume Piolat <first.last@gmail.com>:

> On Friday, 9 September 2016 at 11:16:19 UTC, Marco Leise wrote:
> > It does not /allocate/ with the GC, but the methods are
> > not /annotated/ @nogc, e.g. insert():
> > https://github.com/economicmodeling/containers/blob/master/src/containers/hashmap.d#L338
> > It's plain simple not possible out of the box* at the moment.
> >
> > * writing your own hash function that covers every type is NOT
> >   "out of the box" :p
> 
> But they are template functions.
> Maybe this is a case of
> https://p0nce.github.io/d-idioms/#Automatic-attribute-inference-for-function-templates then?

Sorry, I didn't want to talk about the lack of attribute inference for non-templated functions inside templates :p. Yes, that's why some of the methods in EMSI containers are annotated and I'm aware of that.

The point is that TypeInfo_*.getHash() cannot be @nogc,
because a class or struct may implement a not-@nogc toHash().
(Where I may add, that e.g. TypeInfo_Pointer.getHash() *could*
be @nogc, since all it returns is `cast(size_t)cast(void*)p`).

The alternatives in core.internal.hash are supposed to
be CTFE-able and albeit bytesHash itself does not seem to use
the GC, the wrapper functions for different types may.

And that is why @nogc hash table implementations don't fly at the moment.

-- 
Marco

On Friday, 9 September 2016 at 12:31:04 UTC, Basile B. wrote:
>
> Strangely you seemed to know, 1 month ago, about the annotation problem !
> Wasn't this you "ponce" that opened this Q https://github.com/economicmodeling/containers/issues/60 ?

Yes. But I instantly forget about it since I've implemented a linear search instead since.

On Friday, 9 September 2016 at 12:31:34 UTC, Marco Leise wrote:
> The point is that TypeInfo_*.getHash() cannot be @nogc,
> because a class or struct may implement a not-@nogc toHash().
> (Where I may add, that e.g. TypeInfo_Pointer.getHash() *could*
> be @nogc, since all it returns is `cast(size_t)cast(void*)p`).
>
> The alternatives in core.internal.hash are supposed to
> be CTFE-able and albeit bytesHash itself does not seem to use
> the GC, the wrapper functions for different types may.
>
> And that is why @nogc hash table implementations don't fly at the moment.

Yeah it wouldn't be far-fetched to make toHash() @nogc nothrow.
A hash-table that allocates on lookup would negate any speed-advantage anyway.