Skip to content
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

Closed
wants to merge 3 commits into from
Closed

Convenience syntax for module imports #108

wants to merge 3 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Jun 6, 2014

@zr40
Copy link

zr40 commented Jun 6, 2014

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.

@ghost
Copy link
Author

ghost commented Jun 6, 2014

Syntax highlighting for the self keyword would make it look a bit different from all the other items listed. And the guarantee that it must be listed as the first item makes it easier to find it if it's there.

@dhardy
Copy link
Contributor

dhardy commented Jun 6, 2014

I like it. At the moment I have this rather clunky include pattern in one module:

use std::io;
use std::io::{IoResult,BufferedReader};
use std::io::fs::{File};

How about going further and allowing the following?

use std::io::{self, fs::File, IoResult,BufferedReader};

@gsingh93
Copy link

gsingh93 commented Jun 6, 2014

I like it. I think @dhardy's idea is going a bit too far though.

@mcpherrinm
Copy link

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.

@emberian
Copy link
Member

emberian commented Jun 9, 2014

This can be delayed until after 1.0, but this is an important ergonomic issue IMO. I have also wanted what @dhardy proposes.

@nikomatsakis
Copy link
Contributor

+1 I've been wanting to suggest this for a long time.

@thehydroimpulse
Copy link

+1

@bjadamson
Copy link

+1 for sure!

@ftxqxd
Copy link
Contributor

ftxqxd commented Jun 15, 2014

+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.

@ghost
Copy link
Author

ghost commented Jun 15, 2014

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.

@ftxqxd
Copy link
Contributor

ftxqxd commented Jun 15, 2014

@tommit Or, module imports could use mod:

use core::{
    mod,
    slice::{mod, Items},
    fmt::{
        Show,
        Formatter,
        FormatError,
    },
    iter::{Iterator, FlatMap},
    mem::*,
};
use mod::foobar;

@ghost
Copy link
Author

ghost commented Jun 17, 2014

@P1start Do you mean that the module-scope self (that refers to the encompassing module) would be then also renamed to mod?

@ftxqxd
Copy link
Contributor

ftxqxd commented Jun 17, 2014

@tommit Yes—to be honest, I still prefer using self for everything, but using mod instead of self could make the import tree better represent a file system.

@ghost
Copy link
Author

ghost commented Jun 18, 2014

Well, I made a proposal to rename mod.rs files to self.rs: RFC #128

@ghost ghost mentioned this pull request Jun 23, 2014
@alexchandel
Copy link

@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 mod.rs to self.rs might be a poor choice.

@nrc
Copy link
Member

nrc commented Jul 16, 2014

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 mod to using self since self is heavily overloaded already, can be bound as an identifier as well as a keyword, and would have different meanings in a use item depending on if it occurred at the start of the path or in braces at the end of the path.

Modified PR coming up

nrc added a commit to nrc/rfcs that referenced this pull request Jul 16, 2014
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.
nrc added a commit to nrc/rfcs that referenced this pull request Jul 16, 2014
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.
@alexcrichton
Copy link
Member

Closing in favor of #168 (updated by @nick29581)

glaebhoerl pushed a commit to glaebhoerl/rfcs that referenced this pull request Aug 8, 2014
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.
@ftxqxd ftxqxd mentioned this pull request Dec 19, 2014
withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.