Probably trivial, but VERY frustrating compiler bug

[Steven Schveighoffer]

On 8/14/20 1:26 AM, FeepingCreature wrote:
> On Friday, 14 August 2020 at 03:56:38 UTC, Steven Schveighoffer wrote:
>> On 8/13/20 6:20 PM, Adam D. Ruppe wrote:
>>> On Thursday, 13 August 2020 at 22:14:15 UTC, H. S. Teoh wrote:
>>>> In a nutshell: the exact .stringof of certain function symbols 
>>>> changes depending on which overload was processed first.
>>>
>>> wait why the heck is it using .stringof at all? This inside dmd 
>>> itself? I know it uses mangle toChars in places but the stringof 
>>> thing should be for user diagnostics only, no internal use.
>>>
>> What is the correct way to get a string representation of a type if 
>> not T.stringof? This is inside Phobos, not DMD.
>>
> 
> "T".
> 
> The obvious question is "why do you want a string representation of a 
> type"? For debugging? stringof. For later accessing? Find a way to make 
> an alias of the type visible at that spot, then use the alias's name.

Serialization is the only thing I can think of that both requires you 
generate a string for each type, and that the string is consistent 
across versions. I mean, you can invent a naming scheme, but if the 
compiler can provide it, it's much easier to deal with.

I can use the rat's nest that is fullyQualifiedName. But if the compiler 
had a strict definition of T.stringof (and bonus, if it did what 
fullyQualifiedName did), then one could actually use it in cases where 
one needs a string representation of the type.

As of now, there are three ways the compiler can give you names of a type:
1. T.stringof
2. typeid(T).name
3. __traits(identifier, T)

It would be awesome if all of these were consistent and well-defined.

I just looked at one place where I did some serialization that required 
storing the type name, and I actually had to follow a specific protocol, 
so I didn't need this.

My question really was that -- a question, not an argument.

-Steve