Is it time for D 3.0?

[Steven Schveighoffer]

On 3/28/20 1:09 PM, Denis Feklushkin wrote:
> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>> There have been a lot of this pattern happening:
>>
>> 1. We need to add feature X, to fix problem Y.
>> 2. This will break ALL CODE IN EXISTENCE
>> 3. OK, cancel the fix, we'll just live with it.
>>
>> Having a new branch of the compiler will provide a way to keep D2 
>> development alive while giving a playground to add new mechanisms, fix 
>> long-existing design issues, and provide an opt-in for code breakage.
>>
>> Some issues I can think of:
> 
> I have long wanted to offer but there was no suitable place. I would 
> like to propose to trivial rename standart type names by this way:
> 
> int -> int32
> ulong -> uint64
> float -> float32
> double -> float64
> byte -> octet

I would say no, for 2 reasons. One, this is basically renaming without 
benefit. All those types are well defined, and there is no problem with 
sizing. Two, you can already do this with aliases if this is what you 
wish for.

> Reason:
> 
> Most developers no longer remember where these names came from and why 
> it are so called. In the future this number will close to 100%. And soon 
> we will have access to all sorts of non-standard FPGA implemented CPUs 
> with a different byte size, for example.

Again, alias can already solve this problem. I would recommend for those 
implementations, if D were to support them, that byte not be changed to 
the native byte size, but rather a new type introduced that covers it.

I think D 3.0 doesn't mean "let's break everything", it should be an 
incremental release, but one that is *allowed* to have fixes we have 
been wishing for that break things we cannot break with 2.x.

-Steve