On 06/01/2016 06:09 PM, ZombineDev wrote:
Regardless of how different people may call it, it's not what this thread is about.
Yes, definitely - but then again we can't after each invalidated claim to go "yeah well but that other point stands".
Deprecating front, popFront and empty for narrow strings is what we are talking about here.
That will not happen. Walter and I consider the cost excessive and the benefit too small.
This has little to do with explicit string transcoding in foreach.
It is implicit, not explicit.
I don't think anyone has a problem with it, because it is **opt-in** and easy to change to get the desired behavior.
It's not opt-in. There is no way to tell foreach "iterate this array by converting char to dchar by the usual language rules, no autodecoding". You can if you e.g. use uint for the iteration variable. Same deal as with .representation.
On the other hand, trying to prevent Phobos from autodecoding without typesystem defeating hacks like .representation is an uphill battle right now.
Characterizing .representation as a typesystem defeating hack is a stretch. What memory safety issues is it introducing?
Andrei
