On Saturday, 4 January 2020 at 16:16:30 UTC, Arine wrote:
> On Friday, 3 January 2020 at 22:59:53 UTC, Walter Bright wrote:
>>> This is going to be a big breaking change, and if you are going to do the same thing with `nothrow`, that's way too much breakage for very little benefit just to follow a trend.
>>
>> There are compelling reasons for nothrow by default. I suggest deferring this discussion until the DIP is put forward for review.
>
> An expression comes to mind, "death by a thousand cuts". If you are only going to look at each DIP on it's own, without also taking into consideration other DIPs, then you aren't going to realize just how much breakage the accumulation of all the DIPs is actually causing. There's been a lot of DIPs that cause a bunch of breaking changes recently. They are all small, but it's all starting to add up. And the breakage is starting to outweigh the benefits that they bring. To me personally for my projects, they don't really bring any benefit, but they still break my code.

We need to have a separate discussion about the strategy for breaking changes. We might even agree with the change but the change has an impact on the current codebase that wants to us to disagree with the change.

Walter have hinted several ideas about changing the D syntax, several of the that I agree with but just changing the current compiler causes problems. In the pipeline are changes like "nothrow" by default, "final" by default which is like to see but perhaps it is time to start working on D3 and leave the current compiler in maintenance mode. By doing this we can speed up the development of the "new D" instead of being held back by compatibility worries.

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.

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":

I expected this to take at least another year or two. I am very glad it is happening now.

Because of dip1000 I have been using @safe for a while and having it be the default is the only thing that makes sense. Mainly because of the fact that of all d code out there, only a small part is @system (and it should decline relatively going forward), which means that annotating the system parts is easier than annotating the safe parts. Especially when you have the compiler complain something isn't @safe versus pretending everything is @system.

To abuse a Chinese proverb: the best time for @safe as default was 20 years ago, the second best time is now.

With the preview and revert flags there is plenty time to develop tools to automate the transition, as others have mentioned here as well.

On Saturday, 4 January 2020 at 19:27:25 UTC, Sebastiaan Koppe wrote:
> 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":
>
> I expected this to take at least another year or two. I am very glad it is happening now.
>
> Because of dip1000 I have been using @safe for a while and having it be the default is the only thing that makes sense. Mainly because of the fact that of all d code out there, only a small part is @system (and it should decline relatively going forward), which means that annotating the system parts is easier than annotating the safe parts. Especially when you have the compiler complain something isn't @safe versus pretending everything is @system.

To use an argument that is being used against why this shouldn't happen. You can just do:

@safe:

Its nice and easy and does what you want, then you can annotate everything else that needs to with @system.

On Saturday, 4 January 2020 at 19:37:43 UTC, jxel wrote:
> To use an argument that is being used against why this shouldn't happen. You can just do:
>
> @safe:
>
> Its nice and easy and does what you want, then you can annotate everything else that needs to with @system.

That makes no sense to me. Instead of sane defaults I am expected to prepend every file with some customary intro? And even if I do that, probably no dependency I use does. Just like hardly any dub package is bothered to do @safe right now.

Besides, it doesn't work for everything, I have tried.

On Saturday, 4 January 2020 at 20:19:09 UTC, Sebastiaan Koppe wrote:
> Besides, it doesn't work for everything, I have tried.

This should be fixed regardless of defaults. We'll want it either way.

On 1/4/2020 2:22 AM, WebFreak001 wrote:
> Currently a lot of issues are caused by phobos' std.bitmanip.bitfields.

Please add all issues to Bugzilla.

On 1/4/2020 2:22 AM, WebFreak001 wrote:
> I have done this for all dub packages now so everyone can review what this change actually does to their packages:
> 
> https://i.webfreak.org/safe-test/index.html

This is good work. Thanks!

On 1/4/2020 2:42 AM, Atila Neves wrote:
> Most D code is @safe. Nearly all of it is. Unless you're taking addresses of locals (which can be made @safe by using DIP1000 and scope),

When passing the address of a local to a function, nearly all of that can be easily and safely fixed by changing the function parameter from `T*` to `ref T`.

On 1/4/2020 2:42 AM, Atila Neves wrote:
> most code is @safe anyway

And most of the rest can be trivially made @safe.

Which brings up something interesting:

With @safe as the default, far fewer annotations will be needed for functions! Since nobody likes annotations, including me, this is good.