Cannot hash a std.datetime.Date

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Jun 18 06:08:29 UTC 2018


On Sunday, June 17, 2018 18:15:19 Per Nordlöw via Digitalmars-d wrote:
> The following
>
> unittest
> {
>      import std.datetime.date : Date;
>      Date date;
>      import core.internal.hash : hashOf;
>      auto hash = date.hashOf;
> }
>
> errors (with DMD v2.081.0-beta.1) as
>
> /usr/include/dmd/druntime/import/core/internal/convert.d(619,101): Error:
> template `core.internal.convert.toUbyte` cannot deduce function from
> argument types `!()(Month)`, candidates are:
> /usr/include/dmd/druntime/import/core/internal/convert.d(14,16):
> `core.internal.convert.toUbyte(T)(ref T val) if
> (is(Unqual!T == float) || is(Unqual!T == double) || is(Unqual!T
> == real) || is(Unqual!T == ifloat) || is(Unqual!T == idouble) ||
> is(Unqual!T == ireal))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(479,16):
>         `core.internal.convert.toUbyte(T)(T[] arr) if (T.sizeof ==
> 1)`
> /usr/include/dmd/druntime/import/core/internal/convert.d(485,16):
>         `core.internal.convert.toUbyte(T)(T[] arr) if
> (is(typeof(toUbyte(arr[0])) == const(ubyte)[]) && (T.sizeof > 1))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(503,16):
>         `core.internal.convert.toUbyte(T)(ref T val) if
> (__traits(isIntegral, T) && !is(T == enum))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(537,16):
>         `core.internal.convert.toUbyte(T)(ref T val) if
> (is(Unqual!T == cfloat) || is(Unqual!T == cdouble) || is(Unqual!T
> == creal))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(619,101):
> ... (2 more, -v to show) ...
> /usr/include/dmd/druntime/import/core/internal/hash.d(145,37):
> Error: template instance `core.internal.convert.toUbyte!(Date)`
> error instantiating
> foo.d(6,21):        instantiated from here: `hashOf!(Date)`
>
> but not with 2.080.1. A regression?

I'm not very familiar with the details of hashOf, so I can't say for sure
whether this is a regression or not, but in most cases, if something worked
in a previous release but doesn't work now, and there are no deprecation
messages involved, then it's probably a regression (especially if the
changelog doesn't say anything about it). Occasionally, the breakage is
intentional, but you pretty much can't go wrong by reporting it as a
regression. Worst case, it turns out that it was completely on purpose, and
the bug report will be closed accordingly. But if you don't report it as a
regression, and it is one, then it probably won't be fixed before the actual
release.

Glancing over the changelog, there are multiple entries which have to do
with improving core.internal.hash, and my guess would be that one of those
changes accidentally broke something.

- Jonathan M Davis




More information about the Digitalmars-d mailing list