As a Windows programmer using D, I find a number of questionable
things with D's focus on using string everywhere. It's not a huge
deal to add in UTF-8 to UTF-16 mapping in certain areas, but when
it comes to working with a lot of data and Windows API calls, the
less needless conversions the better.
I like the DirEntries (std.file) approach to traversing files and
folders in a directory (almost as nice as C++14's <filesystem>),
but I think its a bit odd that native-OS strings aren't used in D
here. Sure, I get that having a fairly consistent programming
interface may make using the language easier for certain
programmers, but if you're using D with Windows, then you will be
made well aware of the incompatibilities between D's strings and
the Windows API (unless you always use ASCII I suppose).
Anyway, I'm curious if proposing changes to those interfaces is
worthwhile, or if I should just modify it for my own purposes and
leave the standard library be.
P.S. Its a shame to keep running into Unicode issues with D and
Windows, and sometimes its a bit discouraging. Right before I
peeked into DirEntry, I worked a bit on a workaround for
stdio.File's unicode problems (a documented bug thats 2+ years
old). I remember trying D a while back and giving up because
optlink was choking on paths. And just yesterday it choked on
what the %PATH% environment variable was set to, so I had to
clear that before running it.
- DirEntry on Windows - wstring var... dcrepid via Digitalmars-d-learn
-
