Probably trivial, but VERY frustrating compiler bug
schveiguy at gmail.com
Fri Aug 14 12:47:01 UTC 2020
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.
> 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:
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.
More information about the Digitalmars-d