On Friday, 19 April 2019 at 12:37:10 UTC, Arredondo wrote:
> Here's a reasonably-sized code fragment that demonstrates the issue.

Oh dear, I don't know what's going on there. It might just be that toHash is secretly dependent on various attributes in the signature.

I'd try to match the attrs exactly from this:

https://dlang.org/spec/hash-map.html#using_struct_as_key

size_t toHash() const @safe pure nothrow;
bool opEquals(ref const typeof(this) s) const @safe pure nothrow;

and see if it makes a difference.


idk though.

On Friday, 19 April 2019 at 12:37:10 UTC, Arredondo wrote:
> Here's a reasonably-sized code fragment that demonstrates the issue. I hope the comments along the way are descriptive enough

Hmm. Have you tried using a different compiler or 32/64 bit? I had a weird "null out of nowhere" bug going on with associative array some time ago - https://issues.dlang.org/show_bug.cgi?id=19662

On Friday, 19 April 2019 at 12:48:32 UTC, Adam D. Ruppe wrote:
> It might just be that toHash is secretly dependent on various attributes in the signature.
>

You nailed it. This was it. It was not trivial to add the missing @safe and const attributes, but it worked.

Thanks!

On Fri, Apr 19, 2019 at 08:15:22PM +0000, Arredondo via Digitalmars-d-learn wrote:
> On Friday, 19 April 2019 at 12:48:32 UTC, Adam D. Ruppe wrote:
> > It might just be that toHash is secretly dependent on various attributes in the signature.
> > 
> 
> You nailed it. This was it. It was not trivial to add the missing @safe and const attributes, but it worked.
[...]

For the future, also note that if you want to test opCmp it's better to use == instead of calling opCmp directly, that way you know for sure that the compiler picked up your definition of opCmp. (IIRC if the signature doesn't match for whatever reason the compiler may just silently revert to the default implementation.)

Similarly, if you want to test toHash, use typeid(obj).getHash(&obj), rather than calling toHash directly.  That way you know for sure that the compiler has picked up your custom toHash, rather than just the default implementation.


T

-- 
"Maybe" is a strange word.  When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.

On Friday, 19 April 2019 at 12:37:10 UTC, Arredondo wrote:
>     Slice!(Contiguous, [2], byte*) payload;

BTW, any reason not to use the new version of ndslice?

For new API it would be:

Slice!(byte*, 2, Contiguous)

or just

Slice!(byte*, 2)

On Saturday, 20 April 2019 at 14:24:34 UTC, 9il wrote:
> On Friday, 19 April 2019 at 12:37:10 UTC, Arredondo wrote:
>>     Slice!(Contiguous, [2], byte*) payload;
>
> BTW, any reason not to use the new version of ndslice?
>
> For new API it would be:
>
> Slice!(byte*, 2, Contiguous)
>
> or just
>
> Slice!(byte*, 2)

I think this new ndslice API is newer than my code. I might consider upgrading though, maybe in the new version Slice.field() is const, so I can use my preferred implementation of toHash()?

On Saturday, 20 April 2019 at 22:16:22 UTC, Arredondo wrote:
> On Saturday, 20 April 2019 at 14:24:34 UTC, 9il wrote:
>> On Friday, 19 April 2019 at 12:37:10 UTC, Arredondo wrote:
>>>     Slice!(Contiguous, [2], byte*) payload;
>>
>> BTW, any reason not to use the new version of ndslice?
>>
>> For new API it would be:
>>
>> Slice!(byte*, 2, Contiguous)
>>
>> or just
>>
>> Slice!(byte*, 2)
>
> I think this new ndslice API is newer than my code. I might consider upgrading though, maybe in the new version Slice.field() is const, so I can use my preferred implementation of toHash()?

In the latest release you can do

yourSlice.lightConst.field

lightConst converts from const slice to slice of const.

I will add const and immutable field to the next major release.

Yoy can fill an issue in case you would also need other functionality.

Best,
Ilya

On Sunday, 21 April 2019 at 00:13:15 UTC, 9il wrote:
>
> In the latest release you can do
>
> yourSlice.lightConst.field
>
> lightConst converts from const slice to slice of const.
>
> I will add const and immutable field to the next major release.
>

That is very good to know. BWT, I think ndslice is an amazing contribution, and you are doing a great job. I do find it hard to navigate sometimes though, with the rather thin documentation that it has. More docs would definitely be at the top of my wish list :)

Kind regards,
Arredondo