On Sunday, 18 May 2025 at 03:34:43 UTC, Walter Bright wrote:
> On 5/12/2025 11:21 PM, Paulo Pinto wrote:
>> On Monday, 12 May 2025 at 21:38:28 UTC, Walter Bright wrote:
>>> It never made it into the C++ Standard, and its only use is CLI.
>> 
>> So what.
>
> Why wouldn't a GC pointer be of general utility in C++?

The GC pointer in C++ is called shared_ptr and it was considered to be of general utility... But .NET comes with its own GC based on tracing, not on reference counting and thus they added a pointer type for this. This is just some very basic good design, stop acting like multiple pointer types are somehow a "failed experiment", it's ridiculous.

On Sunday, 18 May 2025 at 05:15:02 UTC, Araq wrote:
> On Sunday, 18 May 2025 at 03:34:43 UTC, Walter Bright wrote:
>> On 5/12/2025 11:21 PM, Paulo Pinto wrote:
>>> On Monday, 12 May 2025 at 21:38:28 UTC, Walter Bright wrote:
>>>> It never made it into the C++ Standard, and its only use is CLI.
>>> 
>>> So what.
>>
>> Why wouldn't a GC pointer be of general utility in C++?
>
> The GC pointer in C++ is called shared_ptr and it was considered to be of general utility... But .NET comes with its own GC based on tracing, not on reference counting and thus they added a pointer type for this. This is just some very basic good design, stop acting like multiple pointer types are somehow a "failed experiment", it's ridiculous.

Exactly, one can start discussing language semantics of what is a GC pointer, and as anyone with formal background in compiler development theory knows, any form of automatic resource management is.

Pointing out it is a failure, when market segments bigger that the whole industrial adoption of D are using them is hardly a failure, and does very little to make D more appealing for adoption.

By the way, Apple is adding new pointer types into clang, for safer C and C++ code and also safer interop with Swift, basically their own flavour of C++/CLI.

See EuroLLVM 2025 talks.

On Saturday, 17 May 2025 at 14:03:05 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> On 17/05/2025 10:05 PM, claptrap wrote:
>> 
>> Why is safe ref counting not feasible with D?
>
> Because we don't have a borrow checker.
>
> Any kind of pointer originating from the ``this`` pointer of a RC type, must not outlive the RC owner.

We have the same problem with manual memory management don't we? So is "safe manual memory management" considered not possible in D?


>> Wouldn't the fact that most data is thread local in D mitigate the majority of the performance penalties? You dont need atomic inc/dec if its thread local do you?
>
> I evaluated this ages ago, with a simple bit of value tracking + moving the reference add into the called function, you can get rid of a ton of those deltas.
>
> Anyway, atomic add/sub have gotten much cheaper on recent hardware, like 1uop. Still good to optimize unnecessary work away though!

Well the cost is irrelevant IMO, I mean people who dont want to pay it choose a different solution, that seems to be a core idea of Dlang, gc, nogc, betterc, etc..

D should be able to do reference counting, that it can't shows failings in the language design.

On 5/18/25 14:20, claptrap wrote:
> On Saturday, 17 May 2025 at 14:03:05 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>
>> On 17/05/2025 10:05 PM, claptrap wrote:
>>>
>>> Why is safe ref counting not feasible with D?
>>
>> Because we don't have a borrow checker.
>>
>> Any kind of pointer originating from the ``this`` pointer of a RC type, must not outlive the RC owner.
> 
> We have the same problem with manual memory management don't we? So is "safe manual memory management" considered not possible in D?

It's possible to some extent, you just cannot hand out raw pointers to manually allocated memory.

On Sunday, 18 May 2025 at 12:20:54 UTC, claptrap wrote:
> On Saturday, 17 May 2025 at 14:03:05 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Any kind of pointer originating from the ``this`` pointer of a RC type,
>> must not outlive the RC owner.
>
> We have the same problem with manual memory management don't we?
> So is "safe manual memory management" considered not possible in D?

Of the cases:
  1) spatial
  2) temporal
  3) type
  4) init

It is only really '2' which is problematic for safe manual management in D, e.g. betterC mode with @safe + dip1000 + dip1021.  i.e. use-after-free and double-free.

I happened to read a piece yesterday, about tagged pointers as a form of smart pointer for C++, and it should be directly convertible to D.

https://btmc.substack.com/p/tagged-pointers-for-memory-safety