On Thursday, August 23, 2018 3:26:46 AM MDT rikki cattermole via Digitalmars-d wrote: > > * Language complexity > > > > Raise your hand if you know how a class with both opApply and the > > get/next/end functions behaves when you pass it to foreach. How about a > > struct? Does it matter if it allows copying or not? > > get/next/end functions, what?
I'm sure that he meant front, popFront, and empty. And yes, the fact that we have both opApply (the D1 solution for supporting foreach) and ranges (the D2 solution for foreach) definitely complicates things. Those two features do theoretically interact properly, because work was done several years ago to ensure that they did, but while they may interact properly from a technical standpoint, it's a mess from a social standpoint. I'm sure that some of the folks here could correctly answer whether foreach or the range API wins with foreach, but it's really not the sort of thing that the average D programmer is going to know, and while IIRC, there is very good reasoning as to which one wins, it's not immediately obvious to most folks. I _think_ that it's opApply that wins, but I'd have to either look it up or test it, and while I certainly don't know everything there is to know about D, given how much I've been involved with D, if I don't know something about it, the odds are pretty good that a lot of D programmers don't. D does have a problem in general of having a lot of great features that work really well in isolation but don't necessarily work well in concert (and it doesn't help that some features have really never been properly finished). And frequently, the answer that folks go with is to simply not use sections of the language (e.g. it's _very_ common for folks to just give up on a lot of attributes like pure, nothrow, or @safe). A number of the issues do get worked out over time, but not all of them do, and sometimes the solutions cause a lot of problems. For instance, DIP 1000 may end up being great for @safe and will help solve certain issues, but it results in yet another attribute that has to be pasted all over your code and which most folks simply won't use. So, it's helping to fix a real problem, but is it making things better overall? I don't know. And while I definitely think that D is easier to understand than C++ (in spite of the increase in D's complexity over time), it's also very much true that D continues to get more and more complicated as we add more stuff. Generally, each solution is solving a real problem, and at least some of time, the solution actually interacts quite well with the rest of the language, but it all adds up. And honestly, I don't think that there's a real solution to that. Languages pretty much always get more complicated over time, and unless we're willing to get rid of more stuff, it's guaranteed to just become more complicated over time rather than less. D definitely improves over time, but certain classes of issues just never seem to be fixed for some reason (e.g. the issue with RAII and destructors really should have been fixed ages ago), and some of the major design decisions don't get fully sorted out for years, because they're not a high enough priority (e.g. shared). I don't really agree that D is in much danger of dying at this point, but I completely agree that we as a group are not doing a good enough job getting some of the key things done (much of which comes down to an issue of manpower, though some of it is also likely due to organizational issues). - Jonathan M Davis
