Policy for exposing range structs

[Johan Engelen via Digitalmars-d]

On Friday, 25 March 2016 at 19:04:46 UTC, Anon wrote:
>
> Two changes to the mangling:
>
> 1) `LName`s of length 0 (which currently cannot exist) mean to 
> repeat the previous `LName` of the current symbol.
>
> 2) N `Number` is added as a valid `Type`, meaning "Type Back 
> Reference". Basically, all instances of a 
> struct/class/interface/enum type in a symbol's mangling get 
> counted (starting from zero), and subsequent instances of that 
> type can be referred to by N0, N1, N2, etc.

I have implemented the second part (simplest I thought) to see 
what it would bring (in LDC). 'Q' seems unused, so I used that 
instead of 'N'  ;)
I'm not 100% certain of the implementation, as it relies on DMD 
using the same pointer values for recurring types but it seemed 
to work with complicated code.
The core.demangle demangler was relatively easy to upgrade for 
repeated types.

Unfortunately, and perhaps expectedly, it did not give a large 
size reduction / speed boost. Not very statistically sound 
results though ;)
The change is relatively easy, I think, so perhaps it is still 
worthwhile pursuing.

An implementation issue that changes in mangling have to deal 
with:
One surprising thing was that std.traits uses the mangled name in 
`ParameterStorageClassTuple`. So std.traits contains its own mini 
mangling parser, and also calls .mangleof on Types, to skip to 
the next function argument in the mangled function string. The 
"type back reference" scheme means that Type.mangleof may not 
correspond to how the Type embedded in the mangling of a 
function, and so I had to upgrade std.traits with its own parser 
(I copied core.demangle.Demangle, and removed all output 
complications).

For changes in mangling, it'd be good if 
std.traits.ParameterStorageClassTuple could be rewritten to not 
use the mangled function name + string processing.