`type B = distinct A` should not be `Ordinal` (when A is), high+friends shouldn't be defined by default

[timotheecour]

example

With type B = distinct A, procs for B must be re-implemented or borrowed, but there is currently an exception for certain procs like high + friends. This is an odd special case going against what distinct is about.

For example this may not be suitable for Z/nZ (https://en.wikipedia.org/wiki/Quotient_group) or for example for Z* = Z - {\0} or type Holy = distinct MyEnum which would re-implement some procs to disallow some value. There are other example use cases where automatically adding Ordinal behavior or high etc is undesirable.

proposal

these don't involve a breaking change:

• new type B {.pure.} = distinct A which makes B not ordinal
• type B {.ordinal.} = distinct A which makes B ordinal when A is Ordinal, or CT error when A is not Ordinal

and maybe in future:

• after a warning phase, we can think of changing the default to be that of {.pure.} instead of that of {.ordinal.}

bikeshedding

pure or nonordinal

links

this came up in https://github.com/nim-lang/Nim/pull/16681#issuecomment-757893543, read this thread

[Araq]

In this case, I think we should break code and declare it to be a compiler bugfix.

[timotheecour]

In this case, I think we should break code and declare it to be a compiler bugfix.

this could cause headaches (the usual reason: 3rd party code over which you have little control), and indeed, like you said elsewhere:

Tried to fix that once but broke too much code

In this case, I'm not sure a legacy flag -d:nimLegacyDistinctOrdinal is sufficient.

There are valid cases where an ordinal is desired, so type B {.ordinal.} = distinct A still makes sense to have; eg: type Second = distinct int

It's quite likely that a reasonable sized projects would end up with dependencies A, B where A assumes non ordinal distinct and B assumes ordinal distinct, for which a global flag -d:nimLegacyDistinctOrdinal doesn't help.

The declarative approach i suggested allows granular decisions and working with such A, B dependencies, and still allows changing the default at some later time (but provides an easier path to upgrade code incrementally instead of all at once).