Breaking changes in Visual C++ 2015

[via Digitalmars-d]

On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:
> https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx
>
> I'm sharing this specifically so we can have an unproductive 
> flamewar about whether breaking changes in D are sometimes 
> worth it or if they are holding D back from mass adoption :).

How about a productive design oriented working group instead of a 
flame war?

I totally side with Walter when he says that drip-drip-drip 
changes are taxing on people who does not work full time with a 
language, but have serious intents with being involved.

I also totally understand his fear of alienating the existing 
user base by changing the language in ways that makes the 
existing user base change their personal programming idioms 
(whether they are sound and clean or the opposite).

However, rhe transition to D for DMD provides:

- Opportunity to rethink compiler internals.

- Opportunity to refactor the compiler so that you can get better 
tooling/automatic transcompiling from D2 to a hypthetical D3 if 
need be.

And therefore also an opportunity to rethink the language 
semantics.

If you want to rethink language semantics you should start with 
tabula rasa (assume no existing langauge). Then come up with the 
hypothetical ideal high level design for the kind of programming 
D is meant for. When you have that, you have much better chance 
to redesign the existing language with an upgrade path to 
something consistent.

Semantic drip-drip-drip metamorphosis is generally not very good 
for an axiomatic system (which programming language internals 
have to be).

If it was up to me I'd focus on 5 areas:

- stronger typing / behavioural typing

- memory model

- see if it is possible to redesign and implement the templating 
system with something that is close to Datalog to get  more 
streamlined metaprogramming

- high level IR for whole program optimization with partial 
evaluation

- identifying a sub langauge that can be used for building a 
small SIMD oriented backend for innnerloops (generating different 
variants SSE2/SSE3/AVX/AVX2 based on cpu info).