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?

it seems like the clean syntax makes the type checker's life harder and so performance is unacceptable. would you rather have clean syntax or acceptable compile times?

I want both! I strongly believe the computer should relieve the user of all the obvious, tedious, boring tasks. That includes figuring out types, if they can be figured out by inspecting the code. Obviously this isn't an easy problem to solve efficiently, but I think it's worth optimizing this heavily, instead of just giving up and forcing the developer to write "dumb" annotations.

Edit: I'm no expert in this topic, but Prolog interpreters (compilers?) have some fascinating machinery to solve complex constraints. Maybe a similar approach could help here?

Trait instantiation in most languages is already using a Prolog-like approach.

そんな暇ねぇよ

アニメーをたくさん見られる暇あるなら、勉強する時間だってあるはずだぜ。

if it was in c, who knows how many memory corruption bugs would be found before they stumbled upon this...

In C, the library in question would already be many decades old and with minimal churn, and thus those memory corruption bugs would have been discovered long ago.

There are advantages to building on mature foundations, even if techniques used to build those foundations are dated by modern standards.