> Constructing an invalid pointer in rust is UB

no, it is dereferencing, not constructing, an invalid pointer, that is UB. there is even a safe function provided to construct an invalid but non-null pointer: `https://doc.rust-lang.org/stable/std/ptr/fn.dangling.html`

you're of course 100% right, I was so proud of my nerd joke that I got like the most basic rust safety rule wrong :(

is the fact that CHERI works better with C/C++ because of C/C++'s "anything goes" attitude, or simply that any hardware design that didn't support C/C++ well was discarded?

> simply by adding the formal verification that proves the safety which will work automatically

"simply" and "formal verification" are usually oxymorons, never mind "automatically"

Fair enough, but I have seen how it works and for just temporal memory safety, it could be simple.

Regular variable definition shadows. Macros expand to regular Rust code, they could always be replaced by the expanded body.

yes, but the code inside is unsafe. the pin macro is like a safe function.

I'm not sure what that has to do with anything. The macro isn't what makes it safe. The unsafe code being properly written is.

but without macros, how would you expose a safe interface?

  fn pin(x: T) -> Pin<&mut T> { ... }

would move the value

Your macroless variant of Rust would offer a safe builtin that does this. It doesn't need to be implemented with a macro.

Since macros just expand into code, how could you imagine that a macro is ever necessary?

the macro uses unsafe inside, so that's another instance of unsafe you'll need to check, whereas the pin macro is like a safe function

Excellent goalpost moving! Congratulations!

no, you just missed my point. expanding the implementation is not a safe abstraction. show me how you'd implement the functionality of the pin macro as a safe abstraction.

I didn't miss that you totally changed the subject and now you're attacking a strawman. See Steve Klabnick's response to your other comment where you did this. Of course macros are good for encapsulation and abstraction, but that's a different subject--and note that the discussion was about Zig vs. Rust, and Zig has no macros so there's unencapsulated unsafe code all over the place.

I won't respond further.

i was responding this claim

> It would be perfectly possible to design a variant of Rust that gets you to 80-90% of Rust's usability, with the same safety, without macros.

i then present an api that i think relies on macros to expose a safe api

> Of course macros are good for encapsulation and abstraction, but that's a different subject.

no it's not. exposing safe abstractions is pretty much rust's raison d'être

everything in zig is unsafe and needs to be checked like rust unsafe, so…

isn't that more like optimistic concurrency control?

> and you dont really have the choice - every society you could choose to be in, with the exception of yourself being a dictator, will have such people

in ancient times, you could banish people from the village

> engineers are expected to read the data sheet

even if you know what the data sheet says, it's easier said than done, especially when the tool gives you basically no help. you are just praying people will magically just git gud.

in my mind it would be doing what fil-c does for c to unsafe rust: a hypothetical memory safe implementation of unsafe rust using the same methods fil-c does e.g. gc

Can't do GC unless you go all-in.

So that implies just running all of Rust through the Fil-C transformation

> Can't do GC unless you go all-in.

It can be done, especially with a safe non-GC language that can meaningfully guarantee it won't corrupt GC metadata or break its invariants. You only have real issues (and then only wrt. excess overhead, not unsoundness) with pervasive mutual references between the GC and non-GC parts of the program. You do need to promote GC pointers to a root anytime that non-GC code has direct access to them, and add finalizers to GC objects that may need to drop/run destructors on non-GC data.

that's what I expected, thanks for making this clear!

what would fil-rust do that miri doesn't?

e.g. validate safety across safe/unsafe boundaries

Miri does do that? It is not aware of the distinction to begin with (which is one of the use cases of the tool: it lets us exercise safe code to ensure there aren't memory violations caused by incorrect MIR lowering). I might be mistaking what you mean. Miri's big limitation is not being able to interface with FFI.

hmmm I thought miri was used in the compiler for static analysis, wasn't aware it's a runtime interpreter.

I guess the primary reason would be running hardened code in production without compromising performance too much, same as you would run Fil-C compiled software instead of the usual way. I've no idea if it's feasible to run miri in prod.

I guess the confusion happens because MIR: the representation, mir: the stage, stable MIR: the potential future API interface for hooking into the compiler stage, and miri: the MIR interpreter all share pretty much the same name. Const evaluation uses MIR and that's the most likely culprit. Miri is an interpreter (as you found out on your own now), and it is not meant for use in production workloads due to the slowdown it introduces, so it limits its use to use in test suites and during debugging.

From my understanding Fil-C is an LLVM operation, so it should be possible to build integration to have a Fil-Rust binary that is slower but gives you some of the benefits of miri. I see value in doing something like that. There are plenty of other languages that would be well served by this too!

> With non-deterministic tests I would always wonder if it's going to fail randomly after the code is already in production.

if you didn't use property-based testing, what are the odds you would've thought of the case?