DIP 1028---Make @safe the Default---Community Review Round 1
gregormueckl at gmx.de
Sat Jan 4 18:51:32 UTC 2020
On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community
> Review for DIP 1028, "Make @safe the Default":
> All review-related feedback on and discussion of the DIP should
> occur in this thread. The review period will end at 11:59 PM ET
> on January 16, or when I make a post declaring it complete.
> At the end of Round 1, if further review is deemed necessary,
> the DIP will be scheduled for another round of Community
> Review. Otherwise, it will be queued for the Final Review and
> Formal Assessment.
> Anyone intending to post feedback in this thread is expected to
> be familiar with the reviewer guidelines:
> *Please stay on topic!*
> Thanks in advance to all who participate.
My concern is about forcing such a transition onto the D
ecosystem at all. Making this change the default in the D
compiler will create a split in the ecosystem. I don't really
know a single programming language ecosystem of notable size that
went smoothly through a transition that altered the syntax and/or
semantics of previously written code. If someone could name a
positive example, I'd be grateful.
The obvious counterexample here is the Python 2 to Python 3
transition. Python 3.0 was released in December 2008 and we're at
the end of the decade long deprecation period of Python 2.
There's still a lot of software that hasn't made the transition.
Most of the changes were small, but they required people to touch
existing code. Even automated tools like 2to3 didn't make a lot
of impact. I'm running a variant of Arch Linux here, that made
Python 3 the default fairly early. Just running a "grep python2
/usr/bin/*" still finds a couple of scripts that need Python 2.
D already had a schism in the past with Tango vs. Phobos in the D
1.0 days. It held the development of the ecosystem back. D 2.0
has matured in recent years and it has enjoyed a period of
relative stability that I believe increased its appeal. Any
language change that forces large scale alteration of existing
code a will undermine all this again. This may put the language
on the sidelines as a "toy", "research" or "unstable" language in
the perception of many.
Walter admits that this drive to create a type safe version of D
is marketing driven. The assertion is that languages need to have
this property to be successful in the future. Is that reward
worth the risk of alienating existing users?
I would propose a more gradual transition, if that is feasibly in
any way. A rough sketch might be:
- Phase 1: Introduce module level pragmas that enable
safe-by-default or alternatively perhaps an explicit opt out at
module level. Recommend that modules start with this declaration,
but don't enforce it.
- Phase 2: When enough modules in dub packages contain these
pragmas, enable a compiler warning if the compiler sees a module
without such a pragma.
- Phase 3: If sufficent packages in dub have been annotated
accordingly (say, >90% in dub), the global switch can be thrown.
This plan would put an effort on educating and convincing the
community to make the change. Progression should be milestone
based, not deadline based. It is important to send the message
that the change is being made gradually and carefully.
Even with this gradual transition, D can still claim to be a safe
language. Projects that want to be safe by default can easily
check that all modules have the corresponding pragma at the top.
That's not worse than other static checks that are performed on
source code in CI/CD environments.
More information about the Digitalmars-d