Dealing with the interior pointers bug

[Boris-Barboris via Digitalmars-d-learn]

On Thursday, 22 June 2017 at 09:45:09 UTC, Russel Winder wrote:
> I think the term "systems programming language" contains no 
> actual data, so needs to be retired. In this situation it 
> provides no reason for conservative garbage collection.

It means the intent of language designer to let you write 
operating system with his language, wich implies certain building 
blocks available to you. Whether it actually allows it or not is 
another question.

> Why should any language allow anything outside the type system.
Everything the language allows to compile is allowed by it's type 
system, or is a bug in the compiler.

> Strong typing means strong typing
Define strong typing then. Pointer is part of the type system, 
all casts and operations on it are too. If you pass wrongly-typed 
pointer, it won't compile.

> Maybe then the fault is having a weak type system, as any 
> language is that allows ints to be pointers and vice versa.

What's wrong with pointers in a language? You're not forced to 
use them, you know? But some tasks force you. If you seek 
compile-time verifyability, use different coding patterns \ 
languages, designed around this intent.

> Maybe type systems should be strong and all FFI be by value 
> with no references to memory allowed?

No, they definetly should not.

Why can't GC use staticaly available type info (all 
pointer\reference variables and fields are visible in program 
text, why not just scan only them)? I don't know, probably it's 
harder, since it requires more cooperation between compiler and 
runtime, and increases GC signature (you have to store a huge 
list of pointers to all pointers on all stacks (and probably heap 
too), and compiler should generate code to populate this list on 
every function call). At this point you would be better off with 
RAII, wich will be more efficient and explicit and do exactly 
what you tell it to do.