-
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
RFC: enforce module directory structure more strictly #63
RFC: enforce module directory structure more strictly #63
Conversation
@nikomatsakis has a more general idea on how to fix the common problems here. He should probably weigh in (or Niko: if you prefer, I can write an RFC for your proposal). |
times, leading to surprising incompatibility between them. This proposal does | ||
not take away one's ability to shoot oneself in the foot should one really | ||
desire to; it just removes almost all of the rope, leaving only mixed | ||
metaphors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahhahahahah :D
@pnkfelix this is basically the "opinionated" version of what I wanted to do. The less opinionated version would support either the mod.rs or else a pattern where the main module is "foo.rs" and submodules are "foo/bar.rs"
The lenient and strict version are basically the same, except for the behaviour when the current file name is not mod.rs. In that case, the lenient version would, given a declaration |
More choices in things like this are bad. |
This seems reasonable to me at first glance. |
I also think this seems like a reasonable solution to a common problem. |
i prefer @nikomatsakis 's generalized form, but I would not object to accepting this RFC, especially since I believe it to be forward-compatible with niko's generalization. |
@chris-morgan I took the liberty of updating the title to be more precise and formal. Feel free to update it again if you don't think it correctly reflects your proposal. |
@nikomatsakis the rename is fine. I wasn't enthralled with the name it had! As for the alternative of allowing It's much easier for a tool to correct style if there is one, and only one, way of doing something. |
+1 to more restrictions to make the module system clearer. |
Strong +1 |
We discussed this at today's meeting, and have decided to merge this. |
Just a quick note of something I've noticed since attempting to adopt the stricter style imposed here: it can yield many open buffers that are all named A good editor/IDE will distinguish them in some way, e.g by using the directory that they fall in (so that the buffers are named things like Nonetheless, the slightly looser semantic that Niko was proposing (which we could still add on top of this, I believe) would enable me to avoid ever using the same filename, which can ease switching between open buffers in some editors. |
@pnkfelix yeah, this has been mentioned a few times. I can't believe that there are editors out there that fail to make the distinction between files with the same name in distinct directories, but apparently it is true. (Hello, people, |
Another possibility is |
This commits adds a `poll_cancel` method to learn about when the `Oneshot` half of a complete/oneshot pair has gone away. This can then be used to detect when a computation is no longer wanted. Closes rust-lang#63
No description provided.