Re: [go-nuts] Language idea: Improved support for method-like functions

2022-12-20 Thread 'Axel Wagner' via golang-nuts 
On Tue, Dec 20, 2022 at 6:05 PM Red Daly  wrote:

> Thanks for the links. Note that while 56283 was declined citing lack of
> emoji support
> , a
> comment in issue 49085
>  has 35
> thumbs up and no thumbs down for essentially the same proposal.
>

I don't think the two are the same proposal. They have overlap, but they
differ significantly. For example, the comment you link suggests that they
should still be *methods* and thus inherently namespaced differently, while
UFCS is about making *functions* callable using method syntax.
Both come with their own unique set of disadvantages and IMO UFCS has a
significantly worse tradeoff.

That being said, we don't know how to implement parameterized methods
either, so the point seems moot.


>
> I suppose it makes sense to decide on this at the same time as deciding
> whether/how to support type parameters for methods.
>
>
>>
>>
>>>
>>> This feature would be useful for defining these pseudo-methods on types
>>> within a package or on types from other packages. Using a pseudo-receiver
>>> type that's defined in another package raises some questions about how to
>>> use the pseudo-method without surprising/confusing readers. Most
>>> prominently for writing method-like generic functions.
>>>
>>> --
>>> 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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%40googlegroups.com
>>> 
>>> .
>>>
>>

-- 
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/CAEkBMfHSn7RtgcFP70QTP%2BpjVgYd955kzUrBDjRXTgV06Ktnpw%40mail.gmail.com.

Re: [go-nuts] Language idea: Improved support for method-like functions

2022-12-20 Thread Red Daly 
On Mon, Dec 19, 2022 at 12:25 PM Axel Wagner 
wrote:

>
>
> On Mon, Dec 19, 2022 at 8:31 PM Red Daly  wrote:
>
>> Methods cannot take type arguments, so I find myself writing `func Foo(o
>> Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs
>> a type parameter.
>>
>> I would like some type of pseudo-method in Go similar to Kotlin's
>> extension methods. Made up syntax:
>>
>> ```go
>> package foo
>>
>> func (o Object) #Foo[T any]() { /* ... */ } // Foo is a pseudo method of
>> Object
>>
>> func main() {
>>   obj := Object{}
>>   obj#Foo() // use # to differentiate from regular methods, or use .
>> }
>> ```
>> or something more clever.
>>
>> I expect a lot of the time people use methods for syntactic reasons, not
>> so those methods can be used to implement an interface. Methods appear in
>> godoc along with the type, get better tab completion than functions, etc.
>> I'm not proposing these pseudo-methods be used in any way to implement
>> interfaces.
>>
>> This may have already been discussed. There have been rejected proposals
>> for adding methods to types defined elsewhere (
>> https://github.com/golang/go/issues/37742 and
>> https://github.com/golang/go/issues/21401). However, I can't find a
>> proposal that proposes the Kotlin approach to "extension methods," which is
>> largely syntax sugar that allows `fun koo(k Kobject): void` to be called
>> like `k.koo()` by the programmer (rather than `koo(k)`) so long as `koo` is
>> statically resolved where such `k.koo` calls appear. Is there such a
>> proposal?
>>
>
> There are (at least) two:
> https://github.com/golang/go/issues/56283
> https://github.com/golang/go/issues/56242
> It's not *exactly* what you describe, but I believe it's close enough.
>

Thanks for the links. Note that while 56283 was declined citing lack of
emoji support
, a
comment in issue 49085
 has 35
thumbs up and no thumbs down for essentially the same proposal.

I suppose it makes sense to decide on this at the same time as deciding
whether/how to support type parameters for methods.


>
>
>>
>> This feature would be useful for defining these pseudo-methods on types
>> within a package or on types from other packages. Using a pseudo-receiver
>> type that's defined in another package raises some questions about how to
>> use the pseudo-method without surprising/confusing readers. Most
>> prominently for writing method-like generic functions.
>>
>> --
>> 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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CA%2BjYSA__GwbLrUhhub47Bo2CT7txcVQ%3DryQC62J274WU4s%2B6Hg%40mail.gmail.com.

Re: [go-nuts] Language idea: Improved support for method-like functions

2022-12-19 Thread 'Axel Wagner' via golang-nuts 
On Mon, Dec 19, 2022 at 8:31 PM Red Daly  wrote:

> Methods cannot take type arguments, so I find myself writing `func Foo(o
> Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs
> a type parameter.
>
> I would like some type of pseudo-method in Go similar to Kotlin's
> extension methods. Made up syntax:
>
> ```go
> package foo
>
> func (o Object) #Foo[T any]() { /* ... */ } // Foo is a pseudo method of
> Object
>
> func main() {
>   obj := Object{}
>   obj#Foo() // use # to differentiate from regular methods, or use .
> }
> ```
> or something more clever.
>
> I expect a lot of the time people use methods for syntactic reasons, not
> so those methods can be used to implement an interface. Methods appear in
> godoc along with the type, get better tab completion than functions, etc.
> I'm not proposing these pseudo-methods be used in any way to implement
> interfaces.
>
> This may have already been discussed. There have been rejected proposals
> for adding methods to types defined elsewhere (
> https://github.com/golang/go/issues/37742 and
> https://github.com/golang/go/issues/21401). However, I can't find a
> proposal that proposes the Kotlin approach to "extension methods," which is
> largely syntax sugar that allows `fun koo(k Kobject): void` to be called
> like `k.koo()` by the programmer (rather than `koo(k)`) so long as `koo` is
> statically resolved where such `k.koo` calls appear. Is there such a
> proposal?
>

There are (at least) two:
https://github.com/golang/go/issues/56283
https://github.com/golang/go/issues/56242
It's not *exactly* what you describe, but I believe it's close enough.


>
> This feature would be useful for defining these pseudo-methods on types
> within a package or on types from other packages. Using a pseudo-receiver
> type that's defined in another package raises some questions about how to
> use the pseudo-method without surprising/confusing readers. Most
> prominently for writing method-like generic functions.
>
> --
> 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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfHnj_xWRw_qsii3V0Sdqq3_%3DoZxzXxxkH5BzZKwjXMPDw%40mail.gmail.com.

[go-nuts] Language idea: Improved support for method-like functions

2022-12-19 Thread Red Daly 
Methods cannot take type arguments, so I find myself writing `func Foo(o 
Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs 
a type parameter.

I would like some type of pseudo-method in Go similar to Kotlin's extension 
methods. Made up syntax:

```go
package foo

func (o Object) #Foo[T any]() { /* ... */ } // Foo is a pseudo method of 
Object

func main() {
  obj := Object{}
  obj#Foo() // use # to differentiate from regular methods, or use .
}
```
or something more clever.

I expect a lot of the time people use methods for syntactic reasons, not so 
those methods can be used to implement an interface. Methods appear in 
godoc along with the type, get better tab completion than functions, etc. 
I'm not proposing these pseudo-methods be used in any way to implement 
interfaces.

This may have already been discussed. There have been rejected proposals 
for adding methods to types defined elsewhere 
(https://github.com/golang/go/issues/37742 
and https://github.com/golang/go/issues/21401). However, I can't find a 
proposal that proposes the Kotlin approach to "extension methods," which is 
largely syntax sugar that allows `fun koo(k Kobject): void` to be called 
like `k.koo()` by the programmer (rather than `koo(k)`) so long as `koo` is 
statically resolved where such `k.koo` calls appear. Is there such a 
proposal?

This feature would be useful for defining these pseudo-methods on types 
within a package or on types from other packages. Using a pseudo-receiver 
type that's defined in another package raises some questions about how to 
use the pseudo-method without surprising/confusing readers. Most 
prominently for writing method-like generic functions.

-- 
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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%40googlegroups.com.