-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Declarations in More Places #1976
Conversation
I like having match self.0.partial_cmp(other.0) {
None => unreachable!(),
Some(Greater) => Some(Lesser),
use Ordering::*; // 😣
Some(Less) => Some(Greater),
Some(Eq) => Some(Eq)
} |
There is a case for |
Over IRC @nagisa suggested Having it in trait also makes sense for the same reason as having it in impl. If we go the route of having it in match like as describe, it would also make sense to have it in struct (though not tuple structs) and enum as well...I'll add them to the RFC. For having |
Just fyi, I think mixing |
I would say that we should, at least for the time being, keep to just impl blocks. I don't think use in match or elsewhere is all that useful, since you can usually just put it in a block around the match (or the function which the match is in); constraining this RFC to just impl blocks seems like a good start to this. However, I don't feel strongly about this--if we can get it with everything, then perhaps that's better. I do have some concerns about this RFC running into the same problems the else match RFC ran into (scoping issues, primarily; what do we include? What makes sense? etc.). These scoping issues are certainly not as major a problem for this RFC I think since it's changes are more minimal in terms of where they can go. |
@Mark-Simulacrum its very useful in match, to not having to write the enum name in every case. |
For
the "match" expr "{" (attr* "use" paths ";")* (pat "=>" (expr "," | block))+ "}" There is no need to allow more things inside the |
It's interesting if you find a complication with adding |
I agree that there's likely no problem with adding |
Perhaps This also logically deals with the problem of mixing semicolon-terminated statements with comma-separated things. You could logically say that the comma-separated list hasn't started until after all the semicolon-terminated statements. |
It'd be nice if it was completely generalized to allow |
@pornel But I wonder if it makes sense for let foo = Foo { // <--
use std::cmp::Ordering::*;
a: Greater,
b: Less,
} (and if yes the question becomes "why not tuples as well") |
I mean from perspective of learning the language, it's easier to remember "all block-like things can start with |
There's definitely a sentiment on the lang team that over time, the body of The reason to single out The case for So, 👍 for |
I'm in favour of allowing this in impls, but not inside |
I agree with adding this to traits as well; because it's not as syntactically weird I think that we should at least group One potential conflict though is a potential conflict with #1406. |
Remove `use` in `match`. Should be as own RFC, and not willing to defend it personally. Likewise, removed parts in the how we teach and drawbacks, making those sections less "if"fy. Added `trait`, as that's analogous to `impl` and I feel stupid for not doing that initially. Added grammar changes. Not sure if they're the right changes, but at least they exist.
Alright, going by discussion, I removed the I also added a grammar section. Somebody who understands the grammar file better than I, please do so. And likewise, since traits are analogous to implementations, I added traits to it. No examples though, as I couldn't really think of a good one quickly. Not entirely sure it's needed either, as I think if you know how to use |
@clarcharr I don't think it's a conflict. The syntax they propose would give a completely new meaning to |
@Havvy fair! Although I think that it's worth mentioning in the drawbacks section that there might be a conflict between these two RFCs. |
Also @Havvy currently the rendered link is broken. |
Render link fixed. I don't consider it worth being a drawback worth writing because it's the same as any other RFC proposing syntax where it blocks off any other RFC from using the same syntax. Should the other RFC also add as a drawback that it conflicts with this one? |
Thanks @Havvy! Lang team: the proposal here is to allow @rfcbot fcp merge |
Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
SUPERSEDED BY #1976 (comment) I have some concerns.
struct S;
impl S {
fn f(&self) {}
use f as g; // or Self::f as g or something
}
S.g(); // Why doesn't it work?! This can be made to work with struct S;
trait Tr {
use S as Z;
}
let s: S = Tr::Z; // OK This may be a bit surprising, but I think it's better than introducing one more special case into the language, like this RFC does. use Default::default;
let x = default(); , but this is legitimately useful, improves consistency and can be easily fixed, so I expect this to be fixed.) The problem with In the end, I can live with |
I am inclined to agree with @petrochenkov's objections to the current RFC. It seems to me that, way back when, when we decided to make @petrochenkov's use clauses seem like an interesting way to separate those two items back out again. |
Right. The question then becomes, is it worth adding the complexity of use clauses to the language right now? I want to say "no" for now, personally. In any case, it'd effectively be its own RFC, so I'm thinking of just closing this one. |
In the past there were discussions about having |
I also fully agree with @petrochenkov's assessment here.
@phaylon: What I find problematic about that syntax is that it defines aliases as a prefix of the item syntax, so it might be more confusing to read if you bring a lot of items into scope, since it takes the code a while to "get to the point" of what these aliases are actually for. |
@Kimundi Do you mean having multiple imports? I think having multiple import targets would be a nice solution, e.g.:
Or am I misunderstanding? |
@phaylon: Basically I mean, that if you have something like this: use foo::Bar, ... in struct X { ... } Then you have to skip over the A syntax like struct X where use foo::Bar, ... { ... } has the advantage that the |
My opinion: There are many RFCs with more pressing motivation than this that were postponed. Use declarations at the module and block level suffice for the vast majority of use cases, and this change seems quite controversial, so I propose to postpone this. |
@Kimundi Ah, that is true. For me that would be outweighed by the fact that I can use it to apply imports to multiple items, and that the construct is expression compatible as-is. |
@phaylon: True. Actually I think the block form ( |
That's a pretty compelling argument; I think @petrochenkov's counter-proposal is worth keeping in mind, but we should turn our ergonomic attention elsewhere for now. @rfcbot fcp postpone |
@rfcbot fcp cancel |
@aturon proposal cancelled. |
@rfcbot fcp postpone |
Team member @aturon has proposed to postpone this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
@nikomatsakis I was interested by your comment in |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
1 similar comment
🔔 This is now entering its final comment period, as per the review above. 🔔 |
That was the "non-unified" version I was talking about. In the olden days, |
The final comment period is now complete. |
Given the lack of comments for a month, and the FCP being complete w/postpone, I'm going to close this. |
Rendered
I personally care more about
use
inimpl
than inmatch
, but don't see why we cannot really have both, other than potential syntactical ugliness.