fix Issue 16495 - __traits(fullyQualifedName) instead of std.traits.f…

[WalterBright]

…ullyQualifiedName

As the bug report suggests, this is better done in the compiler than with complex metaprogramming which is a bit of a speed problem. The library template also duplicates code which must be in the compiler anyway, why do it twice.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	16495	enhancement	__traits(fullyQualifedName) instead of std.traits.fullyQualifiedName

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14711"

[WalterBright]

Will add more tests later.

[ljmf00]

I'm in favor of this change. I would like to point out there's also another problematic trait that is way simpler to implement in the compiler and increase a lot compile-times. moduleName and a derivative implementation of it, moduleSymbol, is way harder to implement as a library, and in some cases is actually impossible, because the compiler yields a forward reference error due to __traits(parent) requiring to resolve the types of that symbol. I would suggest to add a __traits(moduleSymbol, symbol) too.

[WalterBright]

@lmjf00 Please file enhancement requests in bugzilla.

[RazvanN7]

Will add more tests later.

@WalterBright any progres on this?

[WalterBright]

I added the tests from std.traits. But the results aren't identical, as there are multiple ways to print the same fully qualified name.

[RazvanN7]

Also, please replaces the pragma(msg)s with static asserts in test16495.d.

[RazvanN7]

This line is redundant. `TemplateInstance.semanticTiargs is already called at the beginning of this function.

[WalterBright]

It's not quite the same. The sc2.flags are changed.

[RazvanN7]

Yes, but since semantic has already been performed all of the expressions have their type set and when they hit the expression semantic visit methods (which typically start with if (exp.type) return) no analysis is done. So, I suspect that this code only adds a couple of function calls that simply return.

[RazvanN7]

Could we start deprecating std.traits.fullyQualifiedName?

[WalterBright]

Could we start deprecating std.traits.fullyQualifiedName?

Better to just re-implement it as a shell calling __traits.

implemented

[WalterBright]

Documentation: dlang/dlang.org#3495

[adamdruppe]

As I've said many many times, any code that calls this is questionable. There's no real benefit to improving a function that should never actually be used.

I'm not against it per se, but.... if people think they need this, they're almost certainly wrong.

[RazvanN7]

@WalterBright Just add a small changelog entry so that users of the next release can find out about this feature and we are good to go. Thanks!

[dkorpel]

There's still test coverage missing for failure cases

[adamdruppe]

Why are we adding more useless cruft to the language when there clear cases of harm done by it that is avoided by easy to use alternative techniques?

[WalterBright]

failure cases

Those are kinda hard to figure out how to trigger.