Adds Typedef.toString()

[denizzzka]

It is need to avoid silent conversion of Typedef struct itself to string by std.conv.to.

Discussion:
https://forum.dlang.org/post/kjzayldqnixehfprgslc@forum.dlang.org

Previous attempt: #6217

[dlang-bot]

Thanks for your pull request and interest in making D better, @denizzzka! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[denizzzka]

I am should use git squash or this is not necessary?

[thewilsonator]

Yes do squash. Don't worry about the formatting, see #6220

[wilzbach]

Don't worry about the formatting, see #6220

FWIW: This is something different. dmd-cxx is the old C++ branch that didn't compile for years and it's slowly brought back to life (and no one plans to develop with it, we just want to get it to pass on the auto-tester).
Anyhow, while sticking to the DStyle is a requirement for official code, it's not blocking your PR. Every maintainer can easily fix that for you if there's interest in the PR (i.e. the idea has been approved.)

---

Now back to the PR in question, is there any reason why you didn't add a writer-based toString?
string toString isn't really nice, because it always allocates which is slow.

@JackStouffer has been working hard on adding writer-based toString overloads, even for the mentioned Nullable.toString: #6198

[MetaLang]

Sorry @denizzzka, I've been busy with other work the past few days and did not have time to properly review this. As @wilzbach pointed out, it would be preferably to add a writer-based overload of toString so there will be no allocation at all when possible. Take a look at the aforementioned pull request he linked to see how to do it.

[denizzzka]

Changed for writer support and squashed

[MetaLang]

This overload should be documented and considered the "primary" one, with the other just marked as "ditto". Explain that this forwards to the wrapped value and the results between <base type value>.to!string() and <Typedef'd type value>.to!string() will be identical.

[denizzzka]

I do not know how to describe this beautifully, just added an example.

[MetaLang]

This is incorrect, as each overload will show up separately in the documentation, and it will confuse readers if you say that this one could return void or string.

[denizzzka]

(This is copy and paste from Nullable, so its documentation is weak too)

[MetaLang]

More unit tests are needed that test both overloads of toString with multiple different types of values.

Another good test to add would be something like the following to be reasonably sure that the results of Typedef.toString are the same as the base type:

import std.meta: AliasSeq;
import std.conv;

struct TestS {}
class TestC {}

static foreach (T; AliasSeq!(int, bool, float, double, real, ifloat, idouble, ireal,
                             cfloat, cdouble, creal, char, dchar, wchar, TestS, 
                             TestC, int*, int[], int[2], int[int]))
{{
    T t;
    Typedef!T td
    assert(t.to!string() == td.to!string());
}}

[denizzzka]

Something strange with CI check

[wilzbach]

Not too strange though.
Just follow the advice of the message and add @safe to your unittest. Explicit annotation is required because it's too often forgotten.

[denizzzka]

Oh, thank you, did not noticed by myself.

[MetaLang]

Thanks @denizzzka!