On 11/2/14 10:07 PM, Dicebot wrote:
On Sunday, 2 November 2014 at 18:42:20 UTC, David Nadlinger wrote:
Imagine somebody has a type that cannot be @trusted because of
whatever reason. Maybe because it's legacy code, maybe it uses
resources it does not manage, … If you forcibly make logf @safe, then
this type cannot be used with logf without some crazy workaround
(simply using to!string might produce an unneeded allocation if the
type uses the sink-delegate signature for toString).
Why not leave this up to the compiler and support more use cases
without degrading the experience for @safe clients?
David
You mean something like user type toString() which is legitimately
@system and can't be made @trusted? Yes, this makes sense. Will need to
also add tests for that.
Consider me convinced :)
Fantastic, thanks! -- Andrei
