Should the associated function options become a common API convention?

[Enet4]

The function File::options was stabilized in Rust 1.58 (rust-lang/rust#65439). The arguments given for this function to exist is that it's syntactic sugar for OpenOptions::new() that does not require importing OpenOptions.

rust-lang/rust#65439 (comment)

it's just sugar to avoid having to import OpenOptions on its own. You could also argue that semantically it makes sense to tie OpenOptions explicitly to File since it's effectively a fancy builder for it. IMO it makes the code more readable on top of adding a small convenience when writing it.

This raises the question: for other builder types of the FooOptions form, should it become idiomatic for Rust code to also add an associated function Foo::options() that is equivalent in behavior as FooOptions::new(), and how would it be encoded as a guideline? This does not appear to be something ubiquitous at this time, but the introduction of this pattern in std creates a precedent.

[BurntSushi]

"options" is a somewhat idiosyncratic name for what it is: a builder. For types Foo and FooBuilder, yes, I think it is nice to have a Foo::builder method. I personally plan to add such a thing to most or all of my crates, but just haven't actually done it yet.

[Stargateur]

I argue a trait could be useful on this matter:

trait Builder {
    type Builder;
    fn builder() -> Self::Builder;
}

It's very simple and some could say it's useless, but it's allow documentation easy thing and set a more clear convention.

I'm opposed to use options() name, most codebase use builder() and even builder macro crates use builder() by default https://lib.rs/crates/typed-builder