DIP1000 observation

[Richard (Rikki) Andrew Cattermole]

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