[hvdijk]

> But your "facts" are "if I use the API wrong, it behaves wrong."

Kind of, yes. That is what memory safety is about, isn't it? If I look for definitions, I find for instance <https://hacks.mozilla.org/2019/01/fearless-security-memory-s...>, explaining it as:

> When we talk about building secure applications, we often focus on memory safety. Informally, this means that in all possible executions of a program, there is no access to invalid memory. Violations include:

> - use after free

> - null pointer dereference

> - using uninitialized memory

> - double free

> - buffer overflow

std::optional does not itself protect against using uninitialised memory, it merely provides the tools by which the programmer can prevent using uninitialised memory. Isn't that exactly what memory safety is about, about having std::optional somehow automatically ensure that that doesn't happen? If that isn't what memory safety is, what, in your opinion, does it mean instead?

Note that I have attempted to refrain from posting my opinion on whether C++ made the right call or not. That is a separate question from whether it qualifies as memory-safe.

[kllrnohj]

I'm not arguing that c++ is memory safe, it isn't. But the initial claim is that std::optional is "explicitely anti-memory-safety". And that seems like a very unsupported claim. std::optional isn't safer than the rest of C++, but it's definitely not less safe either.

[hvdijk]

Ah, thanks for the clarification, I think we've been talking about two slightly different things, then. For you, std::optional would have to make C++ more memory-unsafe than it already is in order for "anti-memory-safety" to be a fair characterisation. For me, that label merely implies that memory-safer alternative designs of std::optional were considered, and the current design was picked despite its memory-unsafety being a known potential issue. I think I would likely agree with you that std::optional does not make C++ less memory-safe than it already was before that got added.