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

[WIP] Add {HashMap,HashSet} to std's prelude #63418

Closed
wants to merge 3 commits into from

Conversation

tesuji
Copy link
Contributor

@tesuji tesuji commented Aug 9, 2019

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 9, 2019
@@ -123,3 +123,6 @@ pub use crate::string::{String, ToString};
#[stable(feature = "rust1", since = "1.0.0")]
#[doc(no_inline)]
pub use crate::vec::Vec;
#[unstable(feature = "hashmap_prelude", issue = "0")]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@petrochenkov Does this have any effect? Probably not?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has effect on documentation.
(It will also have effect if someone bothers to move stability checking to its proper place - resolve.)

@Centril Centril added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Aug 9, 2019
@rust-highfive

This comment has been minimized.

src/test/ui/derived-errors/issue-31997-1.stderr Outdated Show resolved Hide resolved
src/test/ui/error-codes/E0433.stderr Outdated Show resolved Hide resolved
src/test/ui/resolve/use_suggestion_placement.stderr Outdated Show resolved Hide resolved
@tesuji tesuji force-pushed the hashmap-prelude branch 2 times, most recently from f1cb215 to b46f828 Compare August 10, 2019 05:02
@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@tesuji
Copy link
Contributor Author

tesuji commented Aug 10, 2019

I cannot run the full test suite with x.py in local machine because of #63436.

// The file so far is equivalent to src/libcore/prelude/v1.rs,
// and below to src/liballoc/prelude.rs.
// The file so far is equivalent to `src/libcore/prelude/v1.rs`,
// and below to `src/liballoc/prelude/v1.rs` (except `HashMap`).
// Those files are duplicated rather than using glob imports
// because we want docs to show these re-exports as pointing to within `std`.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I remove these comments or not? @RalfJung

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, no idea. I just observed an inconsistency.

@RalfJung
Copy link
Member

I cannot run the full test suite with x.py in local machine because of #63436.

I hardly ever run more than ./x.py test src/test/ui --pass check, then I let the PR CI point me to what else might be problematic. Things just take too long.^^

@steveklabnik
Copy link
Member

I don't personally think HashMap is used often enough to deserve a spot in the prelude.

@Centril
Copy link
Contributor

Centril commented Aug 13, 2019

IMO we should rethink the prelude and not have it be so limited. I think the bar set by:

It's kept as small as possible, and is focused on things, particularly traits, which are used in almost every single Rust program.

is just too high. For example, I do not think that ToOwned meets that bar.

@steveklabnik
Copy link
Member

I think that messing with something so important, and that affects imports to every single program, is something to be done with extreme care.

Copy link
Member

@joshtriplett joshtriplett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: HashpMap should be HashMap

@joshtriplett
Copy link
Member

I'd love to see this happen.

I'm concerned about it generating warnings about redundant imports, as evidenced by the extensive test suite changes, but I don't see any reasonable way around that.

@joshtriplett
Copy link
Member

joshtriplett commented Aug 15, 2019

Could you please rebase the series and squash some patches together to avoid fixing bugs introduced by the same series? For instance, you have several commits making the same kind of change to tests, and you have a commit changing a test incorrectly followed by a commit fixing the test correctly.

@joshtriplett
Copy link
Member

We discussed this in the lang team meeting, and we developed a consensus that the lang team wants to defer decisions about the content of the prelude to the libs team, unless the libs team specifically wants to consult the lang team (such as for issues of coherence or alignment with new language features). As such, un-tagging the lang team.

@joshtriplett joshtriplett removed I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Aug 15, 2019
@joshtriplett
Copy link
Member

Now, taking my lang team hat off and speaking only for myself:

Yes, please, I'd love to see HashMap in the prelude. I'd also like to see a few other things added to the prelude that people commonly use.

We'll need to take some care about traits, but types should not cause issues to introduce.

@ssokolow
Copy link

For example, I do not think that ToOwned meets that bar.

I always use it when going from &str to String because it best communicates the purpose of the conversion to anyone else reading the code.

@RalfJung
Copy link
Member

I always use it when going from &str to String because it best communicates the purpose of the conversion to anyone else reading the code.

I've been bitten by that quite badly when, for some reason, I ended up with an &&str. Then to_owned turns that into an &str.
Since then, I am using .to_string(), and for literals sometimes format!.

@ssokolow
Copy link

ssokolow commented Aug 16, 2019

I'm having trouble imagining a situation where I'd use .to_owned(), that might happen, and the type system wouldn't catch it.

(If the borrow checker is happy with a reference, then why would I be calling .to_owned() in the first place?)

...and, in that case, I'd say that it's a good thing for the same reason that I don't want string+integer concatenation doing automatic type conversion.

As far as I'm concerned, if .to_string() or format! let an unexpected && Just Work™, then it's a design flaw because I want to catch, understand, and make an explicit decision about that unexpected &&.

@RalfJung
Copy link
Member

I disagree, I think if what I want is a string I should express that -- "to owned" doesn't convey enough information about what we own then. This is related to accidentally cloning a shared reference instead of what it points to. But I'll stop digressing here now. ;)

@ssokolow
Copy link

ssokolow commented Aug 16, 2019

Fair enough. I won't keep things off-topic either but I will say that I hadn't considered shared references.

(I'm still used to choosing project ideas where Rust is just serving as a more maintainable alternative to Python and, given Python's Global Interpreter Lock, that means I don't do much parallel stuff.)

@chris-morgan
Copy link
Member

Quite apart from the question of what items are in the prelude: I had understood that if items were added to the prelude in future, they’d be in a different module than v1. Otherwise I’m not particularly sure what the purpose of the v1 bit would be.

* Fix `HashMap` redundantly import errors
* Replace HashMap by BTreeMap in tests suggested by Jonas
@JohnCSimon
Copy link
Member

Ping from triage
@Centril @lzutao Hi, this has sat idle for over a week, can you post the status on this?
thank you

@Centril Centril added I-nominated S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 24, 2019
@Centril
Copy link
Contributor

Centril commented Aug 24, 2019

r? @alexcrichton

@tesuji tesuji changed the title [WIP] Add HashMap to std's prelude [WIP] Add HashMap, HashSet to std's prelude Aug 24, 2019
@tesuji tesuji changed the title [WIP] Add HashMap, HashSet to std's prelude [WIP] Add {HashMap,HashSet} to std's prelude Aug 24, 2019
@alexcrichton
Copy link
Member

Thanks for the PR! I'm a bit lost reading this PR though. None of the description, the commits, or the discussion thread seem to discuss the motivation here for why HashMap should be added to the prelude at this time. Additionally modifying the prelude is such an important operation that we currently require an accepted RFC to land it. I don't think that's happened though?

@bors
Copy link
Contributor

bors commented Sep 1, 2019

☔ The latest upstream changes (presumably #63870) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

I'm going to close this because this change needs an accepted RFC which hasn't happened, but feel free to ping if assistance is needed in writing an RFC!

@tesuji tesuji deleted the hashmap-prelude branch May 20, 2024 00:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.