refactor lvalue_ty to be method of lvalue #35403
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
|
Do you think it makes sense to refactor similarly the other |
|
Also, I think I would prefer to keep the |
|
@bors r+ why not. |
|
📌 Commit f37bf6d has been approved by |
bors
added a commit
that referenced
this pull request
Aug 11, 2016
refactor lvalue_ty to be method of lvalue Currently `Mir` (and `MirContext`) implement a method `lvalue_ty` (and actually many more `foo_ty`). But this should be a method of `Lvalue`. If you have an `lvalue` and you want to get its type, the natural thing to write is: ``` lvalue.ty() ``` Of course it needs context, but still: ``` lvalue.ty(mir, tcx) ``` Makes more sense than ``` mir.lvalue_ty(lvalue, tcx) ``` I actually think we should go a step farther and have traits so we could get the type of some value generically, but that's up for debate. The thing I'm running into a lot in the compiler is I have a value of type `Foo` and I know that there is some related type `Bar` which I can get through some combination of method calls, but it's often not as direct as I would imagine. Unless you already know the code, its not clear why you would look in `Mir` for a method to get the type of an `Lvalue`.
This was referenced Aug 11, 2016
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently
Mir(andMirContext) implement a methodlvalue_ty(and actually many morefoo_ty). But this should be a method ofLvalue.If you have an
lvalueand you want to get its type, the natural thing to write is:Of course it needs context, but still:
Makes more sense than
I actually think we should go a step farther and have traits so we could get the type of some value generically, but that's up for debate. The thing I'm running into a lot in the compiler is I have a value of type
Fooand I know that there is some related typeBarwhich I can get through some combination of method calls, but it's often not as direct as I would imagine. Unless you already know the code, its not clear why you would look inMirfor a method to get the type of anLvalue.