hashes for refs should be an opt-in feature

[narimiran]

refs #17858:

This does not resolve the issue really, of breaking working code in minor releases - the new hash function must be opt-in in order for that to happen

This is a temporary solution, @Araq has something better in the works.

[timotheecour]

This is not a good change. The fact that hash(ref) was missing was arguably a weird omission given that hash(ptr) and hash(pointer) work (and was inconsistent with the fact that == works with ptr|pointer|ref).

We should fix stdlib and fix bugs/mis-designs instead of piling up historical artifacts just because (i still haven't seen a bug report showing some actual code that broke in their project as a result of this).

Users that need custom hash for ref type (even generic ones) can already do this and #17731 contains runnableExamples for that, this still works. And it's easy enough to add -d:nimLegacyNoHashRef in you user/project/file config, or even in code via {.define(nimLegacyNoHashRef).}, as a temporary workaround.

Turning the correct behavior as opt-in instead of opt-out is what will create dialects, not the other way around.

[Araq]

Holidays are over, I'll come up with a good solution but in the meantime, this solution is less risky.

[arnetheduck]

The way to introduce breaking changes such as these without flags is to put them in a separate module - this doesn't create dialects and works for composing libraries that rely on different "versions". A flag is almost never the right solution, in any direction, but an "enable" flag is less harmful than a "disable" flag.

This is a reality of the Nim language that maintainers of the std lib in particular should be aware of, that open generic symbols cannot be introduced compatibly, specially not for central parts of the std lib like hash, because inevitably, they will be sandwitched into the wrong places with difficult-to-debug runtime issues. It's good to see that compatibility is taken seriously, it's of paramount importance for any longer-term usage of the language.

(of course, introducing a new module is a good workaround while other solutions are being explored)