Thoughts on Backward Compatibility

[Dukc]

On Tuesday, 20 February 2024 at 00:48:42 UTC, Carl Sturtivant 
wrote:
> On Monday, 19 February 2024 at 17:14:21 UTC, Dukc wrote:
>> If D ever were to "pick it's camp" and either force me to use 
>> the GC and the standard runtime whether I want or not, or 
>> alternatively ditch the GC it and impose RAII/ref counting 
>> instead, that would drive me away.
>
> To be clear, I am not suggesting that D should force using the 
> GC.

No worries, wasn't thinking you - rather the numerous doomsayers 
here over the years that say D can't succeed "if it can't decide 
what it wants to be". If they are right, it means my criterion 
for an ideal language is fundamentally backwards.

>
> What I *am* suggesting is that a modern GC for D would be a 
> game-changer, with the default of using the GC being the best 
> answer most of the time. People who didn't believe this could 
> find it out experimentally.

D:s GC is more modern than you might think. Yes, it stops the 
world and isn't as fast as many of the alternatives, but it's 
because it has an unique feature. Namely, the GC-collected memory 
can be referred to with raw pointers. Any GC that can stop it's 
collection and resume it afterwards must only use special 
references (that tell the GC when they are assigned to), meaning 
you can't let regular C functions to handle your GC-collected 
memory.

Maybe D would still benefit from a GC that requires pointer write 
gates, but then all D pointers (and other references, save for 
function pointers) of that program would need that write gate. 
This is not an option if, say you're writing a library for a 
foreign language that must work without the DRuntime being 
initialised. Hence the pointer assignment semantics would have to 
be behind a compiler switch. Or maybe pointer assignment would 
call a symbol somewhere in DRuntime that can be redefined by the 
user.