On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
> https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
>
> Lists some perfectly reasonable code in Modern C++ style that has hidden memory safety bugs.

Not at all reasonable to take a borrowing reference from a temporary... string_view is not owning.

C++ does not use the compiler to check for memory safety issues. Ownership in C++ is a library concept, not a language concept.

C++ is more geared towards using linters for such things. Or rather, that is what is being suggested by providing annotations for owning/non-wning references.

On Monday, 26 April 2021 at 12:05:48 UTC, Calvin P wrote:
> On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
>> https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
>>
>> Lists some perfectly reasonable code in Modern C++ style that has hidden memory safety bugs.
>
> Rust used for kernel/browser/database/UI, D also king able to work but not work good(no product or big projects).
>
>
> Rust replace c++ jobs, go replace java jobs.  D need better long-term strategy.

it is sad but such message is put with regularity years after years.
It is fun to see the rust born by reading old message in this forum.

About the long-term strategy, to my understanding they works on D language and expect that someone will do the killer application «à la» ruby on rails or python datascience or java hadoop.

But the problem is still here, years after years.

Maybe a day …

On Monday, 26 April 2021 at 12:05:48 UTC, Calvin P wrote:
> On Monday, 26 April 2021 at 01:28:35 UTC, Walter Bright wrote:
>> https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
>>
>> Lists some perfectly reasonable code in Modern C++ style that has hidden memory safety bugs.
>
> Rust used for kernel/browser/database/UI, D also king able to work but not work good(no product or big projects).
>
>
> Rust replace c++ jobs, go replace java jobs.  D need better long-term strategy.

For me, D replace Python for data crutching.

On 4/27/2021 4:33 AM, MoonlightSentinel wrote:
> On Tuesday, 27 April 2021 at 10:53:10 UTC, Vladimir Panteleev wrote:
>> What does `scope` mean on a function declaration?
> 
> It applies to the `this` pointer for member methods, just like `return`.
> (Allthough `scope` is implicitly applied for structs IIRC)

This isn't quite right. For structs,

    struct S {
        int* ptr;
        int* hello() scope;
	static int* betty(scope ref S s);
    }

The `this` reference is passed by `ref`. So, `hello` is exactly equivalent to `betty`.

The `ref` already prevents returning the address of a struct. The `scope` prevents the return of `s.ptr` and equivalently `this.ptr`.

This is likely why, in the bug report, the `ptr` field was necessary.

As always, when confused about this, rewrite the code in terms of simple ref's and pointers.

On Tuesday, 27 April 2021 at 23:38:14 UTC, Walter Bright wrote:
>
> As always, when confused about this, rewrite the code in terms of simple ref's and pointers.

I think a large part of the confusion here stems from the fact that `scope ref T` behaves very differently from `scope T*`, even though `ref T` and `T*` are the same "under the hood."

    @safe:
    static int* betty(scope ref S s) { return s.ptr; } // Error
    static int* veronica(scope S* s) { return s.ptr; } // Ok

Unfortunately, there is no documentation of this distinction in the language spec (or anywhere else, as far as I know), so the only way anyone can learn about it is through trial and error.