It is not ridiculous at all. Those things have pretty precise definitions and type segregation absolutely does remove a bunch of soundness issues related to type confusion.

You can think of it as the rather classic "Vec of struct + numeric IDs" that is used a lot e.g. in Rust to represent complex graph-like structures.

This combined with bound checking is absolutely memory safe. It has a bunch of correctness issue that can arise due to index confusion but those are not safety issues. When combined with some kind of generational counters those correctness issue also go away but are only caught at runtime not at compile time (and they incur a runtime cost).

Rust's memory safety is about avoiding liveness issues (that become type confusions since all memory allocators will reuse memory for different types), nothing more, nothing less.

> but those are not safety issues.

there are not memory safety issues. But they definitely can lead to security issues with some sort of confused deputy attack.

For example a capability based system that relied on just this form of memory safety would be pointless.

Of course this can be mitigated by adding version counters to objects and object selectors.

FWIW, arrays of structs + integer handles is the primary way objects are represented in performance-engineered C++.

Maybe we need to introduce the term "value safety" to complement "type safety".

If a language is merely type-safe, then it might be OK to silently replace a value with a different one of the same type, sure, fine. Who cares if the program transmits the wrong message to the wrong recipient as long as it's definitely some message and some recipient?

But a value-safe language, I suggest, is one that doesn't pull this kind of switcheroo.

“Safety” is a very overloaded English word with strong connotations, and the popularization of it in the context of “memory safety” has been good in some ways, but has really poisoned the discourse in many others.

Reminds me of a video I saw about "cloning" on Super Mario 64[1]. SM64 uses slots and one can mess around with slot deletions to get random objects.

[1] https://www.youtube.com/watch?v=X2AhyDI58-I

It absolutely is. Some embedded mallocs do this under the hood against a predefined linker table. Genuinely helps even with the restrictions it imposes.

Are you implying that it is unsafe? Or that it is unrelated to safety properties?

It just shows memory safety is a joke, simply replacing a class of bugs with another.

It isn't a joke. With memory safety bugs the value of an object can unexpectedly be any bit pattern. That breaks the assumptions of basically every language and leads to pretty much anything happening.

If you have an array of objects of the same type and you just pick the wrong one, then the data still has to be a valid bit pattern. Yes it might still be a security bug, but it's much less likely because you aren't completely subverting the language.

Surely you don't think all bugs are the same because they are all bugs?

It takes a lot more for a program to be correct than having valid bit patterns.

To begin with, the whole point of classes is to maintain invariants. Guaranteeing that a location in memory matches the valid bit patterns of its members is far from sufficient.

> It takes a lot more for a program to be correct than having valid bit patterns.

Obviously. I never said otherwise. What's your point?