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 :)
