On 9/28/2014 5:09 AM, Andrei Alexandrescu wrote:
Stuff that's missing:
* Reasonable effort to improve performance of auto-decoding;
* A study of the matter revealing either new artifacts and idioms, or the
insufficiency of such;
* An assessment of the impact on compilability of existing code
* An assessment of the impact on correctness of existing code (that compiles and
runs in both cases)
* An assessment of the improvement in speed of eliminating auto-decoding
I think there's a very strong need for this stuff, because claims that current
alternatives to selectively avoid auto-decoding use the throwing of hands (and
occasional chairs out windows) without any real investigation into how library
artifacts may help. This approach to justifying risky moves is frustratingly
unprincipled.
I know I have to go a ways further to convince you :-) This is definitely a
longer term issue, not a stop-the-world-we-must-fix-it-now thing.
Also I submit that diverting into this is a huge distraction at probably the
worst moment in the history of the D programming language.
I don't plan to work on this particular issue for the time being, but do want to
stop adding more autodecoding functions like the proposed std.path.withExtension().
C++ and GC. C++ and GC...
Currently, the autodecoding functions allocate with the GC and throw as well.
(They'll GC allocate an exception and throw it if they encounter an invalid UTF
sequence. The adapters use the more common method of inserting a substitution
character and continuing on.) This makes it harder to make GC-free Phobos code.
