On 7/2/2024 9:30 PM, Steven Schveighoffer wrote:
> Well, the article is wrong that having a GC prevents all memory safety problems.
> 
> What causes all the problems (mostly) is the "built-in memory management" of the stack, and critically, returning references to stack data that will outlive the stack frame.

The compiler protects against that. Give it a try!


> Having a GC isn't enough, every single memory allocation scheme must also be safe to have a safe language.

To be memory safe, you'd have to use the GC instead of malloc/free. Using the stack is ok.


> What I would say with D is that it is *much easier* to be memory safe, and the compiler provides tools to help with this.

D does much better than that if one sticks with @safe code and the GC.

On 04/07/2024 1:52 PM, Steven Schveighoffer wrote:
> |ref int bar(ref int x) => x; ref int foo() { int i = 0; return bar(i); } |
> 
> Compiles, even with dip1000.

``-preview=dip1000``

```d
@safe:

ref int bar(ref int x) => x;

ref int foo()
{
    int i = 0;
    return bar(i);
}

void main() {
    int* v = &foo();
}
```

```
<source>(3): Error: returning `x` escapes a reference to parameter `x`
<source>(3):        perhaps annotate the parameter with `return`
```

And when annotated:

```
<source>(8): Error: returning `bar(i)` escapes a reference to local variable `i`
```

On Thursday, 4 July 2024 at 02:00:52 UTC, Richard (Rikki) Andrew Cattermole wrote:
> ``-preview=dip1000``
>
> ```d
> @safe:
>
> ref int bar(ref int x) => x;
>
> ref int foo()
> {
>     int i = 0;
>     return bar(i);
> }
>
> void main() {
>     int* v = &foo();
> }
> ```
>
> ```
> <source>(3): Error: returning `x` escapes a reference to parameter `x`
> <source>(3):        perhaps annotate the parameter with `return`
> ```
>
> And when annotated:
>
> ```
> <source>(8): Error: returning `bar(i)` escapes a reference to local variable `i`
> ```

An unsafe programming language is one that allows to write unsafe code by default. If D is to be more safe, then @safe should be the default and @unsafe optional.

On Thursday, July 4, 2024 10:11:56 AM MDT Lance Bachmeier via Digitalmars-d wrote:
> On Thursday, 4 July 2024 at 07:11:13 UTC, Sebastian Nibisz wrote:
> > An unsafe programming language is one that allows to write unsafe code by default. If D is to be more safe, then @safe should be the default and @unsafe optional.
>
> Safety isn't important to anyone that can't be troubled to write `-preview=dip1000`.

You can write @safe code quite easily as long as you're not doing stuff like taking the address of the stack, and you can verify the safety of that yourself and mark the code as @trusted so long as you're not doing anything crazy with it.

Personally, I won't touch DIP 1000 with a ten foot pole, because it's way too complicated. And using the GC for memory allocations makes it unnecessary in general.

Either way, it's certainly not the case that @safe by default is required for memory safety at all. It might make it easier, because you have to mark less with @safe explicitly, but changing the default doesn't inherently make programs more memory safe. It might help the marketing aspect of things, but from a technical perspective, D is just as memory safe either way. And for those who want the pain, -preview=dip1000 does provide additional checks.

- Jonathan M Davis

On 7/3/2024 6:52 PM, Steven Schveighoffer wrote:
> ```d
> ref int bar(ref int x) => x;
> 
> ref int foo()
> {
>     int i = 0;
>     return bar(i);
> }
> ```
> 
> Compiles, even with dip1000.

```
@safe:  // <=== I added this line

ref int bar(ref int x) => x;

ref int foo()
{
    int i = 0;
    return bar(i);
}
```

fails with:

```
test.d(3): Error: returning `x` escapes a reference to parameter `x`
test.d(3):        perhaps annotate the parameter with `return`
```

when compiled with -preview=dip1000