Add true properties #13299
Comments
|
At least it is an RFC material, and a feature that can be added to the language later without breaking existing programs. (There are several features that should be discussed before 1.0 for this reason, but properties are not.) |
|
Closing, this is a language change which needs to go through the RFC process (as @lifthrasiir mentioned) |
matthiaskrgr
pushed a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 11, 2022
…Veykril fix: infer for-loop item type with `IntoIterator` and `Iterator` Part of rust-lang#13299 We've been inferring the type of the yielded values in for-loop as `<T as IntoIterator>::Item`. We infer the correct type most of the time when we normalize the projection type, but it turns out not always. We should infer the type as `<<T as IntoIterator>::IntoIter as Iterator>::Item`. When one specifies `IntoIter` assoc type of `IntoIterator` but not `Item` in generic bounds, we fail to normalize `<T as IntoIterator>::Item` (even though `IntoIter` is defined like so: `type IntoIter: Iterator<Item = Self::Item>` - rustc does *not* normalize projections based on other projection's bound I believe; see [this playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e88e19385094cb98fadbf647b4c2082e)). Note that this doesn't fully fix # 13299 - given the following code, chalk can normalize `<I as IntoIterator>::IntoIter` to `S`, but cannot normalize `<S as Iterator>::Item` to `i32`. ```rust struct S; impl Iterator for S { type Item = i32; /* ... */ } fn f<I: IntoIterator<IntoIter = S>>(it: I) { for elem in it {} //^^^^{unknown} } ``` This is because chalk finds multiple answers that satisfy the query `AliasEq(<S as Iterator>::Item = ?X`: `?X = i32` and `?X = <I as IntoIterator>::Item` - which are supposed to be the same type due to the aforementioned bound on `IntoIter` but chalk is unable to figure it out.
Jarcho
pushed a commit
to Jarcho/rust
that referenced
this issue
Aug 24, 2024
…on, r=Alexendoo Fix suggestion unnecessary_lazy_eval As mentioned at rust-lang#13293 improve suggestion via span_suggestion_verbose changelog: none
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I believe that Rust would benefit greatly by adding true properties. An old rust-dev thread on getters and setters defended the lack of such by saying that Haskell and ML are fine without them. I think that this defense might be misleading, and I still believe that it would be worth it for Rust to have properties.
Haskell does not have properties because it is a functional language, but it does require the use of functions to access the individual fields of a type. It has the record syntax to generate these accessors for you in order to cut down on boilerplate. As far as I know, Rust lacks the equivalent of even this. Haskell also has lenses to make this even easier.
It is important that Rust distinguish itself from the tried-and-true C and C++ languages by eliminating boilerplate/generated code. My worry is that developers simply won't see much advantage in learning a new language otherwise. I believe that if an equivalent of Scala's unapply method is necessary to keep pattern matching working correctly, it would be worth it.
The text was updated successfully, but these errors were encountered: