On 5/12/2025 4:16 AM, Manu wrote:
> `scope` has nothing to do with @safe, and it MUST work in its own right, otherwise the code is lying to the author, and it's an effective liability.

An escape hatch is always needed.

For example, you might want to interface with a 3rd party library that is scope-correct, but is not annotated with `scope`.

On 5/12/2025 5:34 AM, Timon Gehr wrote:
> Even in `@system` code you cannot assign an `int` to an `int*`, you have to use an explicit cast. I don't think it is true that just because `@system` does not give you memory safety guarantees it will therefore be expected that features do not work at all.

@system code is intended to be rare in a properly written D program. Unfortunately, D code is not @safe by default. We are moving to @safe by default, but that requires the editions feature.

Where the line is drawn for what is allowed in @system code is a judgement call, not an obvious thing. Requiring `scope` to be transitive across existing default code would discourage people from using it.

Again, I'll point out all the complaints about @nogc being transitive and thereby making it difficult to use in existing code.

On 5/12/2025 5:41 AM, Richard (Rikki) Andrew Cattermole wrote:
> Right, perhaps if it was a different design, say unsafe blocks I'd agree with what Manu is saying.

Unsafe blocks were not chosen for D because we wanted @system code to be clearly delineated with thought-out interface to them, not just slapped in to shut up compiler complaints about unsafe code.

For a while people would use @trusted lambdas to work like unsafe blocks would. The result of that confirmed that we made the right decision to make the boundary between safe/unsafe code at the function level. One can still use @trusted lambdas, but that use is considered bad practice.

On Monday, 12 May 2025 at 18:40:02 UTC, Walter Bright wrote:
> On 5/12/2025 3:55 AM, Manu wrote:
>> So, if it only works with @safe, I repeat again; WHY?
>
> So you can break the rules in @system code.
>
> We are trying to move towards @safe by default, but the new editions feature is needed first.

Wasn't Manu's whole point that scope only really works in @safe code and you disagreed and said it didn't depend on that?

On Monday, 12 May 2025 at 16:11:18 UTC, Paul Backus wrote:
> On Monday, 12 May 2025 at 13:45:04 UTC, jmh530 wrote:
>> But I think "what people want" and "what's the goal here" are two different kinds of questions. What people want is more powerful safety analysis. But the reason why Walter started working on this was that he saw safety as becoming a bigger issue in programming languages, most notably with Rust gaining traction, and wanted to help D compete on that basis.
>
> Here, you say that the goal of @live is to compete with Rust on safety.
>
>> So I think one thing that has Walter frustrated is that he wants to be able to say D has a borrow checker when someone asks, but the actual users don't want something unless it actually enables the more powerful safety analysis.
>
> Here, you say that the goal of @live is "to be able to say D has a borrow checker."
>
> The problem is that these are not the same goal. Walter's work on @live has (arguably) succeeded in advancing goal #2, but it has done nothing to advance goal #1.
>


In my view, competing with Rust and being able to say that D has a borrow checker are the same thing. My point was that what people really want is more powerful safety analysis. Sorry if that was confusing.

On 5/12/2025 6:25 AM, Dennis wrote:
> Finally, mechanical scope checking has false positives:
> ```D
> void f(ref scope S ctx)
> {
>      const old = ctx;
>      g(ctx);
>      ctx = old; // Error: scope variable `old` assigned to `ref` variable `ctx` with longer lifetime
> 
> }
> ```

This comes about because `old`, being declared after `ctx`, has a shorter lifetime than `ctx`. If `old` has a destructor, that destructor will run before `ctx`s destructor, and `ctx` will be referring to an invalid instance of `old`.

If S does not have a destructor, does that make the error a false positive or not? I decided that the existence of a destructor should not change the scoping rules. The increase in language complexity is not worth it, as such to often leads to unexpected, quirky side effects.

BTW, thank you for your post. It's informative and excellent.

On Monday, 12 May 2025 at 19:15:56 UTC, jmh530 wrote:
> In my view, competing with Rust and being able to say that D has a borrow checker are the same thing. My point was that what people really want is more powerful safety analysis. Sorry if that was confusing.

It's not confusing, it's just incorrect. I understand your view perfectly, and I disagree with it.

On 5/12/2025 12:12 PM, jmh530 wrote:
> Wasn't Manu's whole point that scope only really works in @safe code and you disagreed and said it didn't depend on that?

D is complicated. Sometimes I make mistakes.

It never made it into the C++ Standard, and its only use is CLI.