[indigoabstract]

My controversial opinion:

If Rust were to "borrow" something from the C/C++ spirit, then disabling the borrow checker should be available as a compiler option.

As in, you're an adult: if you want it, you can have it, instead of "we know better".

[whatshisface]

If you could disable the borrow checker globally, projects would do it, and it would become impossible to compile anything with it enabled.

You can already disable it locally: the unsafe keyword is for that.

[gpm]

The unsafe keyword doesn't disable the borrow checker... it lets you interact with different pointer types that aren't borrow checked, but if you're using the normal reference types in rust the same guardrails are still in place.

[pornel]

That's not the spirit Rust wants to have. You can already disable borrow checker selectively by using "raw" pointers in places where you think you know better, and this is used very commonly. Every String in Rust has such raw pointer inside.

It doesn't make much sense to globally relax restrictions of Rust's references to be like C/C++ pointers, because the reference types imply a set of guarantees: must be non-null (affects struct layout), always initialized, and have strict shared/immutable vs exclusive access distinction. If you relax these guarantees, you'll break existing code that relies on having them, and make the `--yolo` flag code incompatible with the rest. OTOH if you don't remove them, then you still have almost all of borrow checker's restrictions with none of the help of upholding them. It'd be like a flag that disables the sign bit of signed integers. It just makes an existing type mean something else.

[klysm]

Doesn’t work - you need the borrow checker guarantees to implement downstream compilation steps. You can just turn off assumptions

[gpm]

> you need the borrow checker guarantees to implement downstream compilation steps.

You don't technically. The borrow checker doesn't effect the semantics of the program (like, for example, type inference does) and the rest of the compiler doesn't need to (and in fact, doesn't) use its analysis to figure out how to compile the code.

The downstream compiler does assume that the code followed the rules for accessing references - i.e. didn't violating aliasing rules. The borrow checker guarantees this, but it's fundamentally a conservative check. It rejects programs it can't guarantee are correct, and rice's theorem proves that there are always correct programs that it can't guarantee are correct.

That said if you just treat rust-references like C-pointers you will run into issues. The aliasing rules for rust references are stricter. Also not fully agreed upon yet - the currently closest to accepted definition is in the "tree borrows" paper but it has yet to be adopted as the official one by the rust team.

[MangoToupe]

Is rust simple aesthetics to you? Why use rust, or any language at all really, at all then? The whole point of formal languages is to point a gun at the people who refuse to be adults.

If we can't have this, C itself offers zero benefit over assembly.

[indigoabstract]

I think it's more in the spirit of playfulness, like in "don't take yourself too seriously". It's why people want to mod Minecraft and Doom for example.

Because it's fun.

I can totally understand why you wouldn't want to do this though - the plethora of incompatible lisp dialects come to mind. That's why I said it was controversial.

[Wowfunhappy]

You don't think assembly is more tedious to write than C? I don't think that's because of what C does/doesn't "allow" you to do.

[yazaddaruvala]

Of course it is. C does allow named functions and variables. C doesn’t allow arbitrary jumps.

Those are two reasons why C is less tedious than assembly.

[1718627440]

> C doesn’t allow arbitrary jumps.

Have you heard of longjmp?