Fix Issue 20502: Converting std.typecons.RefCounted!T to a string gives T's storage location instead of T's fields when T is a struct without an explicit toString

[n8sh]

Example of what this PR fixes:

void main()
{
    import std.typecons : refCounted;
    import std.stdio : writeln;

    writeln(123); // "123"
    writeln(refCounted(123)); // "123"
    
    struct A { string toString() { return "a"; } }
    writeln(A.init); // "a"
    writeln(refCounted(A.init)); // "a"

    // This one doesn't match:
    struct B { int x; }
    writeln(B(123)); // "B(123)"
    writeln(refCounted(B(123))); // "RefCounted!(B, cast(RefCountedAutoInitialize)0)(RefCountedStore(558C7FFBC660))"
}

[dlang-bot]

Thanks for your pull request, @n8sh!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20502	minor	Converting std.typecons.RefCounted!T to a string gives T's storage location instead of T's fields when T is a struct without an explicit toString

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 + phobos#7352"

[MoonlightSentinel]

Compiling with DMD master prints:

123
123
a
a
B(123)
B(123)

Is there a mistake in your example?

EDIT: This was tested on Win10, run.dlang.io yields the RefCounted!(B, cast(RefCountedAutoInitialize)0)(RefCountedStore(558C7FFBC660))

[n8sh]

@MoonlightSentinel I've verified this is still happening with freshly-compiled DMD master with that example verbatim. Pasting the example into https://run.dlang.io/ and running it also gives that result.

[MoonlightSentinel]

Strange, are you on Mac/Posix?

[atilaneves]

Is there a reason for this to be @system other than the cast?

[n8sh]

RefCounted in general is @system.

[n8sh]

@MoonlightSentinel I've tested this on Windows 10 using dmd v2.090.0. Maybe you had this branch checked out and dmd used it when you ran the example so the fix was already applied.

[MoonlightSentinel]

@MoonlightSentinel I've tested this on Windows 10 using dmd v2.090.0. Maybe you had this branch checked out and dmd used it when you ran the example so the fix was already applied.

I somehow missed that the above behaviour was fixed and thought it was still present. Sorry for the noise

[MoonlightSentinel]

Maybe add tests for const/immutable RefCounted (and maybe other storage classes as well)

[berni44]

@RazvanN7 Browsing through old issues I came across this PR. Seems to be one of the forgotten PRs, that could be merged (after fixing the trivial merge conflict). In my opinion the request of @MoonlightSentinel for const/immutable RefCounted is an enhancement, not a must have (don't let the best be the enemy of the better).

[RazvanN7]

LGTM. Please fix the merge conflict and we're good to go.