Bug 19197 – Replace instances of typeid(T).getHash(..) with hashOf
Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P1
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2018-08-27T06:29:11Z
Last change time
2018-11-08T05:21:14Z
Keywords
bootcamp
Assigned to
Tiberiu Lepadatu
Creator
ZombineDev
Comments
Comment #0 by petar.p.kirov — 2018-08-27T06:29:11Z
Since core.internal.hash.hashOf is a template, there are a number potential benefits:
* better performance (e.g. more opportunities for inlining, less indirections for value types)
* less dependence on TypeInfo (which we want to phase out in the long term)
* -betterC friendly (no need to link druntime and phobos to your library / app, in order to use simple templates like std.typecons.Nullable)
Comment #1 by tiberiulepadatu14 — 2018-10-21T12:02:57Z
(In reply to ZombineDev from comment #0)
> Since core.internal.hash.hashOf is a template, there are a number potential
> benefits:
> * better performance (e.g. more opportunities for inlining, less
> indirections for value types)
> * less dependence on TypeInfo (which we want to phase out in the long term)
> * -betterC friendly (no need to link druntime and phobos to your library /
> app, in order to use simple templates like std.typecons.Nullable)
I have started working on this but when I change typeid(T).getHash(..) to hashOf at line 2682 the unittest is failing. Is the return of the hashOf different that the one for the one for the typeid(T).getHash(..)?
Comment #2 by n8sh.secondary — 2018-10-22T03:09:30Z
>Is the return of the hashOf different that the one for the one for
>the typeid(T).getHash(..)?
It can be.
https://dlang.org/phobos/object.html#.hashOf
>Calculates the hash value of `arg` with an optional `seed` initial
>value. The result might not be equal to `typeid(T).getHash(&arg)`.
Comment #3 by n8sh.secondary — 2018-10-22T22:05:53Z