>Heavy reliance on the range interface, without automatic support for common range-like types like arrays, so calling code must be cluttered with wrappers.
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.
Even if the decision to close the door on this sucks I think they are correct - this is not a syntax problem. Adding sugar will not fix fundamental issues w/ Go's error handling.
They need to add/fix like 5-6 different parts of the language to even begin addressing this in a meaningful way.
Programming in D after C++ is like the opposite of death by 1000 cuts - its just a constant stream of finding nice little things that simplify your life or avoid footguns. You become accustomed to all the niceties very fast and its hard to justify going back haha.
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).