On Tuesday, 14 January 2020 at 01:03:37 UTC, rikki cattermole wrote:
> 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.

In as much as like a "@safe class" (or struct/interface/etc) makes sense, it would surely make the most sense that a @safe class is one where all methods are @safe. Ditto on nothrow and pure.

So the descending into scopes is a consequence of that.

Though you could argue that a @nogc class is a class that cannot live on the GC heap instead... (i was so happy with @disable operator new until that got deprecated). But still, the same idea can apply there too. We just need to define it as such.

But that's the formal reason why these specific attributes would descend into scopes.

On Monday, 13 January 2020 at 17:34:48 UTC, Joseph Rushton Wakeling wrote:
> 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).

That's the thing, D has a GC. If you are now trying to push Rust-like features into @safe to allow @safe non-gc memory, you are going to be adding restricting code that would otherwise not have to be to be @safe with a GC. So the language becomes more restrictive like Rust, all while losing the benefit of having a GC and not needing to worry about those restrictions. The DIP that tried to disable dynamic array resizing is proof of that.

>> 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?

Depends what you mean by provable. If you mean using potentially unsafe features and the compiler being able to prove they are being used safely, no I don't think any compiler does that. If you mean it's provable to be safe because it doesn't allow unsafe features like basically what D does, then yes. It'd be more safe than D in that regard as it simply doesn't allow pointers. If you also take into consideration, in it's current state, D isn't provable to be safe as it has features that a provably *unsafe*. At least one person here even thought you couldn't use the feature in @safe code (see: void initializers).

>> 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.

If your in a @safe function trying to figure out where unsafe calls are, how would you search for @trusted? The function you are searching for could be in one of the thousands of different files. Are you going to go look at each and every one? There's an example a few pages back that illustrates this.

On Monday, 13 January 2020 at 20:37:33 UTC, Steven Schveighoffer wrote:
> 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 agree and I think my request for a depreciation plan would request that unspecified interface methods be deprecated.

https://forum.dlang.org/post/bojmstnsnfydfaggslzj@forum.dlang.org

On Tuesday, 14 January 2020 at 06:12:35 UTC, Jesse Phillips wrote:
> I agree and I think my request for a depreciation plan would request that unspecified interface methods be deprecated.
>
> https://forum.dlang.org/post/bojmstnsnfydfaggslzj@forum.dlang.org

I don't think deprecating would be a good idea since it make more attributes mandatory which isn't helpful for quick scripts and disrupts existing builds using -de.

Another approach could be to highlight problematic functions (which are really @system but not annotated as such). Hence I implemented -transition=safe to list these functions as a less intrusive message, see https://github.com/dlang/dmd/pull/10715

On Monday, 13 January 2020 at 21:46:46 UTC, Adam D. Ruppe wrote:
> [snip]
>
> 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 like this approach. Looks like DIP 1029 is moving in that direction.

On Tuesday, 14 January 2020 at 10:21:21 UTC, MoonlightSentinel wrote:
> On Tuesday, 14 January 2020 at 06:12:35 UTC, Jesse Phillips wrote:
>> I agree and I think my request for a depreciation plan would request that unspecified interface methods be deprecated.
>>
>> https://forum.dlang.org/post/bojmstnsnfydfaggslzj@forum.dlang.org
>
> I don't think deprecating would be a good idea since it make more attributes mandatory which isn't helpful for quick scripts and disrupts existing builds using -de.
>
> Another approach could be to highlight problematic functions (which are really @system but not annotated as such). Hence I implemented -transition=safe to list these functions as a less intrusive message, see https://github.com/dlang/dmd/pull/10715

For interfaces I could understand, the depreciation I suggested for regular methods would mandate only needed attributes but it also requires a different compiler logic. Your solution may effectively be the same.

I think a depreciation is important to guide the transition and shouldn't be done right away but as one of the release steps. Those using de are looking to nudge themselves on the release plan.

On Tuesday, 14 January 2020 at 05:23:10 UTC, Arine wrote:
> That's the thing, D has a GC. If you are now trying to push Rust-like features into @safe to allow @safe non-gc memory, you are going to be adding restricting code that would otherwise not have to be to be @safe with a GC. So the language becomes more restrictive like Rust, all while losing the benefit of having a GC and not needing to worry about those restrictions. The DIP that tried to disable dynamic array resizing is proof of that.

It's not about what _I'm_ doing.  There are already DIPs and experimental features that extend the reach of what @safe can verify, allowing validation of memory safety for various GC-free (or rather, GC-agnostic) scenarios.

That doesn't impose Rust-style restrictions on anyone who doesn't want them -- you can GC away to your heart's content -- but it makes it more possible for people who want to work _without_ the GC to validate the memory safety of their programs.

And that provides a context where @safe-by-default might start to look less intrusive.

BTW, note that Rust, having dropped built-in GC early on in its design, is now looking at ways to support it as a developer opt-in: https://docs.rs/gc/0.3.3/gc/

So, these things are not either-or.  Whether a developer wants to use GC or not (or a hybrid of GC- and non-GC-backed memory allocation), there's a common interest in being able to validate at compile time that the overall result is memory safe.

>>> 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.
>
> If your in a @safe function trying to figure out where unsafe calls are, how would you search for @trusted? The function you are searching for could be in one of the thousands of different files. Are you going to go look at each and every one? There's an example a few pages back that illustrates this.

I'm sorry, but I can't find the example you are referring to.  Can you provide a link to the post?

As for the rest of your remarks: I understand (and sympathize) with the wish for better ways to track down those parts of a codebase that need manual validation.  But that problem is the same problem whether we have @safe as an opt-in or as the default.

From what you've written elsewhere, do I understand correctly that what you're arguing for is an alternative way of marking those pieces of code, and that you believe this would make it easier to search out those problematic parts of a codebase?

On that note I disagree with your earlier remark:

> If we are going to make @safe the default we don't really need
> @safe keyword, or @system or @trusted. It's make sense to get
> rid of all 3 of them and just add @unsafe. If you are going to
> do it, might as well do it right the first time.

I agree that @trusted can be abused, but limiting us to just @unsafe (à la Rust) seems to me to be unacceptable.

One of the horrible things about Rust is that you can put an `unsafe { ... }` block around any single arbitrary line inside a function, and the compiler stops complaining -- despite the fact that the validity of that unsafe call may be contingent on stuff in the other lines of the function.  And yet the function signature offers no clue to the user that there might be anything risky going on underneath.

@trusted allows us to clearly annotate those function signatures such that the user is always clear which functions are in need of overall validation.

FWIW I agree with Steven Schveighoffer that it would be useful to update the behaviour of @trusted such that the developer must mark up the explicitly unsafe lines: https://forum.dlang.org/post/qv7t8b$2h2t$1@digitalmars.com

However, I'm not sure that this needs to be coupled with the current DIP.  It's a complementary and helpful change to a @safe-by-default switchover, but not a _necessary_ one.

On 14.01.20 15:56, Joseph Rushton Wakeling wrote:
> On Tuesday, 14 January 2020 at 05:23:10 UTC, Arine wrote:
>> That's the thing, D has a GC. If you are now trying to push Rust-like features into @safe to allow @safe non-gc memory, you are going to be adding restricting code that would otherwise not have to be to be @safe with a GC. So the language becomes more restrictive like Rust, all while losing the benefit of having a GC and not needing to worry about those restrictions. The DIP that tried to disable dynamic array resizing is proof of that.
> 
> It's not about what _I'm_ doing.  There are already DIPs and experimental features that extend the reach of what @safe can verify, allowing validation of memory safety for various GC-free (or rather, GC-agnostic) scenarios.

Which features and DIPs are those?

On 13.01.20 22:46, 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 
> 

It does not mention nested functions and auto return functions. They should be treated like template functions (as they also have attributes inferred by default).

On Wednesday, 15 January 2020 at 02:08:18 UTC, Timon Gehr wrote:
>> It's not about what _I'm_ doing.  There are already DIPs and experimental features that extend the reach of what @safe can verify, allowing validation of memory safety for various GC-free (or rather, GC-agnostic) scenarios.
>
> Which features and DIPs are those?

DIP1000 for example.  (Yes, I know that this didn't formally get accepted but stuff has moved forward derived from this.)

Obviously this is not as comprehensive as e.g. Rust's borrow checker, but the direction of travel here seems pretty clear.