The reason `os.Open` has not changed is because it doesn't have to change. None of the features you mention really make sense for what it does. At least that would be my interpretation. If you want to support your interpretation, I would suggest digging up proposals to add those features which got rejected because we didn't want to add more functions. That would show that a lack of keyword arguments is to blame for a lack of `os.Open` evolution, instead of a lack of need for evolution.
On the other hand, `net.Dial` empirically shows that it *is* possible to use this approach to not add more functions, while expanding functionality. Pre Go 1.0 there was only net.Dial. For Go 1.0, we determined that we would want to be able to specify timeouts, so we added net.DialTimeout <https://go.dev/doc/go1#net>. Then, for Go 1.1, we also wanted to specify a local address to use. However, it became clear that it is not sustainable to add more and more versions of a `Dial` function, so net.Dialer was added in Go 1.1 <https://pkg.go.dev/net@go1.1#Dialer>. Since then, we have added many more options to it <https://pkg.go.dev/net#Dialer>. As adding fields to a struct is backwards-compatible, we can add as many options as we like, while still maintaining compatibility and not adding new package-scoped API surface or functions. The actual history of `net.Dial` strongly implies that if we *wanted* to evolve `os.Open`, then what we would do is add a new struct type `os.Opener`, with fields for all these optional features, which would then have an `func (*Opener) Open(name string) (*File, error)` method. It's not a perfect mechanism, but so far, it seems to have sufficed. To be clear, if you feel strongly that we should support keyword arguments, you can write and file a proposal to that effect. All I can say is that in the past, this has come up repeatedly, but obviously has not been accepted. So your case should better be strong - and in particular, it should acknowledge the evidence and history we've built in over a decade. And you might ultimately save yourself some frustration by instead adopting the imperfect solutions we do have. On Thu, Aug 17, 2023 at 7:32 AM Jon Perryman <jon.perry...@gmail.com> wrote: > The net.dialer solution you mention uses a struct which does not simplify. > How does this get programmers out of the add another function mentality? > GOLANG and C/C++ programmers have the same solution because it's not > convenient to use a struct. Compare charts in C++ versus JavaScript. C++ > solution chose to implement 1,000 functions instead of using the struct as > you suggest. JavaScript looked to the future and implemented it using the > method that I'm proposing for GOLANG. The method I'm suggesting is so easy > and convenient that people use it as seen with chartjs. > > Ask yourself why os.open() has remained unchanged since the beginning > instead of expanding to include new features. Adding new features is > extremely inconvenient. Using a struct is inconvenient. Let's just add > more functions. > > On Wed, Aug 16, 2023 at 9:14 PM Axel Wagner <axel.wagner...@googlemail.com> > wrote: > >> Have a look at net.Dialer <https://pkg.go.dev/net#Dialer>. It is >> essentially a struct that adds optional, keyword arguments to net.Dial >> <https://pkg.go.dev/net#Dial>. >> >> On Thu, Aug 17, 2023 at 3:44 AM Jon Perryman <jon.perry...@gmail.com> >> wrote: >> >>> Struct does not solve the basic problem. In what way are you suggesting >>> to solve the described os.open() changes? Should each API be seperate from >>> os.open where it must be used with every read/write? >>> >>> On Wed, Aug 16, 2023 at 6:14 PM Kurtis Rader <kra...@skepticism.us> >>> wrote: >>> >>>> Personally, and I say this as a happy user of Python, I dislike keyword >>>> parameters. Note that in Python keyword parameters are (or should be) >>>> seldom used for anything other than optional arguments. And if your API has >>>> so many parameters that they need names the API probably needs refactoring. >>>> Alternatively, pass a struct whose contents can be initialized using the >>>> struct member names. >>>> >>>> On Wed, Aug 16, 2023 at 6:04 PM Jon Perryman <jon.perry...@gmail.com> >>>> wrote: >>>> >>>>> Do you feel your GOLANG API implementations allows your API's >>>>> and functions to evolve and grow? Personally, positional args has pissed >>>>> me >>>>> off for years when a proven simple solution has never been adopted by most >>>>> Unix programming languages (except Javascript). Most notably, it's missing >>>>> from GOLANG. >>>>> >>>>> Everyone here understands and uses os.open from the os package. For >>>>> argument's sake, let's say os.open() is your responsibility to integrate >>>>> nosql, memory files, compression, encryption, btree, key indexed files and >>>>> more. How do you modify os.open( ) to integrate these file related >>>>> features? This was solved years ago in languages not used in Unix >>>>> using keyword arguments that also included positional. For example: >>>>> >>>>> func os.open(name string, memoryfile= bool, compress= bool, btree{ >>>>> btree_optons string }, encrypt{ key= string }, nosql{ nosql_options string >>>>> } ) (*File, error) >>>>> os.open('myfile.txt', encrypt{ key='abc' }, compress=true) >>>>> >>>>> The os.open args 1, 3 and 5 would be set from the specified arguments. >>>>> >>>>> Is this something that others need and I should pursue or should I >>>>> just forget it? Proposal https://github.com/golang/go/issues/62078 >>>>> was closed with "I don't see anything concrete being proposed here.". >>>>> If I should pursue this, should I reword it or reduce it to this Email? >>>>> >>>>> Thanks, Jon. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "golang-nuts" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to golang-nuts+unsubscr...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/CAByJhJnkuai27VNiE6PraU9-5hoO85Hm__0UQJrT75a7KqD8uw%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/golang-nuts/CAByJhJnkuai27VNiE6PraU9-5hoO85Hm__0UQJrT75a7KqD8uw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Kurtis Rader >>>> Caretaker of the exceptional canines Junior and Hank >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAByJhJnTVs-gkQqnFtQ-kvJ%2Bqhnehij13hDh7yv4AoAXuxvKLg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/golang-nuts/CAByJhJnTVs-gkQqnFtQ-kvJ%2Bqhnehij13hDh7yv4AoAXuxvKLg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEp0G%2BT0hNos00%3DaVCGLmspJr3ZD_bRCq_ybmPz1K-NQg%40mail.gmail.com.
