Head Const

[ZombineDev via Digitalmars-d]

On Tuesday, 16 February 2016 at 11:02:38 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 16 February 2016 at 10:17:05 UTC, Jonathan M Davis 
> wrote:
>> version of D. We don't know what we're going to want to do at 
>> that point, and if we're actually willing to break backwards 
>> compatibility in a serious way, what D2 looks like doesn't 
>> really matter much for D3. And we don't even know whether 
>> there will ever be a D3. What matters to us now is what we do 
>> with D2 for making it a good language now and not what we may 
>> or may not do with a future version of the language. Planning 
>> for D3 now would be like planning for D when working on 
>> finishing up C++98.
>
> This is true, in a way, but also a bit too pessimistic.
>
> Here is a possible strategy:
>
> 1. add semantics that are desirable to D2
> 2. express both D2 and D3 in a single intermediate 
> representation
> 3. work on a new D3 syntax that does not support deprecated 
> features
> 4. have two parsers, one for D2 and one for D3
>
> Let compiler vendors decide whether they want to support D2 or 
> not.

A small comment on the way you express most of your opinions:
You have many ideas on how and why D should change, however all 
of your proposals are so vague that no one can figure out any 
concrete action items in them. Furthermore you don't seem to be 
familiar with implementation details and even don't seem to have 
any experience in writting large programs in D, because you never 
talk about concrete problems and never contribute DIPs or PRs 
(which other people serious about using D do). It seems that 
you're not interested in using D for anything at all, which is 
very strange considering how much time you spend on the forums.
Instead of trying critisize other people's concrete plans/ideas 
by saying that instead they should be focusing on something very 
abstract that only you understand, I think it would be a lot more 
beneficial for the D community and your agenda, if you turn your 
words into actions and show **by example** that your 
design/implementation has **objective, measurable** benefits. 
Otherwise no one will find practical real-world benefits from 
your theoretical ideas and we would just waste time arguing with 
each other, while something practical could be accomplished in 
the same time.
Be the change you want to see in the world.

Back to your concrete comment:

It sounds nice in theory, however there are too many refactorings 
in the AST and semantic analysis done for each release, which 
prevents creating a stable intermediate representation.
The only stable IRs are the DMD backend IR, the GCC IR and the 
LLVM IR.
By the way those sementics (maybe) are already representable in 
the current AST abstractions in the frontend. What benefits would 
a dedicated frontend IR bring? Hint: I have already watched the 
LLVM talk about the Swift IR and I'm familiar with the reasons 
for Rust introducing MIR. I just don't see the value such a large 
initiative would bring to D.
The best way to defend your point would be look at the DMD source 
code and propose specific API changes/additions which would bring 
objective benefits. Otherwise you sound like someone telling a 
car manufacturer that they should be focusing on flying cars or 
teleportation, because clearly that's the future :D