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

Conversation

Projects
None yet
@tommit
Copy link

commented Jun 6, 2014

@zr40

This comment has been minimized.

Copy link

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.

@tommit

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Jun 6, 2014

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

@mcpherrinm

This comment has been minimized.

Copy link

commented Jun 9, 2014

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.

@cmr

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2014

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

@thehydroimpulse

This comment has been minimized.

Copy link

commented Jun 13, 2014

+1

@bjadamson

This comment has been minimized.

Copy link

commented Jun 15, 2014

+1 for sure!

@P1start

This comment has been minimized.

Copy link
Contributor

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.

@tommit

This comment has been minimized.

Copy link
Author

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.

@P1start

This comment has been minimized.

Copy link
Contributor

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;
@tommit

This comment has been minimized.

Copy link
Author

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?

@P1start

This comment has been minimized.

Copy link
Contributor

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.

@tommit

This comment has been minimized.

Copy link
Author

commented Jun 18, 2014

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

@alexchandel

This comment has been minimized.

Copy link

commented Jun 26, 2014

@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

This comment has been minimized.

Copy link
Member

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

Convenience syntax for module imports (was rust-lang#108)
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

Convenience syntax for module imports (was rust-lang#108)
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

This comment has been minimized.

Copy link
Member

commented Jul 16, 2014

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

glaebhoerl added a commit to glaebhoerl/rfcs that referenced this pull request Aug 8, 2014

Convenience syntax for module imports (was rust-lang#108)
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.

@P1start P1start referenced this pull request Dec 19, 2014

Merged

RFC: `self` in `use` #532

withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017

Lift the error type out of `Poll` into a `Result`
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
You can’t perform that action at this time.