On Monday, 13 January 2020 at 15:57:38 UTC, Joseph Rushton Wakeling wrote:
> Clearly yes: @safe-by-default fits within an observable trend of languages getting more and more concerned with provable memory safety, and with a related trend of requiring the user to write provably safe code.  Rust in particular has significantly raised the bar in this space, and proven that such constraints are often welcomed by developers.

Rust doesn't just provide safety. It also provides a lot more other guarantees than just safety. It is low level and achieves memory safety *without* a GC. It provides guarantees for multi threading, that reduces data races and other difficult to diagnose problems. This is a world where single thread performance isn't getting significantly faster. But we are now getting CPUs with 64 cores and 128 threads.

You can't just look at one aspect for Rust, without looking at every aspect. Java provides memory safety, but there's a reason why people using Rust don't use Java.


> As a separate issue, it's probably a good idea to take discussion of keyword choices off the table for the purposes of this DIP.  @safe, @trusted and @system have well-defined meanings which are entirely compatible with the transition to @safe-by-default.  We should keep our focus on the stuff that needs to change, not the stuff that doesn't.

It's not just keyword choices. It's fundamentally how discover-able @unsafe code is while reading @safe code. This DIP is a big breaking change that is going to break basically all code out there. All documentation, all discussions, all example code, ~everything~. This is probably the only time to discuss something like this. It wouldn't make sense to accept this DIP, then have another DIP that causes a similar amount of breakage regarding a similar aspect of the language.

> In short: since nothing stops anyone who cares from having a `@safe` codebase right now through the existing opt-in features, show us in detail how the pain of transitioning to opt-out is really worth it ;-)

I agree with this. People that want to write @safe code write @safe code. Those that don't want to, don't. Making safe by default won't make people write @safe code that is actually safe, it'll just make them misuse @trusted more.

On 1/13/20 12:13 PM, Arine wrote:
> This DIP is a big breaking change that is going to break basically all code out there

Can someone explain this point of view to me? It seems extreme.

I've also seen a lot of assertions that all documentation and tutorials (ALL) will be broken.

-Steve

On Monday, 13 January 2020 at 17:13:36 UTC, Arine wrote:
> Rust doesn't just provide safety. It also provides a lot more other guarantees than just safety. It is low level and achieves memory safety *without* a GC. It provides guarantees for multi threading, that reduces data races and other difficult to diagnose problems. This is a world where single thread performance isn't getting significantly faster. But we are now getting CPUs with 64 cores and 128 threads.

Yes, indeed.  That's kind of the point -- Rust has established a set of viable techniques for proving memory safety in a systems programming context.  That in turn establishes that there is lot of scope for D to improve its memory-safety guarantees (in particular, being able to prove memory safety criteria in GC-free code).

D has been learning and adapting from that -- and can continue to do so.  But in terms of considering the basic viability of this DIP, the important point of consideration is whether it is desirable to have provable memory safety by default in a systems programming language.  Rust gives us a clear example that it can be both desirable and achievable.  The move to ever-more-parallel development gives us the extra motivation for why this will matter more and more in future.

All the other stuff comes down to implementation details.  The question is which of those implementation details matter when it comes to making @safe-by-default viable in practice, and whether that is achievable with minimal transition problems.

Note that all this is saying is that it is valid to make the proposal.  It doesn't say that the proposal should be accepted (either on principled or on practical grounds).  You may notice plenty of practical critique in the feedback I offered.

> You can't just look at one aspect for Rust, without looking at every aspect. Java provides memory safety, but there's a reason why people using Rust don't use Java.

Genuine question, as I'm not a Java dev: does Java genuinely provide _provable_ memory safety?  Or is it just that in practice things will be memory safe because of the GC, and it doesn't allow you access to features that escape that safety blanket?

> It's not just keyword choices. It's fundamentally how discover-able @unsafe code is while reading @safe code.

Isn't that the same as it's ever been -- search for @trusted blocks?  I don't see how that would change.

On Monday, 13 January 2020 at 17:33:12 UTC, Steven Schveighoffer wrote:
> On 1/13/20 12:13 PM, Arine wrote:
>> This DIP is a big breaking change that is going to break basically all code out there
>
> Can someone explain this point of view to me? It seems extreme.
>
> I've also seen a lot of assertions that all documentation and tutorials (ALL) will be broken.

Yea.  This is something where both sides of the argument are better off avoiding rhetoric and providing clear empirical evidence.

Obviously the onus is more strongly on the DIP proponents, but it's not helpful for anyone to offer unsubstantiated opinion rather than facts.

Without demonstrable facts on hand, perhaps it's better to provide feedback on what facts need to be obtained rather than just unsubstantiated opinion?

On Monday, 13 January 2020 at 17:33:12 UTC, Steven Schveighoffer wrote:

> I've also seen a lot of assertions that all documentation and tutorials (ALL) will be broken.

That was probably me. I don't recall ever saying all documentation and tutorials will be broken, but it will certainly cause problems for a lot of the material out in the wild, and it's the kind of breakage that will make folks run away. It's not just what's written in the documentation/tutorial either. You change one thing in a working example and all of a sudden it no longer compiles. Seriously, who changes to @safe by default in a regular release?

Ultimately it's up to the DIP author to make the case that this type of breakage won't happen. The author of this DIP did not do that, and anyone else making such a proposal would have it shot down immediately for exactly that reason.

On 1/13/20 1:38 PM, bachmeier wrote:
> On Monday, 13 January 2020 at 17:33:12 UTC, Steven Schveighoffer wrote:
> 
>> I've also seen a lot of assertions that all documentation and tutorials (ALL) will be broken.
> 
> That was probably me. I don't recall ever saying all documentation and tutorials will be broken, but it will certainly cause problems for a lot of the material out in the wild, and it's the kind of breakage that will make folks run away. It's not just what's written in the documentation/tutorial either. You change one thing in a working example and all of a sudden it no longer compiles. Seriously, who changes to @safe by default in a regular release?

I feel this is a bit blown out of proportion.

I see all the time on stackoverflow answers updated for e.g. newer versions of Swift. There's no reason to think the same thing wouldn't happen for D.

But I also think it's going to be a very small part of the tutorials/docs that are incorrect. Looking at tour.dlang.org, I see the following pages that won't work with the DIP defaults:

https://tour.dlang.org/tour/en/basics/memory (basically talks about safe D anyway, so it would need an update for sure)
https://tour.dlang.org/tour/en/basics/type-qualifiers (runs fine with dip1000, so maybe we need to look at the order in which we turn on the various DIP defaults)
https://tour.dlang.org/tour/en/basics/associative-arrays (object.keys is not safe, this would need to be fixed before implementation of the DIP)
https://tour.dlang.org/tour/en/basics/exceptions (writeln(e.info) has issues with safety, that might not be a problem with the real DIP)

> 
> Ultimately it's up to the DIP author to make the case that this type of breakage won't happen. The author of this DIP did not do that, and anyone else making such a proposal would have it shot down immediately for exactly that reason.

You will have lots of time to get your code ready for the DIP to be the default.

-Steve

On 1/2/20 4:47 AM, 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.

How does the DIP affect interfaces and class virtual functions? Especially interfaces without marking will be a potential problem as there will be no errors on a @system interface stub which now is tagged with @safe but has no implementation to complain about. But an implementing class would fail to compile potentially (and might be in a separate project). This is a fundamental API difference that's not easy to account for. The DIP should address that process.

I noticed that even templated class member functions are currently @system unless tagged @safe (for good reason). So there's going to be a lot of code out there like this.

-Steve

On Monday, 13 January 2020 at 20:32:32 UTC, Steven Schveighoffer wrote:
> On 1/13/20 1:38 PM, bachmeier wrote:
>> On Monday, 13 January 2020 at 17:33:12 UTC, Steven Schveighoffer wrote:
>> 
>>> I've also seen a lot of assertions that all documentation and tutorials (ALL) will be broken.
>> 
>> That was probably me. I don't recall ever saying all documentation and tutorials will be broken, but it will certainly cause problems for a lot of the material out in the wild, and it's the kind of breakage that will make folks run away. It's not just what's written in the documentation/tutorial either. You change one thing in a working example and all of a sudden it no longer compiles. Seriously, who changes to @safe by default in a regular release?
>
> I feel this is a bit blown out of proportion.
>
> I see all the time on stackoverflow answers updated for e.g. newer versions of Swift. There's no reason to think the same thing wouldn't happen for D.
>
> But I also think it's going to be a very small part of the tutorials/docs that are incorrect. Looking at tour.dlang.org, I see the following pages that won't work with the DIP defaults:

If you only work with idiomatic D code, this DIP won't have much of an impact. If you're like me, and almost everything you've ever done with D has taken advantage of D's interoperability with C (one of its big selling points), it's a serious PITA, and every bit of documentation, tutorial, and blog post you've ever written for others will break. All of a sudden you have to tell others to litter their code with ugly @trusted or @system. All of this because adding a -safe switch isn't sufficient for those that want safe by default.

On Monday, 13 January 2020 at 21:43:24 UTC, bachmeier wrote:
> All of this because adding a -safe switch isn't sufficient for those that want safe by default.

Or better yet, let's make `@safe:` work well so we can do this on a per-module level. See:

http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_13.html#my-attribute-proposal---no-changes-to-defaults

On 14/01/2020 10:46 AM, Adam D. Ruppe wrote:
> On Monday, 13 January 2020 at 21:43:24 UTC, bachmeier wrote:
>> All of this because adding a -safe switch isn't sufficient for those that want safe by default.
> 
> Or better yet, let's make `@safe:` work well so we can do this on a per-module level. See:
> 
> http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_13.html#my-attribute-proposal---no-changes-to-defaults 
> 

I'm not sure I like the idea that attributes are going down scopes like you have suggested. It should be explicit that you want that.

Otherwise I'm on board.