That's a much nicer way of saying what I was trying to get across. :-) Early respondents to a lengthy survey about D usage are not necessarily a good representation of the more casual user's needs for the language.
--bb On Thu, Mar 1, 2018 at 1:49 PM, Jonathan M Davis via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote: > On Thursday, March 01, 2018 13:24:29 Bill Baxter via Digitalmars-d-announce > wrote: > > Just don't overlook the fact that people who fill out 30 minute surveys > > right away after being told about them are a self-selected group of > people > > who apparently have way too much time on their hands. > > Which also suggests they would likely also have more free time to go > chase > > down and fix breaks in their legacy code caused by new compilers. > > It's also the case that the folks who even see this survey are likely to be > a fairly small percentage of the actual user base. So, while its results > may > be useful, they need to be viewed with that fact in mind. > > That being said, I think that it's a given that we need to make breaking > changes at least occasionally. The question is more how big they can be and > how we go about it. Some changes would clearly be far too large to be worth > it, whereas others clearly pay for themselves. The harder question is the > stuff in between. > > For instance, while we might not actually have a new operator if D were > being redesigned from the ground up (Andrei has previously stated that it > really should have just been a function in the standard library or > runtime), > that would be far too large a change with far too little benefit to be even > vaguely worth it at this point. On the other hand, we _did_ change it so > that switch statements don't have implicit fallthrough anymore, and that > change was _very_ well received, because it caught bugs and it was a quick > fix to update correct code that was then an error (it was probably also > true > that relatively little correct code had to be updated, but that's harder to > measure). > > Each potential breaking change has to be weighed on its own, and the real > question is how strongly we weight the pros vs the cons. We could choose to > favor breaking code only when it's cleary _very_ benificial to do so, or we > could choose to break code any time there's even a slight benefit to it. I > think that it's pretty clear that the right choice is somewhere in between > those two extremes, but it's not an easy question as to where it is. > > And as has been discussed before, we have folks clamoring for breaking > changes and folks clamoring for nothing to ever break, and sometimes, > they're exactly the same folks. :| > > - Jonathan M Davis > >
