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/[email protected]?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/[email protected]
"""
-- 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?
