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