fix dlang#10806 - std.csv inconsistently overrides Exception.toString

[VPanteleev-S7]

RFC - this does regress the pure/@safe/const attributes of toString.

[dlang-bot]

Thanks for your pull request and interest in making D better, @VPanteleev-S7! 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 coverage diff by visiting the details link of the codecov check)
• 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.

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#10807"

[dkorpel]

I'm a bit on the fence because on one hand, this a breaking change, but on the other hand, class inheritance and attributes don't mix well so I don't expect people to call Class.toString in @safe pure code often.

One way to keep the current attributes is to make a @safe pure version of Throwable.toString that CSVException can use in its overrides. Do you think that's worth doing?

[VPanteleev-S7]

In terms of global improvements, we do have Throwable.message, which is still reserved via __future. It does seem like the perfect use case for it.

An alternative, more pragmatic solution would be to forego the toString override and just do the string formatting up-front in the CSVException constructor. We're using exceptions already, that by itself implies some GC use, and a couple string allocations for an exceptional case wouldn't make much of a difference.

[dkorpel]

That alternative solution sounds good to me 👍