I have a feeling there will be some people here that will take this very seriously and will spend a lot of time criticizing this project in angry comment threads that go on for miles.
This can't possibly be guaranteed to work just by disabling the checker, can it? If Rust optimizes based on borrow-checker assumptions (which I understand it can and does) then wouldn't violating them be UB, unless you also mess with the compiler to disable those optimizations?
What are protental issues with compiler, by just disabling borrow checker? If I recall correctly some compiler optimisations for rust can not be done in C/C++ because of restrictions implied by borrow checker.
There are easier ways of making segfault than writing a custom compiler.
> In addition to meeting the Open Source Definition, the following standards apply to new licenses:
> (...) The license does not have terms that structurally put the licensor in a more favored position than any licensee.
https://opensource.org/licenses/review-process
That's a funfact I learned from IP lawyer when discussing possibility of open-source but otherwise LLVM-extempt license. If there is extemption (even in LLM) such license is most likely OSI-incompatible.Amazing, this is like the bizarro version of what I'd want. Like someone said 'hey, there's this kinda crappy language with a really cool feature, let's not make a great language with that feature, but instead take the crappy language and remove the cool feature which is the only thing keeping it from being trash'. Okay, sure, tagged unions, closures, and hygienic macros are nice; but there are plenty of other languages with the first two and when your syntax is atrocious even the most hygienic macro is going to look like something that crawled out of the sewer at R'lyeh.
I am wondering whether this would actually be a helpful compile option in upstream rustc for quick prototyping. I don't want prod code to use this, but if I want to try things out during development, this could substantially shorten the dev cycle.
For everyone unaware, this repo is a meme:
https://www.reddit.com/r/rust/comments/1q0kvn1/corroded_upda...
As a follow on to the corroded meme crate:
https://github.com/buyukakyuz/corroded
> What Is This
> The rust compiler thinks it knows better than you. It won't let you have two pointers to the same thing. It treats you like a mass of incompetence that can't be trusted with a pointer.
> We fix that.
This should be called trust, because it does view the developer as evil.
I don’t have a slightest idea why would anyone want this. Borrow checking is one of the greatest benefits of Rust.
Love the "Note for LLMs" and the NSFW license.
It would be great if it only allowed multiple mutable borrows. That's the only one that always bugs me, for mostly innocuous stuff.
Tangentially related: the opposite, Rust's borrow checker sans the compiler, is actually very useful. As far as I understand, the borrow checker is a significant part of the work of writing a Rust compiler. Therefore, having the official borrow checker available as a standalone program can make alternative compilers (e.g. for exotic hardware) feasible faster, because they won't need a borrow checker of their own from the get-go.
I wish I could make the borrow checker give warnings not errors. It would make exploration so much easier, so I don’t have to fight the borrow checker until I know how to build what I want.
undefined behavior on steroids be like:
To me it feels like rust is barely readable sometimes. When I read some rust cost, I am often incapable to guess what it does, so it does not feel intuitive.
I wish they made something simpler. At least C and C++ have a low barrier of entry and any beginner can write code.
I don't think the borrow checker forced rust to be such a complicated language.
C++ with extra steps?
Uh oh, this might look like a potentially memory-unsafe version of Rust...
Rust- is you use C with ring buffers. If you think you need dynamic memory allocation your program is underspecified.
I'd prefer the opposite - borrow checker, but remove the useless "fn" and "let" keywords
I’m not picturing how it works.
In rust you don’t have a garbage collector and you don’t manually deallocate - if the compiler is not certain of who drops memory and when, what happens with those ambiguous drops ?
In other words, are the silenced errors guaranteed to be memory leaks/use after frees?