std.experimental.logger formal review round 3

[Dicebot via Digitalmars-d]

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