On 11/10/2013 08:45 PM, John Colvin wrote:
On Sunday, 10 November 2013 at 19:24:53 UTC, Andrei Alexandrescu wrote:
On 11/10/13 11:14 AM, Timon Gehr wrote:
On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
On 11/9/13 1:27 AM, SomeDude wrote:
I would add that constant breaking changes make the language unfit for
industrial usage in the long term.
Let's remember that D is being pushed in production by Andrei at
Facebook. If the language breaks everything at each release, there
is no
way Facebook or any other company for that matter is going to bet a
dime
on it.
Agreed with qualifications. We at Facebook are well aware that bumping
the gcc release will inevitably cause breakages, and are able and
willing to put up with them for the sake of the benefits. This of
course
is guided by the breakage/benefits ratio.
Andrei
What about just shipping a fully automated fix-up tool when trivial but
major breaking changes happen?
That's nice because in a good way it puts the onus on the breakers.
For it to be useful, the tool would have to be rock solid and work in
100% cases.
Andrei
string mixins?
Just let CTFE thread through additional state describing the locations
of the constant literals the code is assembled from, and make sure the
fix-ups do not influence anything else. For the off chance that some
part of the generated code that we want to change is actually computed
from other data, it is still possible to require manual interaction, but
I don't know of any real code for which this might be the case.
Code relying on stringof, eg. stringof returning '@safe' in types
instead of 'safe' would be quite hard to handle as well, but it should
still be possible to handle the relevant subset of cases.
Of course, such a tool would be quite a piece of engineering. :o)
