> It's not a misconception, there are plenty of times in the past year that I've heard someone propose some change for the new edition only for the Rust devs to meet it with "that's not possible because we can't infallibly warn for it in the compiler, so there's no point discussing it".
Do you have examples for that?
Edit: I'm not doubting you, but having precedent of things that were rejected due to breakage it causes might be helpful in some current/future discussions :)
> Furthermore, just because we can imagine things that could be broken, it doesn't mean that the Rust developers interpret that as carte blanche to break things. The history of Rust development since 1.0 has been one of careful, gradual, and conservative change.
My fear is that this is currently changing. There are a couple of threads on the internals forum currently collecting ideas of what people want changed in future epochs. To me, that's a shift to a different mode of operation. From "editions allow breakage as last resort" to "editions make breakage no longer a big issue".
> It appears that you have a lot of fear about various things that you imagine might be changed (such as ref and ref mut in patterns, which is sort of head-scratching because I've never heard anyone propose removing them, and it wouldn't make sense to remove them anyway)
The idea also seemed like a big hit in #rust-lang at the time. People were quite gleeful that `ref` could go away at some point.
I'm happy it's no longer on the table, but having to fight for the ability to destructure into mutable and immutable felt wrong.
Same thing with the modules redesign. Having to fight that hard for your existing workflows and use-cases not to be broken through multiple RFCs felt wrong as well.
Having some constructs auto-convert their final result value seems certain at this point.
> but I think such fears are unwarranted. I've been observing the Rust developers at work longer than almost anyone, and I've ended up with a degree of trust in their sense of taste that rivals that of any other project that I've seen. The people behind the language today are the same ones who have been behind the language for years now, so if you happen to like where their influence has led the project so far, I think it's reasonable to trust that they won't abruptly leap off the rails. :)
I've been following Rust since 0.10 or so, so I've been there quite a while as well. I was there for the uint wars, the battle of match ergonomics, and of course the big module rework skirmish.
I'm sure nobody is acting out of malice, my fears are more that with a certain community size, it is easy to be drowned out if you have different needs or opinions.
Do you have examples for that?
Edit: I'm not doubting you, but having precedent of things that were rejected due to breakage it causes might be helpful in some current/future discussions :)
> Furthermore, just because we can imagine things that could be broken, it doesn't mean that the Rust developers interpret that as carte blanche to break things. The history of Rust development since 1.0 has been one of careful, gradual, and conservative change.
My fear is that this is currently changing. There are a couple of threads on the internals forum currently collecting ideas of what people want changed in future epochs. To me, that's a shift to a different mode of operation. From "editions allow breakage as last resort" to "editions make breakage no longer a big issue".
> It appears that you have a lot of fear about various things that you imagine might be changed (such as ref and ref mut in patterns, which is sort of head-scratching because I've never heard anyone propose removing them, and it wouldn't make sense to remove them anyway)
Here is one mention of it: https://github.com/rust-lang/rfcs/pull/2005#issuecomment-305...
The idea also seemed like a big hit in #rust-lang at the time. People were quite gleeful that `ref` could go away at some point.
I'm happy it's no longer on the table, but having to fight for the ability to destructure into mutable and immutable felt wrong.
Same thing with the modules redesign. Having to fight that hard for your existing workflows and use-cases not to be broken through multiple RFCs felt wrong as well.
Having some constructs auto-convert their final result value seems certain at this point.
> but I think such fears are unwarranted. I've been observing the Rust developers at work longer than almost anyone, and I've ended up with a degree of trust in their sense of taste that rivals that of any other project that I've seen. The people behind the language today are the same ones who have been behind the language for years now, so if you happen to like where their influence has led the project so far, I think it's reasonable to trust that they won't abruptly leap off the rails. :)
I've been following Rust since 0.10 or so, so I've been there quite a while as well. I was there for the uint wars, the battle of match ergonomics, and of course the big module rework skirmish.
I'm sure nobody is acting out of malice, my fears are more that with a certain community size, it is easy to be drowned out if you have different needs or opinions.