-
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
Convenience syntax for module imports #108
Conversation
This syntax would make it less obvious that the module itself is being imported. Importing the module itself would be done inside the list of imported items, making it look just like any other imported item. |
Syntax highlighting for the |
I like it. At the moment I have this rather clunky include pattern in one module:
How about going further and allowing the following?
|
I like it. I think @dhardy's idea is going a bit too far though. |
The example @dhardy posted of using a path like fs::File inside { } in a use statement seems fairly unobjectionable, but is otherwise fairly seperate from what is proposed here. I'm in favour of both, though. |
This can be delayed until after 1.0, but this is an important ergonomic issue IMO. I have also wanted what @dhardy proposes. |
+1 I've been wanting to suggest this for a long time. |
+1 |
+1 for sure! |
+1 Extending on @dhardy’s idea: use core::{
self,
slice::{self, Items},
fmt::{
Show,
Formatter,
FormatError,
},
iter::{Iterator, FlatMap},
mem::*,
}; Hmm. Maybe that’s going a bit too far, but it’s not actually too aesthetically displeasing, and it displays the imports as a tree in such a way that it actually is possibly easier to read. It also removes a lot of code duplication. |
That import tree reminded me of the file system, and then it occurred to me that the mod.rs files could have also been named self.rs. |
@tommit Or, module imports could use use core::{
mod,
slice::{mod, Items},
fmt::{
Show,
Formatter,
FormatError,
},
iter::{Iterator, FlatMap},
mem::*,
};
use mod::foobar; |
@P1start Do you mean that the module-scope |
@tommit Yes—to be honest, I still prefer using |
Well, I made a proposal to rename mod.rs files to self.rs: RFC #128 |
@P1start The module hierarchy is decoupled from the actual filesystem layout by design. The syntax proposed in here is very convenient, but I think renaming |
This was discussed in the meeting today (https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-07-15.md) and we decided to accept this RFC. However, we prefer using Modified PR coming up |
Use the `mod` keyword in a module list to make the use section more concise. Originally submitted as RFC PR rust-lang#108 by @tommit.
Use the `mod` keyword in a module list to make the use section more concise. Originally submitted as RFC PR rust-lang#108 by @tommit.
Closing in favor of #168 (updated by @nick29581) |
Use the `mod` keyword in a module list to make the use section more concise. Originally submitted as RFC PR rust-lang#108 by @tommit.
That is: type Poll<T, E> = Result<Async<T>, E> enum Async<T> { Ready(T), NotReady, } This commit tweaks the return type of the `Future::poll` method to be more `try!`-friendly and also more amenable to `if let` for matching against readiness. Additionally, `Async` is used instead of `Option` to be more clear about what's actually happening, and it's also theoretically more extensible in the future if need be. Finally, the `try_poll!` macro has been removed while a new `try_ready!` macro has been added. This new macro has *different semantics* as it propagates both `NotReady` *and* errors to the caller. It only returns the `Async::Ready` variant. Closes rust-lang#108
Rendered view