On Monday, 2 September 2024 at 09:48:44 UTC, Nick Treleaven wrote:
> On Sunday, 1 September 2024 at 20:42:14 UTC, Donald Charles Allen wrote:
>> But it makes no sense to me to try to turn D into Rust, because you don't have the luxury of starting with a blank sheet of paper as the Rust project did. D's multiple memory-management methods, some inherited from C, make it inherently memory-unsafe, so trying to provide memory-safety guarantees is very difficult and will almost certainly make a mess of the language. Section 20.24 says to me that a start has been made on that mess.
>
> Safe Rust is too restrictive about mutability.
> DIP1000 is about extending the amount of code that can be @safe. DIP1000 removes restrictions.
>
>> I think the D project should focus on increasing the distance between D and C/C++ and forget about competing with Rust. Those who want guaranteed memory-safety are likely to just use Rust.
>
> D supports GC, so heap allocation does not have to restrict safe operations. DIP1000 shows you can often use safe pointers to stack memory without Rust's mutability restrictions.

While I think it is beside the point, I agree with you about Rust's mutability restrictions. They assume everything you write is multi-threaded. There is no way, other than using "unsafe", to say to the compiler "just relax -- this code is single-threaded".

What Rust does or does not do is not relevant to turning D into a language that is incomprehensible except to lawyers, which is what appears to be happening.

On 03/09/2024 1:05 AM, Donald Charles Allen wrote:
> On Monday, 2 September 2024 at 09:48:44 UTC, Nick Treleaven wrote:
>> On Sunday, 1 September 2024 at 20:42:14 UTC, Donald Charles Allen wrote:
>>> But it makes no sense to me to try to turn D into Rust, because you don't have the luxury of starting with a blank sheet of paper as the Rust project did. D's multiple memory-management methods, some inherited from C, make it inherently memory-unsafe, so trying to provide memory-safety guarantees is very difficult and will almost certainly make a mess of the language. Section 20.24 says to me that a start has been made on that mess.
>>
>> Safe Rust is too restrictive about mutability.
>> DIP1000 is about extending the amount of code that can be @safe. DIP1000 removes restrictions.
>>
>>> I think the D project should focus on increasing the distance between D and C/C++ and forget about competing with Rust. Those who want guaranteed memory-safety are likely to just use Rust.
>>
>> D supports GC, so heap allocation does not have to restrict safe operations. DIP1000 shows you can often use safe pointers to stack memory without Rust's mutability restrictions.
> 
> While I think it is beside the point, I agree with you about Rust's mutability restrictions. They assume everything you write is multi-threaded. There is no way, other than using "unsafe", to say to the compiler "just relax -- this code is single-threaded".
> 
> What Rust does or does not do is not relevant to turning D into a language that is incomprehensible except to lawyers, which is what appears to be happening.

A lot of the issues surrounding Rust and its lifetime stuff is not related to the borrow checker.

If you read any of the complaints they pretty much all center around trying to solve aliasing. This includes requiring you to use the ownership transfer system. This would never be the default in D.

For D even with owner escape analysis, there is no reason for GC memory to not work in a graph.

The core issue with using DIP1000 is that it is not trying to solve escape analysis or owner escape analysis for heap memory. It is being misused to try to model heap memory. I do not believe that it is fixable, it's simply solving a problem in a way that directly negatively affects most code, and it does so by not respecting the problem domain or the literature on the topic.

- Someone that has well over ~120k LOC of DIP1000 annotated code

On Monday, 2 September 2024 at 13:15:51 UTC, Richard (Rikki) Andrew Cattermole wrote:
> The core issue with using DIP1000 is that it is not trying to solve escape analysis or owner escape analysis for heap memory. It is being misused to try to model heap memory. I do not believe that it is fixable, it's simply solving a problem in a way that directly negatively affects most code, and it does so by not respecting the problem domain or the literature on the topic.

As someone who has written a bunch of code using DIP 1000 to try and model ownership of heap memory, I can confirm that this is 100% correct. The way it's done is by essentially lying to the compiler, and telling it to treat a pointer to the heap *as though* it's a pointer to the stack.

It's kind of like template metaprogramming in C++. It's a clever hack, and the fact that it works at all is kind of impressive. But we shouldn't *have* to resort to clever hacks like this to solve simple problems.

On Monday, 2 September 2024 at 13:15:51 UTC, Richard (Rikki) Andrew Cattermole wrote:
> The core issue with using DIP1000 is that it is not trying to solve escape analysis or owner escape analysis for heap memory. It is being misused to try to model heap memory.

Don't forget there are people using it as intended :)

On 03/09/2024 6:26 AM, Sebastiaan Koppe wrote:
> On Monday, 2 September 2024 at 13:15:51 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> The core issue with using DIP1000 is that it is not trying to solve escape analysis or owner escape analysis for heap memory. It is being misused to try to model heap memory.
> 
> Don't forget there are people using it as intended :)

Thanks to your comment I realized that DIP1000's attributes and my proposal's could live side by side during transition period.

And yes, there absolutely should be a transition period. No way I want to hurt anyone doing just that!

It would be great if you would comment on my proposal, my suspicion is at least for things that are not virtual, it should "just work" for you.

On Tuesday, 3 September 2024 at 03:03:51 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 03/09/2024 6:26 AM, Sebastiaan Koppe wrote:
>> On Monday, 2 September 2024 at 13:15:51 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> The core issue with using DIP1000 is that it is not trying to solve escape analysis or owner escape analysis for heap memory. It is being misused to try to model heap memory.
>> 
>> Don't forget there are people using it as intended :)
>
> Thanks to your comment I realized that DIP1000's attributes and my proposal's could live side by side during transition period.
>
> And yes, there absolutely should be a transition period. No way I want to hurt anyone doing just that!
>
> It would be great if you would comment on my proposal, my suspicion is at least for things that are not virtual, it should "just work" for you.

Been swamped and didn't want to do a shallow one. Your coroutines one is still in the queue as well.