I recall Andrei's talk about what to do if you want a million users. Do as you would do if you had a million users.<br><br>Certain changes make sense to have if D is to have a million users. Some of them, unfortunately, would be a pointless hassle to existing users. It's a difficulty that unlikely to get solved through arguing.<br>

<br>One possible approach would be as with python 2 vs python 3. Have a "different" D branch that pays far less attention to current users, and far more to the millions ahead. And build conversion tools alongside, to help current users convert when (and IF) the new branch succeeds in being significantly better.<br>

<br>Dmitry<br><br><div class="gmail_quote">On Wed, May 22, 2013 at 5:15 PM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 5/22/13 3:04 PM, Dicebot wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday, 22 May 2013 at 14:37:10 UTC, John Colvin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
no one cares about reasons for code breakage. For those who care<br>
about breakage, it is a boolean flag - either breaks, or not.<br>
</blockquote>
<br>
This may well be the case, but you're missing the point:<br>
<br>
Breakage is always bad, so we avoid it *unless* the change adds some<br>
significant value to the language.<br>
Fixing a bug (almost) always adds significant value.<br>
Changing command line syntax, in my opinion (and, it would appear,<br>
Walter and Andrei's) does not add significant value.<br>
<br>
Although each individual person who suffers breakage may not care why<br>
it happened, this does not in any way constitute an argument for<br>
allowing less important changes to break stuff.<br>
</blockquote>
<br>
You seem to misunderstand what angers me and Jacob here. It is not the<br>
fact that this specific DIP is rejected (I don't really care), it is the<br>
fact that D developers keep repeating "D goes stable" mantra when it<br>
actually does not. Pretending to prioritize stability and breaking code<br>
even with bug fixes is technically lying. Bad for reputation, bad for<br>
marketing. And good luck using "They have a different understanding of<br>
stability" line in a dialog with enterprise type manager.<br>
<br>
If stability is really a priority - please start doing something real<br>
about it. At least start with defining what "stability" means and what<br>
guarantees D team can give for users. Publish it at <a href="http://dlang.org" target="_blank">dlang.org</a> and it is<br>
at least a start.<br>
<br>
Or stop rejecting stuff using "stability" as smoke screen. This two<br>
options exclude each other.<br>
</blockquote>
<br></div></div>
I don't understand what you're sustaining. We all want D to become more stable. It's not a smoke screen or a pretext to reject improvements.<br>
<br>
My understanding of your reasoning is:<br>
<br>
1. Stability is something binary, if you break some code no matter how much code and on what grounds - if you break it stability is zero. If you don't break any code at all, then stability is one. There is no intermediate state between zero and one.<br>


<br>
2. By definition (1), D is not stable.<br>
<br>
3. Therefore since it's not stable, let's accept whatever changes because they won't make anyone's life worse.<br>
<br>
Is my interpretation correct? If so, do you understand reasonable people may disagree with the reasoning above?<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Andrei<br>
</font></span></blockquote></div><br>