35 karma · joined September 12, 2014
But D arrays/slices are already ranges. Is this referring to string autodecoding or something else completely? I fail to recall any situations where builtin types required wrappers often.
>Insistence on returning things exclusively as ranges, even when a single item is wanted, so calling code must be cluttered with dereferencing. (e.g. std.algorithm.searching.find)
This is mirroring C++ iterator design and IMO the right move though I agree that specifically for ranges it is rather awkward to use in practice.
What would you return instead? A pointer? What if one wants to find the position of the element and do something after that with that position/subrange.
They need to add/fix like 5-6 different parts of the language to even begin addressing this in a meaningful way.
D is by no means perfect (and over the years it has accumulated lots of warts) but if you know what you are doing it enables amazing productivity and almost never gets in your way. If you have an idea about solving a problem in a particular way there's almost always a path available to do just that without running into "computer says no" situations (stares at Go).
The truth is it was good enough for most uses already but people waited out for someone to step up and make things better before they felt it would be worth trying D
D really shines if you do greenfield projects where you have the luxury to reinvent some wheels. Its surprisingly pleasant to see a lot of boilerplate one might expect to accumulate to just not be there because it’s either generated or is just not necessary because the language is flexible enough
That being said standard formatting function can automatically print most types including user types. This eliminates necessity for automatic formatting implementation in majority of situations