On Wednesday, 23 October 2019 at 15:31:24 UTC, Exil wrote:
> D isn't a systems programming language



"“But D has a GC!”, I hear you exclaim. Yes, but it’s also a systems programming language with value types and pointers, meaning that today, D isn’t memory safe. DIP1000 was a step in the right direction, but we have to be memory safe unless programmers opt-out via a “I know what I’m doing” @trusted block or function. This includes transitioning to @safe by default."

https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

-Alex

On Wednesday, 23 October 2019 at 16:54:36 UTC, 12345swordy wrote:
> "“But D has a GC!”, I hear you exclaim.

No body said that. Funny how you chose the simplest argument to argue against.

> Yes, but it’s also a
> systems programming language with value types and pointers, meaning that today, D isn’t memory safe. DIP1000 was a step in the right direction, but we have to be memory safe unless programmers opt-out via a “I know what I’m doing” @trusted block or function. This includes transitioning to @safe by default."
>
> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
>
> -Alex

Despite the mess DIP1000 was and still is, it did actually solve some problems. Even still there are bugs related to DIP1000 that aren't being fixed anymore cause the focus has already shifted away from it. The DIP1000 still says it will be "updated" but that's most likely never going to happen. Especially considering this DIP1021 has an example of a bug that the DIP doesn't even fix.

For @safe, it is already safe if you use the GC. If you use @safe with DIP1021 you are restricting the user in what code they can write and it doesn't make their code any safer. This is just a flat restriction for no purpose for them.

For manual memory management, this does not solve the problem illustrated by the DIP's example. Especially considering that in a blog post (formally unbeknownst to the DIP1021) the intention is to introduce a @live attribute. And the actual problem won't actually be fixed unless the @live attribute is there.

So it doesn't benefit @safe users, it doesn't benefit manual memory management users and it won't come to fruition until some future attribute is implemented. I'm all for implementing Rust's memory management in D, but this is just horrible project management in all regards. Maybe it wouldn't be that big of a deal if it was a smaller project where you can muddle through finding your way willy nilly, but the whole purpose of the formalities -is- should be so you don't do that.

On Sunday, 20 October 2019 at 12:31:23 UTC, Mike Parker wrote:
> DIP 1021, "Argument Ownership and Function Calls", has been formally accepted with minor revision. It was updated to make clear that the proposal is one piece of a bigger plan.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md

Is there a connection between this DIP and the restrict qualifier in C? This DIP basically ensures that in @safe code, if a piece of data is accessed only through scope pointers, then there must be only one mutable pointer to said data or they are all const. That there is only one mutable way to access data sounds like restrict to me. I would think that would enable some optimizations in @safe code.

On 10/28/2019 12:23 PM, jmh530 wrote:
> Is there a connection between this DIP and the restrict qualifier in C? This DIP basically ensures that in @safe code, if a piece of data is accessed only through scope pointers, then there must be only one mutable pointer to said data or they are all const. That there is only one mutable way to access data sounds like restrict to me. I would think that would enable some optimizations in @safe code.

I hadn't thought of that, it is an interesting observation.

On Monday, 28 October 2019 at 20:23:50 UTC, Walter Bright wrote:
> On 10/28/2019 12:23 PM, jmh530 wrote:
>> Is there a connection between this DIP and the restrict qualifier in C? This DIP basically ensures that in @safe code, if a piece of data is accessed only through scope pointers, then there must be only one mutable pointer to said data or they are all const. That there is only one mutable way to access data sounds like restrict to me. I would think that would enable some optimizations in @safe code.
>
> I hadn't thought of that, it is an interesting observation.

Just for context, here's a paper arguing restrict without tooling is a bad idea: http://people.cs.pitt.edu/~mock/papers/clei2004.pdf .  Having the compiler enforce it changes the game substantially, I think.

On 10/28/2019 2:38 PM, Ben Jones wrote:
> Just for context, here's a paper arguing restrict without tooling is a bad idea: http://people.cs.pitt.edu/~mock/papers/clei2004.pdf .  Having the compiler enforce it changes the game substantially, I think.

I've always known it was a bad idea (not just me, it was common knowledge). People have a hard time understanding restrict, and are guaranteed to use it wrong. Let alone errors using it from people who do understand it.

Compiler enforcement is the only way to make it go.

On Monday, 28 October 2019 at 21:53:50 UTC, Walter Bright wrote:
> I've always known it was a bad idea (not just me, it was common knowledge). People have a hard time understanding restrict, and are guaranteed to use it wrong. Let alone errors using it from people who do understand it.
>
> Compiler enforcement is the only way to make it go.

It isn't possible to prove it for a compiler in many cases.  Not without full verification, and even then it is hard.

So yeah, having it is good, but requiring it isn't competitive (vs C restrict).

On Monday, 28 October 2019 at 19:23:30 UTC, jmh530 wrote:
> they are all const. That there is only one mutable way to access data sounds like restrict to me.

Well, if you add the constraint that there also is no const way to access the data.

But unique ownership is stricter than «restrict», which only guarantees that there is no aliasing (overlapping) between the pointed-too-memory. No guarantees for there not being other pointers to the same memory.

It is basically only significant when accessing arrays, like when you are calling a function with two windows onto the same array. Proving that the two windows don't overlap is not always possible without a performance loss.

Being able to tell the compiler that there is no overlap makes sense when doing inline updates in an array, so that the compiler can restructure instructions and use SIMD.  Without restrict you would often have to write the single array element before reading another (as they could point to the same memory location).

BUT «restrict» is very crude. It would probably be better to provide more narrow guarantees (e.g. «the offset between the two pointers is at least 16 bytes»).