Why same pointer type for GC and manual memory?

[Basile B.]

On Friday, 15 November 2019 at 10:55:55 UTC, IGotD- wrote:
> On Friday, 15 November 2019 at 08:58:43 UTC, user1234 wrote:
>> On Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
>>> I'm trying to find the rationale why GC pointers (should be 
>>> names managed pointers) are using the exact same type as any 
>>> other pointer.
>>>
>>> Doesn't this limit the ability to change the default GC type?
>>> Doesn't this confusion make GC pointers just as unsafe as raw 
>>> pointers?
>>> Has there been any prior discussion about introducing managed 
>>> pointers in D?
>>
>> One other reason is that special pointers are not good for 
>> debugging and have a runtime cost... in D it's not like in a 
>> VM.
>
> It's true it has a runtime cost but I'm wondering if it isn't 
> worth it. There will be an extra dereference of course but this 
> is only done once per for every piece that use the fat pointer.
>
> With a fat pointer you could also provide more information, 
> allocated size for example which makes it possible to safely 
> cast the pointer to anything checking that the boundaries are 
> correct. Also reading a fat pointer (like *ptr) can check the 
> bounds. Size information is also handy for some allocators, 
> buddy allocator for example where storing the size in the 
> allocated block is something that you not always want to as it 
> throws the memory off the natural alignment which is one of the 
> benefits of the buddy allocator. In the fat pointer you could 
> store more information like reference count, type of allocator, 
> a pointer to free function (makes it possible to hotswap 
> allocators).
>
> When it comes to debugging, then you need to parse the fat 
> pointer, just like it parses common containers classes. This is 
> not a too big deal I think.

TBH I see your point but D is a system programming language. Even 
if there's a GC you can also do Manual Memory Mangement 
(sometimes you'll see "MMM "to refer to that in the forums), RC, 
and you can also write custom machine code in asm blocks.

In most of the case, if you just stick to the GC way, it'll be 
alright, even if pointers are actual machine pointers, i.e usable 
in asm blocks ;)

Recently some guys have discovered however that an aggressive 
anti virus scanner could cause problems...

Anyway, just to say, D produces machine code and doesn't requires 
a VM... if you need fat pointers for a custom memory management, 
free to you.

I don't think this will ever change.