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.
On Thu, Aug 17, 2023 at 3:03 AM 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>
> .
>
--
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/CANVuwyFU-O4hfJckFtZnNGen_jZ-Dmg_fKXR90ChLogTBiFOKA%40mail.gmail.com.
