Rename File::with_options to builder #76744
Conversation
rust-highfive
added
the
S-waiting-on-review
|
Wow, there are some people using File::with_options: https://github.com/search?l=Rust&q=%22File%3A%3Awith_options%22&type=Code . Gonna open an stabilizing PR after this. |
|
seems like Ashley is busy, gonna ping other T-libs member: r? @dtolnay |
jyn514
added
the
T-libs-api
| @@ -358,32 +358,26 @@ impl File { | |||
| OpenOptions::new().write(true).create(true).truncate(true).open(path.as_ref()) | |||
| } | |||
|
|
|||
| /// Returns a new OpenOptions object. | |||
| /// Returns a builder struct to configure how a file is opened. | |||
There was a problem hiding this comment.
It is not a builder struct but OpenOptions struct.
| /// Returns a builder struct to configure how a file is opened. | |
| /// Configure how to open a file with `OpenOptions`. |
There was a problem hiding this comment.
OpenOptions struct is a builder struct. I'm not sure we want to repeatedly mention
OpenOptions. I'll leave this for reviewer to decide.
| #[unstable(feature = "with_options", issue = "65439")] | ||
| pub fn with_options() -> OpenOptions { | ||
| #[unstable(feature = "file_builder", issue = "65439")] | ||
| pub fn builder() -> OpenOptions { |
There was a problem hiding this comment.
I wonder why not options?
There was a problem hiding this comment.
I guess I've never seen APIs like that. But yeah, it could be if reviewer prefers.
There was a problem hiding this comment.
Based on the informal poll in #65439, builder was the least popular name and options was the most popular (just).
There was a problem hiding this comment.
I know that. However Rust design has never been a community vote, but
it depends much on official respective teams.
(To be clear: I don't belong to any Rust teams).
There was a problem hiding this comment.
Right, just pointing it out in case whoever reviews this wasn't aware.
There was a problem hiding this comment.
Wow, I didn't even know there is a vote. I just came out with it from my mind. Good to know that we are on the same page and same taste. :D
There was a problem hiding this comment.
I think I would prefer to let this play out in the tracking issue a little further. As it stands, due to the lack of consensus I think a rename/stabilization here would require disproportionately much attention and for very little benefit, so I think it would be better for the team to prioritize other things.
So the team now prefers the community votes over team designs and decisions.
What are consensus you talking about? If you don't have strong opinion on it, you could reassign it to others. With all respects, I am really disappointed with how things done in this PR. |
|
To clarify, please don't hold a URO/reddit vote.
This is sadly just how bandwidth works. Expecting that a team would engage to raise and discuss meaningful objective points on anything someone cares about regardless of rate of PRs opened and priorities, is not realistic. |
|
It's alright for your explanation to clarify things. |
This patch implements this idea: #65439 (comment)
Java APIs often use builder pattern and name the builder function as
builder.At least we have a prio-art to follow. An arguments against
with_optionsis that it often receives arguments.