Even if we assume that the addition of keyword arguments would be a
positive for the Go language and ecosystem, it wouldn't be a backward
compatible change to add a keyword argument unless we make additional
changes to the language to support implicit conversions between
function-with-keyword types. For example, a completely valid way to use
os.Open today would be to pass it into a function as an argument:
func DoThing(open func(string) (*os.File, error)) {
f, err := open("foo.json")
// etc
}
...
DoThing(os.Open)
How does the above code work after adding a new keyword argument to
os.Open? If a new non-keyword argument was added, this would clearly be a
backward incompatible change today. How would I implement DoThing such that
I _can_ use new keyword arguments?
Any real language change needs to precisely define what happens in the
above cases, and more. So, if you're serious about such a proposal, you
need to state the exact changes you're proposing to the language
specification, the expected impact on the language implementation(s), and
have some evidence that the proposed changes are worth the effort and are
better than the alternatives.
On Thursday, August 17, 2023 at 6:13:55 AM UTC-4 Dan Kortschak wrote:
> On Thu, 2023-08-17 at 11:34 +0200, Peter Herth wrote:
> > I think the omission of keyword parameters in Go is a weakness. In
> > many cases, keyword parameters are a simple way of creating APIs,
> > which depend on a lot of possible parameters, of which most are not
> > necessarily specified. Their omission is especially ironic, as there
> > is a strong push to initialize structs only via using the keyword
> > parameter syntax. And the reasons for that are very good. So when we
> > have a nice system - which essentially is just syntactic sugar at the
> > call site - for structs, why can't we have the same system for
> > functions? Like with structs, it should be mostly a syntax for
> > calling functions. They should probably be able to specify which
> > parameters are positional and which can be specified by keyword
> > parameters.
> > Of course you can do the common "trick" via generating a struct which
> > allows the keyword syntax for creation, but I think it would be a
> > good addition to not need that indirection.
>
> A significant problem with additions like this is that people would use
> it. kwargs-rich functions enable overly complex APIs. I'm very glad Go
> doesn't have them.
>
>
--
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/90a6abfc-d878-4935-a718-193acfa9e853n%40googlegroups.com.
