<div dir="ltr"><div class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">That's a much nicer way of saying what I was trying to get across.  :-)</div><div class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">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.</div><div class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">--bb</div><br class="gmail-Apple-interchange-newline"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 1, 2018 at 1:49 PM, Jonathan M Davis via Digitalmars-d-announce <span dir="ltr"><<a href="mailto:digitalmars-d-announce@puremagic.com" target="_blank">digitalmars-d-announce@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, March 01, 2018 13:24:29 Bill Baxter via Digitalmars-d-announce<br>
wrote:<br>
<span class="">> Just don't overlook the fact that people who fill out 30 minute surveys<br>
> right away after being told about them are a self-selected group of people<br>
> who apparently have way too much time on their hands.<br>
> Which also suggests they would likely also have more free time to go chase<br>
> down and fix breaks in their legacy code caused by new compilers.<br>
<br>
</span>It's also the case that the folks who even see this survey are likely to be<br>
a fairly small percentage of the actual user base. So, while its results may<br>
be useful, they need to be viewed with that fact in mind.<br>
<br>
That being said, I think that it's a given that we need to make breaking<br>
changes at least occasionally. The question is more how big they can be and<br>
how we go about it. Some changes would clearly be far too large to be worth<br>
it, whereas others clearly pay for themselves. The harder question is the<br>
stuff in between.<br>
<br>
For instance, while we might not actually have a new operator if D were<br>
being redesigned from the ground up (Andrei has previously stated that it<br>
really should have just been a function in the standard library or runtime),<br>
that would be far too large a change with far too little benefit to be even<br>
vaguely worth it at this point. On the other hand, we _did_ change it so<br>
that switch statements don't have implicit fallthrough anymore, and that<br>
change was _very_ well received, because it caught bugs and it was a quick<br>
fix to update correct code that was then an error (it was probably also true<br>
that relatively little correct code had to be updated, but that's harder to<br>
measure).<br>
<br>
Each potential breaking change has to be weighed on its own, and the real<br>
question is how strongly we weight the pros vs the cons. We could choose to<br>
favor breaking code only when it's cleary _very_ benificial to do so, or we<br>
could choose to break code any time there's even a slight benefit to it. I<br>
think that it's pretty clear that the right choice is somewhere in between<br>
those two extremes, but it's not an easy question as to where it is.<br>
<br>
And as has been discussed before, we have folks clamoring for breaking<br>
changes and folks clamoring for nothing to ever break, and sometimes,<br>
they're exactly the same folks. :|<br>
<br>
- Jonathan M Davis<br>
<br>
</blockquote></div><br></div>