On Monday, 9 April 2012 at 15:37:37 UTC, Andrej Mitrovic wrote:
On 4/9/12, Jakob Ovrum <[email protected]> wrote:
The one taking (const(char)[] s) does this, but not the other
overload
taking (string s). Whether or not that's safe I don't really
know.
I've had an argument over this on github, but I don't know if
it was
about toStringz or maybe toUTF16z. I haven't got the link to the
discussion.
You're right, I just confirmed the optimization is still in place
for the `string` version. The documentation is identical for both
functions. I think this is a mistake.
It assumes that the string is either a compiler-generated literal
or a GC allocated string, while the documentation does not
mention such assumptions. With all the focus on manual memory
management and pluggable allocators going on, I think the
optimization must be removed or the documentation for the
`string` overload changed.
This optimization can always be put back in without narrowing the
scope of the `string` overload once the above conditions can be
reliably checked.
Another option is to add a known-bug section to the `string`
overload informing users that the function may fail on
custom-allocated strings.
