provided toString() because strlen must die

[WalterBright]

No description provided.

[dlang-bot]

Thanks for your pull request, @WalterBright!

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.

Testing this PR locally

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

dub fetch digger
dub run digger -- build "master + dmd#8550"

[JinShil]

You could replace a toChars or two to get full test coverage.

[Geod24]

SemaphoreCI was stuck.
I think it'll be better to store the length instead of calling strlen on every toString, but it's already an improvement.

[jacob-carlborg]

Here new public symbols were added without Ddoc 😞.

[jacob-carlborg]

How will this affect the C++ headers?

[JinShil]

Here new public symbols were added without Ddoc 😞.

Have you ever tried to convince @WalterBright to do things like this? It's better if we just merge and add the docs ourselves in a separate PR.

[jacob-carlborg]

We managed to get him to do PRs instead of pushing directly. Also he’s the one nagging everybody else to have proper Ddoc sections.

[WalterBright]

How will this affect the C++ headers?

It won't. They are not callable from C++, and they don't occupy a slot in the vtbl[].

without Ddoc

If it did something different than every other toString() in dmd, then it would need a Ddoc. Actually, if it did something different than every other toString(), it should have a different name as well as a Ddoc.

As always, use your best judgement.

[WalterBright]

I think it'll be better to store the length instead of calling strlen on every toString, but it's already an improvement.

It may be. But by adding this function, the need for strlen becomes encapsulated, and is not leaked to the users of the object. A sign of effective encapsulation is being able to change the underlying data structure without needing to change any users of the object.

[jacob-carlborg]

It won't. They are not callable from C++, and they don't occupy a slot in the vtbl[].

👍.