Bug 10427 – No opEquals method in std.random.MersenneTwisterEngine
Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-06-20T13:38:00Z
Last change time
2013-06-20T16:40:50Z
Assigned to
nobody
Creator
joseph.wakeling
Comments
Comment #0 by joseph.wakeling — 2013-06-20T13:38:23Z
MersenneTwisterEngine should have an .opEquals() method like Xorshift and the Linear Congruential generator.
Because it's currently a value type the lack seems innocuous, but it will cause issues if/when the design is converted to a reference type.
Comment #1 by issues.dlang — 2013-06-20T14:21:02Z
How is this a bug? It doesn't _need_ an opEquals, so it would be bad practice to add one. If it's changed to a reference type, _then_ you need opEquals, and you implement it. But until it's a reference type, opEquals is unnnecessary, and not having it is most definitely not a bug.
If anything, the fact that XOrshiftEngine and LinearCongruentialEngine have opEquals have opEquals is the bug. As far as I can tell, they don't need them. Please _don't_ declare opEquals on types that don't need them. It _increases_ the chances of there being a bug, because the opEquals could be wrong. It could also be less efficient than what the compiler would have done on its own.
Comment #2 by joseph.wakeling — 2013-06-20T14:30:40Z
It's a discrepancy I noticed, so I thought it should be on record. The concern was that when the RNGs _are_ converted to reference types, the lack of opEquals in one out of three might be overlooked.
The unittests I've submitted earlier today should catch that if it happens, though.
Comment #3 by issues.dlang — 2013-06-20T15:39:01Z
While I understand the concern about the possibility of introducing a bug, bug reports are for actual bugs, not for potential bugs. And unit testing is exactly how you prevent such regressions from creeping into the code.
Comment #4 by joseph.wakeling — 2013-06-20T16:40:50Z