Probably trivial, but VERY frustrating compiler bug

[H. S. Teoh]

On Fri, Aug 14, 2020 at 05:26:06AM +0000, FeepingCreature via Digitalmars-d 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.
> > 
> > -Steve
> 
> "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.

This is std.format, it's trying to print a user-readable string that
represents the type name.  Using .stringof is precisely what .stringof
was made for, isn't it?

The problem comes when overzealous unittesting wants to write a unittest
to test that the code is doing its job in calling .stringof.  Just like
unittests that assert(1+1 == 2) just in case the compiler isn't doing
its job, or perhaps the CPU is, heaven forbid, *malfunctioning*,
unittests of this sort inevitably cause more frustration than they help.
IOW, the unittest is testing something outside the control of the code
it's supposed to be testing, and thereby introduces an extraneous
dependency on outside behaviour.


T

-- 
My program has no bugs! Only undocumented features...