https://issues.dlang.org/show_bug.cgi?id=12448
--- Comment #12 from Jonathan M Davis <[email protected]> --- (In reply to bearophile_hugs from comment #11) > (In reply to Jonathan M Davis from comment #10) > > we risk ending up with such code breaking when scope > > actually gets fully implemented > > Implementing scope/in will just disallow some current wrong usages, so it > will just break code, it will not introduce actual (silent) bugs, that are > the dangerous ones. Just because code breakage isn't silent doesn't mean that it's good. It isn't even properly defined what scope is supposed to mean, so you can't even know for sure what correct usage is. In theory, it's only supposed to be used with parameters which don't escape a function, but since that's not well-defined, it's arguably impossible to know for sure whether you're using it correctly, and even if we knew for sure exactly what it meant, if you still end up using it in the wrong way, then your code will break when scope is properly implemented, whereas it wouldn't break if you just didn't use it. So, using scope or in before they're properly implemented really doesn't buy you anything, and it risks breaking code once they are implemented. Regardless, putting scope on toStringz is fundamentally wrong, because it's not guaranteed that the pointer being returned doesn't refer to the string being passed in. And even if we don't know exactly what constitutes escaping a function, I think that it's pretty clear that returning a pointer to the contents of the in parameter would mean that the parameter escaped the function. --
