https://issues.dlang.org/show_bug.cgi?id=16973

--- Comment #1 from Denis Shelomovskii <verylonglogin.reg@gmail.com> ---
This issue caused druntime Issue 16974.

--

https://issues.dlang.org/show_bug.cgi?id=16973

--- Comment #2 from Denis Shelomovskii <verylonglogin.reg@gmail.com> ---
A possible solution is to require explicit second argument type specification.

Using current language abilities it can be done with helper `seed` function or struct:
---
hashOf(obj, seed(0));
---
or with function overload rename:
---
hashOfWithSeed(obj, 0);
---

--

https://issues.dlang.org/show_bug.cgi?id=16973

safety0ff.bugz <safety0ff.bugz@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |safety0ff.bugz@gmail.com

--- Comment #3 from safety0ff.bugz <safety0ff.bugz@gmail.com> ---
(In reply to Denis Shelomovskii from comment #1)
> This issue caused druntime Issue 16974.

Druntime used to have a function rt.util.hash.hashOf with signature:
size_t hashOf( const(void)* buf, size_t len, size_t seed )

Which made up most references to 'hashOf' within druntime (by TypeInfos.)

I wouldn't be surprised if this bug was due to thinking it's calling rt.util.hash.hashOf instead of object.hashOf.

Mistaking core.internal.hash.hashOf for rt.util.hash.hashOf was responsible for a recent regression.

--

https://issues.dlang.org/show_bug.cgi?id=16973

--- Comment #4 from Denis Shelomovskii <verylonglogin.reg@gmail.com> ---
(In reply to safety0ff.bugz from comment #3)
> (In reply to Denis Shelomovskii from comment #1)
> > This issue caused druntime Issue 16974.
> 
> Druntime used to have a function rt.util.hash.hashOf with signature:
> size_t hashOf( const(void)* buf, size_t len, size_t seed )
> 
> Which made up most references to 'hashOf' within druntime (by TypeInfos.)
> 
> I wouldn't be surprised if this bug was due to thinking it's calling rt.util.hash.hashOf instead of object.hashOf.
> 
> Mistaking core.internal.hash.hashOf for rt.util.hash.hashOf was responsible for a recent regression.

No doubts it's a function call from wrong module. But it doesn't change the fact that Issue 16974 is caused by this issue.

--

https://issues.dlang.org/show_bug.cgi?id=16973

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--

https://issues.dlang.org/show_bug.cgi?id=16973

Steven Schveighoffer <schveiguy@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@gmail.com

--- Comment #5 from Steven Schveighoffer <schveiguy@gmail.com> ---
I would recommend this be closed as WONTFIX.

If you don't follow the specification of the function, I don't see how you expect to get correct results.

--