On 07/18/2016 03:37 PM, Walter Bright via Digitalmars-d wrote:
On 7/18/2016 6:48 AM, Andrew Godfrey wrote:
We risk scaring away potential community members, and alienating
existing ones,
by the way we say "no" to proposals for breaking changes. We could
improve how
we say "no", by having a place to point people to. Potential topics:
Anything we do will risk scaring away people. The only answer is we
have to do what is right.
3) Why we feel that breaking changes risk killing D outright. (I just
don't see
it. I wonder if we're confusing "dfixable" breaking changes, with
other more
disruptive kinds (such as Tango=>Phobos).)
Because if you thoroughly break a person's code, you put them in a
position of rewriting it, and they may not choose to rewrite it in D3.
They may choose a more stable language.
I have many older programs in different languages. It's nice if they
recompile and work. It's not nice if I have to go figure out how they
work again so I can get them to work again.
For some changes there could be switches, rather like optimization level
switches, or those managed by version. This would allow the compilation
version to be set based on a compile time variable, I'm not totally
sure whether this should be file level or, as with version, block
level...or selectable. This would get to be a huge maintenance chore
after awhile, but it would allow you a few years to deprecate code.
The question is "How important would a change need to be to justify this
kind of action?", and my guess is that it would need to be pretty important.
