[FpUser]

>"Does anybody else wish the compiler wouldn't"

Compiler being obtuse and not being able to figure when it is safe to "break rules" is the problem. Not twisting brain of the programmer into being "safe compiler". This sounds like a Stockholm syndrome.

>"you should be following immutable practices"

No I should not. I should do what makes sense in particular situation and not bending over for some zealots trying to enforce one and the only way.

[chlorion]

In C++ or C, you are always twisting the brain of the programmer into being a "safe compiler". I don't think that is an advantage personally.

Lifetimes don't go away just because there isn't a borrow checker or way to define them in the source code.

[FpUser]

I do not have this impression. As for managing lifetimes in modern C++ I've already stated elsewhere that from my personal experience this problem practically does not not exist for application level programming. People writing OS level code will of course disagree but luckily I am not in that domain. I do write code for low power microcontrollers but I use plain C and do not have any real problems as there are no allocations / freeing. Just be careful with interrupts when handling shared data.

[verdagon]

This isnt quite true, you can have memory-safe single ownership without borrow checking, and it feels quite different than what Rust has us do.

[neerajsi]

I think one measurable outcome here is what kind of error message you get when you do violate a rule and whether rust users know what to do to fix their code. As a person who loves to explore the complexity behind seemingly simple interfaces, this stuff is really cool. On the other hand, I don't relish having people break their brains to understand why similar code is accepted vs not.

I'm not a rust user myself, but I'm guessing from all the references to raw pointers that a lot of the code referenced here is actually not idiomatic for all but small snippets of high perf code, so maybe the complexity is not going to affect too many people.

[FpUser]

>"so maybe the complexity is not going to affect too many people"

I think this approach shows a high level of disrespect for users.

[neerajsi]

I work with many people who are quite intelligent but early in their career or not domain experts in PL implementation. These people are perfectly respectable, but how long would it take to teach them how to map their source to the lifetime dependency tree with subtle rules in order to understand a borrow checker result that triggers an error? Without that understanding, a dev using rust would maybe try poking at their code unsystematically in hopes of getting it to work. I've seen this happen in other domains while people are ascending the learning curve.

[FpUser]

I have to apologize here. Not sure what was with my brain at the moment but I've misunderstood your entire original reply.

[Ygg2]

> Compiler being obtuse and not being able to figure when it is safe to "break rules" is the problem.

Compiler afaik will never be able to correctly 100% identify you are or aren't breaking some properties due to Rice's Theorem.

That said, you're committing a Nirvana fallacy. Perfect doesn't prevent improvement.

E.g. seatbelts don't prevent being stabbed by a large metal pole, ergo it's useless.

Every week I see newbies coming and asking why won't compiler allow this - and then point a hugely unsafe action.

Hell, I ran into a similar issue. I wanted to expose something mutable as immutable. My argumentation was but it was immutable at time of calling. However as someone in Rust discord pointed, using that you could cause UB trivially.

[FpUser]

>"Compiler afaik will never be able to correctly 100% identify"

Nobody here is talking about 100%. I responded to a post that has left me with the impression that it is up to the user to bend backwards and make their brains work as a compiler rather than try to improve compiler.

[Ygg2]

> that it is up to the user to bend backwards and make their brains work as a compiler

What do you mean? You always have to track lifetimes and what outlives what (i.e. work of a compiler). Especially in C++. Not doing that results in UB.

In Rust you have a compiler double checking you. And it errs on side of caution. And no, errors aren't horrible, they come with suggestions for fixing them.