^^^

What moonchild says.

I've worked with languages with multiple fundamental pointer types (needed for 16 bit code). This kind of thing never worked well. For example, you'd need 4 versions of strcpy() to deal with 2 pointer types. What a mess DOS programming was with that.

It's a good thing that's not the solution I proposed, then.

> So instead, generate multiple definitions and rewrite callers:

Yes, in much the same fashion as with template functions: multiple definitions are generated, and callers are rewritten to target the appropriate specialisation.

Code bloat comes with its own performance problems (code caching).

Besides, I seriously doubt that there's much gold in unambiguously recognizing stack pointers. I try to put as much as possible on the stack, but it just doesn't seem like much. The more stack allocation you manage to do, the more code bloat gets generated. Any malloc'd pointer will look just like a GC pointer, so you'll be paying the penalty for all of those.

How these tradeoffs play out will be difficult to determine in advance. If you've the confidence that it will work out favorably, by all means, give it a try.

Of course, one could add user annotations, but annotations are generally disliked.

> Any malloc'd pointer will look just like a GC pointer, so you'll be paying the penalty for all of those.

I don't see why. A small amount of manual tagging for extern(C) things—done in this case as part of the standard library, so opaque to user code—will go a long way in that regard. And in any custom allocator, automatic inference should work just fine, since the data returned will be clearly derived from the already-tagged malloc/mmap/VirtuallAlloc/whatever (type info does still have to be associated manually, of course, as part of the GC.addRange dance, to avoid spurious pinning).

That would all come undone with separate compilation. You'd have to recompile the entire program every time.

You'd also have to keep around a massive amount of data at compile time. A variable that's a pointer to a struct, can't just be represented as a pointer to a struct. It'd have to have a map of which pointers in the struct are managed for every pointer to that struct.

The way the D compiler is implemented now, a struct S has only one instance, as every pointer to a struct's type points to that same instance. And still sometimes people compile programs so large the compiler runs out of memory.

You were complaining about 1% performance deltas else-thread—anyone remotely serious about performance is using LTO.

If you were going to debate in a public forum, you should have anticipated some pedantic loser like myself coming along and pointing out your No True Scotsman fallacy.

> You were complaining about 1% performance deltas else-thread (...)

You should revisit that corner of the thread to revive your memory. The discussion was about adding an extra 1% performance penalty for reasons, not the importance of a 1% delta either way.

Well, we are already avoiding having too much template instantiations with C++ and D so it's not very appealing.

> What a mess DOS programming was with that.

You could always use huge pointers in the general case, and treat 16-bit pointers as an optimization only. This is probably how these platforms might be best supported by something like modern GCC/LLVM.

> You could always use huge pointers in the general case, and treat 16-bit pointers as an optimization only

Data flow analysis isn't that good.

> Data flow analysis isn't that good.

It definitely wasn't in the old DOS days. But it's worth testing the approach in the context of modern platforms.

Interesting, I will read through those