DIP1028 - Rationale for accepting as is

mw mingwu at gmail.com
Mon May 25 18:39:16 UTC 2020


On Monday, 25 May 2020 at 17:31:29 UTC, Paul Backus wrote:
> Even if you did review your code *and* all of your 
> dependencies, if you did it before DIP 1028 was accepted (i.e., 
> any time in the last 10 years or so), you may have deliberately 
> left external @system functions un-annotated, because @system 
> was the default.
>
> In fact, I *know* that people have done this, because I've been 
> running my patched version of the compiler [1] against the dmd, 
> druntime, and phobos codebases, and I have found an enormous 
> number of such un-annotated declarations. Here are just a few 
> of them in druntime:
>
> https://github.com/dlang/druntime/pull/3117
>
> Lots and lots of projects in the D ecosystem are going to need 
> similar patches to be compatible with DIP 1028. And I don't 
> think it's realistic to expect people to make these changes 
> without some kind of help from the tooling.
>
> [1] https://github.com/dlang/dmd/pull/11176


Can we declare the new D compiler version 3.0 for 
@safe-as-default? and keep version 2.x compiler for the old 
@system-as-default?

In industries, it is a big-NO-NO to break exiting *working* code 
base.

I've read some past threads talking about the instability of 
compilers (due to new feature introduced), e.g. in this 
on_leaving_d thread:

https://forum.dlang.org/thread/ncbawciyybdksecurmsc@forum.dlang.org?page=1

https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md

Let me quote what D's *industry users* (whose trademark is on the 
front page of dlang.org) have said 2 years ago:

"""
But when it comes to be boring and predictable, D fails terribly. 
You can't
assume that released features will become 100% usable (no bugs, 
sufficient docs
and tests, well-defined integration with other language features) 
even few
years after initial release. You can't assume that next compiler 
upgrade won't
suddenly break your project or any of its transitive 
dependencies. You can't
assume that any compiler version will be maintained for more than 
few months.
You can't assume there is any control over how declared vision
documents get executed in practice. You
can't trust any promises from language authors because they don't 
keep any track
of those. It is anarchy driven development in all its glory.
"""


I understand the desire of Walter to continue innovation and I 
appreciate it, and I also think this change from @system to 
@safe-as default is an important step for D's future direction, 
as I commented in my thread yesterday:

https://forum.dlang.org/post/brvexgjuqkbebizdmfjj@forum.dlang.org

"""
-- the recent change @safe as default opt-in is good thing: 
without a @nogc phobos, nobody is going to write @system level 
software using D. I think this @safe change means the shift of 
D's focus from system software to application software. And I'm 
glad to see the the template project that dub generate starts 
with "app.d", which is the right direction for D.
"""

But on the other hand, we also need to take care of our existing 
D users, esp industry users, are they going to be happy about 
breaking their working code base with a new compiler version?

For example, we can define a metric: say, how many percent of the 
packages on https://code.dlang.org/ will continue work as-it-is 
*without* to make any change with the new @safe-as-default 
compiler. If > 95% of these packages (the 68–95–99.7 three-sigma 
rule of thumb 
https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule) 
require not any code change, then go ahead, release the new 
@safe-as-default compiler as 2.093.

Otherwise, I'd suggest to keep 2 versions of compiler:

-- version 2.x as stable compiler for (industry) users to use in 
production, and will only provide bug fixes, but no new language 
feature (changes) to the compiler. (And I believe the 2.x version 
D language has already be *feature rich enough* to beat all those 
Java, C#, and Rust for people to use in production software).

-- version 3.x for Walter to experiment and explore new ideas, 
and warn all the users that version 3 is unstable compiler 
feature-wise, use-it-at-your-own-risk, your code base may need 
major change in the future.

Thoughts?



More information about the Digitalmars-d-announce mailing list