91–100 of 133 posts
The progress on the error messages truly is worth highlighting, and kudos to the team for all the hard work there. It's one of the hardest things to get right in a programming language, particularly if that language has a fussy compiler.
Earlier quoted context omitted.
I think more interesting would be something we're truly stuck with (at least until Rust 2.0, which may never come).
(Stuff that’s deprecated in the standard library is stuff we’re stuck with; they cannot be removed in editions.)
This way slowly the ecosystem could move and stuff could be eventually removed.
Earlier quoted context omitted.
I've been complaining for a long time that `Drop` is fundamentally wrong. Rust's "just write a new function" fixed C++'s "construction is mutation of location", but Rust's Drop makes the same mistakes as C++: destruction needs to be for consuming data, not borrowing it and mutating it. Now, we can't just do drop (T) because of DSTs, so we we'll need a new type of consuming reference. And the dual to that, an initiali…
> but Rust's Drop makes the same mistakes as C++: destruction needs to be for consuming data, not borrowing it and mutating it. but Rust's drop isn't for that purpose. It's not for the actual cleanup of the struct and its children it is for additional cleanup before the children are deleted. So it has to be mutable. The compiler synthesizes the "delete children" code. (I don't understand your point about drop )
I think that purpose is the tail wagging the dog, an explanation of the current method rather than an actual requirement.
The simpler thing to do is just have drop on the aggregate calls drop on the fields, just as new on the aggregate can call new on the fields.
I hope Rust adds the major anticipated features (GATs, const generics, specialization) soon, or alternatively decides to not implement them altogether. I'm a rather new Rust developer, but still I very quickly ran into the issue of needing a nightly version of rustc because one of my dependencies (PyO3) relied on one of these features. It would be awesome to have some periodic updates from the compiler team on the pr…
Technically speaking, those are implemented, just not stabilized, if you’re using them in the nightly, they’re just disabled in stable. So I would anticipate they will eventually stabilize like many other features have and become part of stable.
I hope Rust adds the major anticipated features (GATs, const generics, specialization) soon, or alternatively decides to not implement them altogether. I'm a rather new Rust developer, but still I very quickly ran into the issue of needing a nightly version of rustc because one of my dependencies (PyO3) relied on one of these features. It would be awesome to have some periodic updates from the compiler team on the pr…
Technically speaking, those are implemented, just not stabilized, if you’re using them in the nightly, they’re just disabled in stable. So I would anticipate they will eventually stabilize like many other features have and become part of stable.
Earlier quoted context omitted.
Is there a meaningful help that a Rust beginner can provide here?
Many tickets are scored with a difficulty, and sometimes comes with a mentor: https://github.com/rust-lang/rust/labels?q=E- I think there are meaningful things a beginner can do. I'd be surprised if improving error messages would be terribly hard. And working on the small issues will help you become familiar enough to help with the bigger things. Edit: Also perhaps a way to get some exposure to the rust compiler is t…
Earlier quoted context omitted.
(Stuff that’s deprecated in the standard library is stuff we’re stuck with; they cannot be removed in editions.)
Could a lint check for them and warn if some code uses them? This way slowly the ecosystem could move and stuff could be eventually removed.
> could be eventually removed.
It can not be used according to our stability policy. There's a lot of closed source Rust out there.
Earlier quoted context omitted.
Rust is barely a moving target since 1.0. If you only read the version releases it might seem so, but for the pragmatic programmer not much is changing. Many of the changes concern very special features that only a few libraries make use of. As a library user you don't need to learn them. I learned Rust a few years ago and without keeping up with the latest changes too much I still feel confident I can work on curren…
Having these "very special features" means that there are some things with are added to the language but rarely used. That means that you might come across code in a library that you don't understand, especially if you're not using those features in your own code. So, I think the argument that "very special features" shouldn't be counted toward language complexity/growth is wrong, IMO. I would even say that there nee…
- sugar for quality of life improvements that benefits everyone (like ? or NLL)
- new feature that lets you do something that couldn't be done before (like impl Trait or global allocators)
- new feature that removes a special case of the semantics that can be extrapolated from already present features (like associated consts and subslice patterns)
Earlier quoted context omitted.
Could a lint check for them and warn if some code uses them? This way slowly the ecosystem could move and stuff could be eventually removed.
If you use something that's deprecated, you get a warning, yes. > could be eventually removed. It can not be used according to our stability policy. There's a lot of closed source Rust out there.
But this is just talk at the moment. Currently there is no mechanism to implement this. It would also be a challenge for documentation.
Earlier quoted context omitted.
Having these "very special features" means that there are some things with are added to the language but rarely used. That means that you might come across code in a library that you don't understand, especially if you're not using those features in your own code. So, I think the argument that "very special features" shouldn't be counted toward language complexity/growth is wrong, IMO. I would even say that there nee…
I'd say having special features is ok, as long as these criteria are met: 1) It's obvious the feature is being used. 2) The feature is easy to look up without knowing what it's called, just based on how it's been used. 3) It's easy to understand what the feature actually does, with the appropriate context.