On Borrow Checking

[Don Allen]

On Friday, 16 May 2025 at 21:21:00 UTC, Clouudy wrote:
> On Sunday, 11 May 2025 at 20:43:52 UTC, Paul Backus wrote:
>> The reason for the negativity is that people do not want "a 
>> borrow checker." What they want is more powerful safety 
>> analysis. A borrow checker is merely one possible means of 
>> achieving that goal.
>>
>> In business terms, this is a failure of "product-market fit." 
>> You are supplying something that there is no demand for. Even 
>> if it works perfectly, nobody is going to buy it.
>
> I don't necessarily believe that the issue is "nobody wants a 
> borrow checker", because @nogc people would definitely like 
> having something similar to it, or to smart pointers. But the 
> issue is that it seems like whenever the D Devs decide to work 
> on new features they immediately get distracted by a different 
> shiny new thing before anything is completely finished.
>
> There was C++ interoperability, which doesn't completely work 
> because of inheritance (and probably other reasons, too). Then 
> there's ImportC, which doesn't work with macros because D 
> doesn't have a pre-processor (not that I would support one 
> being included in normal D, but if the goal is to let you just 
> include C files, you probably need it for C things). There was 
> obviously @nogc features scattered all around, and there's 
> still @safe which blocks some code that is actually safe. 
> Allocators are still around but nobody in the DLF wants to keep 
> them (which I disagree with).
>
> And right now there's a debate about changing Phobos and how it 
> should happen, but there hasn't been any visible progress on 
> actually implementing it. Now we're adding borrow-checking that 
> doesn't work in a familiar manner to the most famous 
> implementation of it?
>
> IMO there needs to be a temporary freeze on new features until 
> everything that is currently in the language and is incomplete 
> gets complete. Then decide on whether we want a borrow checker 
> or whether we want smart pointers (or both), then decide on 
> whether we want to keep allocators or try different memory 
> management methods, and so on. It doesn't really inspire much 
> confidence to hear "well most of this feature works but there 
> are exceptions", and a lot of people don't use D because of 
> stuff like that.

I completely agree with this. I have expressed my concern 
multiple times about warts being worked on, by which I meant 
ideas that smacked of me-too-ism and felt to me as if they had 
not been fully thought through or were part of a coherent 
strategy. My intent was something similar to what was said above, 
though Clouudy said it better.

This project does not have enormous developer resources and if it 
is to ever really succeed, it needs to apply the resources it has 
in ways that really move the project forward. The current manner 
in which decisions get made to allocate the time of someone like 
Walter are pretty far from optimal. I know this has been 
discussed to death, but I suggest that it the discussion needs to 
continue, because the problem hasn't been fixed.