https://www.youtube.com/watch?v=lkgszkPnV8g

This is a great talk. In my first pass, D doesn't suffer from any of them.

Anyone want to verify?

On 7/11/24 22:36, Walter Bright wrote:
> https://www.youtube.com/watch?v=lkgszkPnV8g
> 
> This is a great talk. In my first pass, D doesn't suffer from any of them.
> 
> Anyone want to verify?

Well, the situation in D is overall much better, but I wouldn't say it does not suffer from any of them.


- std::vector::operator[]:
  D code still suffers from unrecoverable range errors that would crash the website, it's just not a memory safety issue unless you pass badly designed compiler flags like `-release`.


- std::map::operator[]:
  Not a problem in D.


- get_default():
  Potential for lifetime error fixed with DIP1000.
  Still potentially a performance problem in D without DIP1040.


- volatile:
  Not clear, but I guess `volatile` is less popular nowadays.
  https://dlang.org/phobos/core_volatile.html
  D also does not have a full `shared` story so far.


- shared_ptr thread-safe:
  Potentially fixed because D has transitive `shared`. But again, `shared` is unfinished. Or use GC.


- shared_ptr bonus bug:
  Simple pattern like the one on the slide seem superficially fixable with DIP1000, but in general in D it is not possible to make smart pointer dereferencing safe. Can use GC though.


- lock bug:
  That syntax would not lock until the end of the scope in D either, but for different reasons. But there is no reason to expect it would work, so I guess we can consider this fixed in D.


I guess the lessons are:

- D also does not have static typing to rule out range errors.
- D also does not have memory safety for general allocator-backed container types.
- remove `-release`
- implement DIP1040.
- finalize `shared`.

On Thursday, 11 July 2024 at 20:36:35 UTC, Walter Bright wrote:
> https://www.youtube.com/watch?v=lkgszkPnV8g
>
> This is a great talk. In my first pass, D doesn't suffer from any of them.
>
> Anyone want to verify?

d is buggy and there are several things I believe cant be fixed without a major rewrites; it wont be any good to pretend otherwise

On 7/11/2024 3:39 PM, Timon Gehr wrote:
> - std::vector::operator[]:
>    D code still suffers from unrecoverable range errors that would crash the website, it's just not a memory safety issue unless you pass badly designed compiler flags like `-release`.

`-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.

What a range check error does can be set with the `-checkaction` switch:

-checkaction=[D|C|halt|context]
                    behavior on assert/boundscheck/finalswitch failure

> - std::map::operator[]:
>    Not a problem in D.
> 
> 
> - get_default():
>    Potential for lifetime error fixed with DIP1000.
>    Still potentially a performance problem in D without DIP1040.
> 
> 
> - volatile:
>    Not clear, but I guess `volatile` is less popular nowadays.
>    https://dlang.org/phobos/core_volatile.html

Those are special functions, and the documentation is explicit about what they are for, and not for, and atomic operations are in the "not" category. They are not part of the type system of the language.

>    D also does not have a full `shared` story so far.

It's a far better story than C++ has.


> - shared_ptr thread-safe:
>    Potentially fixed because D has transitive `shared`. But again, `shared` is unfinished. Or use GC.


> - shared_ptr bonus bug:
>    Simple pattern like the one on the slide seem superficially fixable with DIP1000, but in general in D it is not possible to make smart pointer dereferencing safe.

It is possible by blocking any attempts at bypassing the interface of it.

> Can use GC though.

Yup. Not the unsafe mess shared_ptr is.


> - lock bug:
>    That syntax would not lock until the end of the scope in D either, but for different reasons. But there is no reason to expect it would work, so I guess we can consider this fixed in D.

Unmentioned is the "if it looks like a declaration it is one" ambiguity bug, that featured fairly prominently in the talk. D does not allow:

```
void test()
{
    int (x);
}
```
Error: undefined identifier `x`

as a declaration of x.


> I guess the lessons are:
> 
> - D also does not have static typing to rule out range errors.

I don't understand that. If you have resizeable arrays, static typing is not going to give you compile time guarantees. D does allow static arrays, which can rule out range errors for statically known indices.


> - D also does not have memory safety for general allocator-backed container types.

That wasn't in his talk.


> - implement DIP1040.

We'll be moving forward with that.

> - finalize `shared`.

The idea is to disallow use of shared if it cannot be done atomically - std.atomic would need to be used.

On 7/12/24 22:13, Walter Bright wrote:
> On 7/11/2024 3:39 PM, Timon Gehr wrote:
>> - std::vector::operator[]:
>>    D code still suffers from unrecoverable range errors that would crash the website, it's just not a memory safety issue unless you pass badly designed compiler flags like `-release`.
> 
> `-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.
> ...


```d
void main(){
    auto a=[1,2,3];
    a[3]=2;
}
```

```bash
$ dmd -run tt
core.exception.ArrayIndexError@tt.d(4): index [3] is out of bounds for array of length 3
----------------
??:? onArrayIndexError [0x5a712bff44b2]
??:? _d_arraybounds_indexp [0x5a712bff180f]
??:? _Dmain [0x5a712bff1780]
```

```bash
dmd -release -run tt
```

(crickets.)

> ...
>>
>>
>> - volatile:
>>    Not clear, but I guess `volatile` is less popular nowadays.
>>    https://dlang.org/phobos/core_volatile.html
> 
> Those are special functions, and the documentation is explicit about what they are for, and not for, and atomic operations are in the "not" category. They are not part of the type system of the language.
> ...

I am aware.

>>    D also does not have a full `shared` story so far.
> 
> It's a far better story than C++ has.
> ...

I acknowledged as much at the beginning of my post.
I like D and I dislike C++.

> 
>> - shared_ptr thread-safe:
>>    Potentially fixed because D has transitive `shared`. But again, `shared` is unfinished. Or use GC.
> 
> 
>> - shared_ptr bonus bug:
>>    Simple pattern like the one on the slide seem superficially fixable with DIP1000, but in general in D it is not possible to make smart pointer dereferencing safe.
> 
> It is possible by blocking any attempts at bypassing the interface of it.
> ...

Well, the example was specifically about the dereference operator returning by `ref`.

> 
>> I guess the lessons are:
>>
>> - D also does not have static typing to rule out range errors.
> 
> I don't understand that. If you have resizeable arrays, static typing is not going to give you compile time guarantees.

It can do that. Neither D nor C++, nor other particularly popular languages are doing it yet though.

There are entire compilers that have been verified for functional correctness by the type systems of their implementation languages. This in particular includes absence of runtime errors, which is not even prone to misspecification errors.

> ...
> 
>> - D also does not have memory safety for general allocator-backed container types.
> 
> That wasn't in his talk.
> ...

`shared_ptr` was in the talk. The language-level safety challenges remain basically the same, whether you build your data structures out of `shared_ptr`s or not.

> ...
>> - finalize `shared`.
> 
> The idea is to disallow use of shared if it cannot be done atomically - std.atomic would need to be used.

At the moment, basic druntime synchronization functionality does not compile with `-preview=nosharedaccess`.

Class references cannot be tail-`shared`. etc.

On 7/12/2024 2:16 PM, Timon Gehr wrote:
> (crickets.)

It'll give the bounds check error for @safe code even with -release.

On 7/13/24 01:25, Walter Bright wrote:
> On 7/12/2024 2:16 PM, Timon Gehr wrote:
>> (crickets.)
> 
> It'll give the bounds check error for @safe code even with -release.
> 

I am aware. In C++ you can get the bounds check with std::vector::at.

Anyway, your point was:

On 7/12/24 22:13, Walter Bright wrote:
> 
> `-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.

This is false. Nothing else is required to turn off some bounds checks with `-release`, escalating out-of-bounds accesses to a memory safety issue.

On Friday, 12 July 2024 at 20:13:24 UTC, Walter Bright wrote:
> `-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.

This is very interesting because until this past week or so I thought -release implied -noboundscheck as well.  I think I've been using D around 8 or 9 years now.  I had already stopped using -release some time ago, but nonetheless, whatever documentation there was for those command line args must have been veeery slow to catch up to reality.

On Friday, 19 July 2024 at 14:34:33 UTC, cc wrote:
> On Friday, 12 July 2024 at 20:13:24 UTC, Walter Bright wrote:
>> `-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.
>
> This is very interesting because until this past week or so I thought -release implied -noboundscheck as well.  I think I've been using D around 8 or 9 years now.  I had already stopped using -release some time ago, but nonetheless, whatever documentation there was for those command line args must have been veeery slow to catch up to reality.

-release includes -boundscheck=safeonly, which turns off bounds checking in @system and @trusted code.

Most D code is not (yet) @safe, so the result is that most D code will have its bounds checks removed when using -release.

On 7/11/24 1:36 PM, Walter Bright wrote:
> https://www.youtube.com/watch?v=lkgszkPnV8g
> 
> This is a great talk. In my first pass, D doesn't suffer from any of them.
> 
> Anyone want to verify?

It was a bonus slide in one of my meetup presentations. It comes with horrible audio and speaker accent but here it is:

  https://youtu.be/qrxxgYwU1X0?t=903

Ali
"yes, alive"