Re: [go-nuts] keyword= support for function calls

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 t

Re: [go-nuts] keyword= support for function calls

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 omissio

Re: [go-nuts] keyword= support for function calls

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 initializ

Re: [go-nuts] keyword= support for function calls

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

Re: [go-nuts] keyword= support for function calls

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

Re: [go-nuts] keyword= support for function calls

On Wed, Aug 16, 2023 at 6:44 PM Jon Perryman 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? > I guess I don't understand what you

Re: [go-nuts] keyword= support for function calls

Have a look at net.Dialer . It is essentially a struct that adds optional, keyword arguments to net.Dial . On Thu, Aug 17, 2023 at 3:44 AM Jon Perryman wrote: > Struct does not solve the basic problem. In what way are you suggesting to

Re: [go-nuts] keyword= support for function calls

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 wrote: > Personally, and I say this as a happy user

Re: [go-nuts] keyword= support for function calls

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. Alter

[go-nuts] keyword= support for function calls

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