distinctBase overload for values

[timotheecour]

the overload for values (instead of types) is the one that's needed most often, and writing it inline everywhere or define their own helper for that everywhere needed is pointless and encourages the worse alternative getFoo(args).Bar out of laziness, see below.

example 1

type Foo = distinct Bar
echo distinctBase(typeof(getFoo(args))).getFoo(args) # before this PR
echo getFoo(args).Bar # bad alternative (not DRY, error prone, and not always possible if Bar is not in scope)
echo getFoo(args).distinctBase # with this PR

example 2

when $ for a distinct type is not defined in scope, you can do:

proc `$`(a: distinct): string = $a.distinctBase # match all distinct
proc `$`(a: TLineInfo): string = $a.distinctBase # or just 1 specific type
echo myvar # myvar object could contain sub-fields that are distinct

this provides a more flexible alternative to the ones discussed in nim-lang/RFCs#203 since we have fine grained control over which distinct fields get shown

note

a lot of time has passed since #8531 (comment) and my experience shows this overload is indeed needed. There is no bloat since that symbol is already defined anyways.

[Clyybber]

distinct types should really be distinct and I think its a bad idea to make it easy to undistinct a type if you don't even know what type it's distinct base is or if that type isn't even in scope.

[timotheecour]

it's needed for generic code, which can't guess what the base is without distinctBase, eg:

• repr uses that
• custom serialization, debugging, hashing, prettyprinting
• when the $ + procs provided with the distinct type are either missing or not suitable

bad idea to make it easy to undistinct

I don't buy this argument. Making something hard on purpose doesn't prevent anything and just causes friction. The conversion is explicit, not implicit, so there's no danger here and nim is a systems programming language, not a nanny, and shouldn't get in the way.

[Araq]

I like it enough to merge it already.