DIP 1028---Make @safe the Default---Community Review Round 1

[Gregor Mückl]

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":
>
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>
> 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:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *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.