Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

Alex those were my opinion and my thoughts, as long as they don't harm
anyone they can coexist in peace... in any case, your bluntness is pardoned
and thanks for reading me. As I said before this is a feeling and it makes
me feel good to release it, so allowing me to write this, is, at the
bottom, allowing me to express freely and I'm thankful for that.

El mar, 24 oct 2023 a las 14:51, Axel Wagner ()
escribió:

> On Tue, Oct 24, 2023 at 6:14 PM Victor Giordano 
> wrote:
>
>> TD;DR: The above is just a stream of consciousness that I release in this
>> place that I find appropriate for this purpose. Forgive me in advance.
>>
>
> I find it inappropriate, pardon my bluntness. The use cases for generics
> are well documented. We have them in Go, since three versions. Please move
> on. If you want to improve the language, accept where we are right now and
> how we can best continue from here. Instead of pretending it is still 2+
> years ago and we would still discuss whether to add them.
>
> This thread in particular is not even a significant complication of them.
> It's about a comparatively mild, potential improvement on type inference.
> It's not about improving their expressive power in any way.
>
>
>>
>> This is the thing about generics... make the world a very complex place..
>> and I do wonder... ¿ What kind of problems can be solved by generics that
>> can not be solved by interfaces?
>> If the idea is to be minimalism... ¿why do you surrender to the
>> temptation of generics?... ¿Does a language need generics to become better
>> or is human temptation in its unfilled need to write less and less that
>> invent generics...? ¿I'm the lazy one that rants for having to learn new
>> types theory?
>>
>> and After a few drinks: First Object class now interface{} struct...
>> you both have everything... generics... keep it simple please... don't
>> become Scala...
>>
>> El mar, 24 oct 2023 a las 12:49, 'Axel Wagner' via golang-nuts (<
>> golang-nuts@googlegroups.com>) escribió:
>>
>>> I think addressing this would sensibly include a rule to allow unifying
>>> two types, if one is assignable to the other (which, AIUI, we already do
>>> for directional channels).
>>>
>>> It's possible that this can be confusing in some circumstances including
>>> composite types e.g. something like
>>>
>>> func Append[T any](s []T, v ...T)
>>> func main() {
>>> var (
>>> s []any
>>> v []io.Reader
>>> )
>>> s = Append(s, v...) // would infer Append[any] and then fail to
>>> compile because []io.Reader is not assignable to []any
>>> }
>>>
>>> But I can't really come up with an example where this is worse than the
>>> status quo. Or even where something that *could* compile with fully
>>> specified instantiation then doesn't compile with inferred arguments.
>>>
>>> The situation also becomes significantly more complex if we take
>>> assignment context into account for inference. AIUI we currently don't and
>>> it is something I want.
>>>
>>> I wouldn't want to confidently state that this is something we should or
>>> should not do.
>>>
>>> On Tue, Oct 24, 2023 at 5:01 PM tapi...@gmail.com 
>>> wrote:
>>>
 My another surprise is that the below partial instantiation doesn't
 work.

 s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work
 s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works

 On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com
 wrote:

> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com
> wrote:
>
> Sorry, I didn't look your full code.
> I think the full code should work with Go toolchain 1.21.n.
>
>
> Aha, it actually doesn't. I'm surprised.
>
>
> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>
> How so?
>
> Can you give an example scenario where it could cause unintended
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
> --
 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/7bd4727b-46ec-4972-b9a3-f7271892bff5n%40googlegroups.com
 
 .

>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/golang-nuts/eD7207kM8zA/unsubscribe.
>>> To unsubscribe from 

Re: [go-nuts] Can Generics match implementers of an interface?

['Axel Wagner' via golang-nuts]

On Tue, Oct 24, 2023 at 6:14 PM Victor Giordano 
wrote:

> TD;DR: The above is just a stream of consciousness that I release in this
> place that I find appropriate for this purpose. Forgive me in advance.
>

I find it inappropriate, pardon my bluntness. The use cases for generics
are well documented. We have them in Go, since three versions. Please move
on. If you want to improve the language, accept where we are right now and
how we can best continue from here. Instead of pretending it is still 2+
years ago and we would still discuss whether to add them.

This thread in particular is not even a significant complication of them.
It's about a comparatively mild, potential improvement on type inference.
It's not about improving their expressive power in any way.


>
> This is the thing about generics... make the world a very complex place..
> and I do wonder... ¿ What kind of problems can be solved by generics that
> can not be solved by interfaces?
> If the idea is to be minimalism... ¿why do you surrender to the temptation
> of generics?... ¿Does a language need generics to become better or is human
> temptation in its unfilled need to write less and less that invent
> generics...? ¿I'm the lazy one that rants for having to learn new types
> theory?
>
> and After a few drinks: First Object class now interface{} struct...
> you both have everything... generics... keep it simple please... don't
> become Scala...
>
> El mar, 24 oct 2023 a las 12:49, 'Axel Wagner' via golang-nuts (<
> golang-nuts@googlegroups.com>) escribió:
>
>> I think addressing this would sensibly include a rule to allow unifying
>> two types, if one is assignable to the other (which, AIUI, we already do
>> for directional channels).
>>
>> It's possible that this can be confusing in some circumstances including
>> composite types e.g. something like
>>
>> func Append[T any](s []T, v ...T)
>> func main() {
>> var (
>> s []any
>> v []io.Reader
>> )
>> s = Append(s, v...) // would infer Append[any] and then fail to
>> compile because []io.Reader is not assignable to []any
>> }
>>
>> But I can't really come up with an example where this is worse than the
>> status quo. Or even where something that *could* compile with fully
>> specified instantiation then doesn't compile with inferred arguments.
>>
>> The situation also becomes significantly more complex if we take
>> assignment context into account for inference. AIUI we currently don't and
>> it is something I want.
>>
>> I wouldn't want to confidently state that this is something we should or
>> should not do.
>>
>> On Tue, Oct 24, 2023 at 5:01 PM tapi...@gmail.com 
>> wrote:
>>
>>> My another surprise is that the below partial instantiation doesn't
>>> work.
>>>
>>> s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work
>>> s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works
>>>
>>> On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com
>>> wrote:
>>>
 On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com
 wrote:

 Sorry, I didn't look your full code.
 I think the full code should work with Go toolchain 1.21.n.


 Aha, it actually doesn't. I'm surprised.


 On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:

 How so?

 Can you give an example scenario where it could cause unintended
 consequences?  Or some other negative?

 -Mike

 On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
 wrote:


 It is hard to call such type inference better. That is too aggressive.

 --
>>> 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/7bd4727b-46ec-4972-b9a3-f7271892bff5n%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/eD7207kM8zA/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAEkBMfEWgAvSqqL5mSr-Nf%2B5P%2BNkOA%2BCSbt8fi%3DRuJYKiZfYVA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> V
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" 

Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

TD;DR: The above is just a stream of consciousness that I release in this
place that I find appropriate for this purpose. Forgive me in advance.

This is the thing about generics... make the world a very complex place..
and I do wonder... ¿ What kind of problems can be solved by generics that
can not be solved by interfaces?
If the idea is to be minimalism... ¿why do you surrender to the temptation
of generics?... ¿Does a language need generics to become better or is human
temptation in its unfilled need to write less and less that invent
generics...? ¿I'm the lazy one that rants for having to learn new types
theory?

and After a few drinks: First Object class now interface{} struct...
you both have everything... generics... keep it simple please... don't
become Scala...

El mar, 24 oct 2023 a las 12:49, 'Axel Wagner' via golang-nuts (<
golang-nuts@googlegroups.com>) escribió:

> I think addressing this would sensibly include a rule to allow unifying
> two types, if one is assignable to the other (which, AIUI, we already do
> for directional channels).
>
> It's possible that this can be confusing in some circumstances including
> composite types e.g. something like
>
> func Append[T any](s []T, v ...T)
> func main() {
> var (
> s []any
> v []io.Reader
> )
> s = Append(s, v...) // would infer Append[any] and then fail to
> compile because []io.Reader is not assignable to []any
> }
>
> But I can't really come up with an example where this is worse than the
> status quo. Or even where something that *could* compile with fully
> specified instantiation then doesn't compile with inferred arguments.
>
> The situation also becomes significantly more complex if we take
> assignment context into account for inference. AIUI we currently don't and
> it is something I want.
>
> I wouldn't want to confidently state that this is something we should or
> should not do.
>
> On Tue, Oct 24, 2023 at 5:01 PM tapi...@gmail.com 
> wrote:
>
>> My another surprise is that the below partial instantiation doesn't work.
>>
>> s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work
>> s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works
>>
>> On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com wrote:
>>
>>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com
>>> wrote:
>>>
>>> Sorry, I didn't look your full code.
>>> I think the full code should work with Go toolchain 1.21.n.
>>>
>>>
>>> Aha, it actually doesn't. I'm surprised.
>>>
>>>
>>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>>
>>> How so?
>>>
>>> Can you give an example scenario where it could cause unintended
>>> consequences?  Or some other negative?
>>>
>>> -Mike
>>>
>>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
>>> wrote:
>>>
>>>
>>> It is hard to call such type inference better. That is too aggressive.
>>>
>>> --
>> 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/7bd4727b-46ec-4972-b9a3-f7271892bff5n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/eD7207kM8zA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAEkBMfEWgAvSqqL5mSr-Nf%2B5P%2BNkOA%2BCSbt8fi%3DRuJYKiZfYVA%40mail.gmail.com
> 
> .
>


-- 
V

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

Re: [go-nuts] Can Generics match implementers of an interface?

['Axel Wagner' via golang-nuts]

I think addressing this would sensibly include a rule to allow unifying two
types, if one is assignable to the other (which, AIUI, we already do for
directional channels).

It's possible that this can be confusing in some circumstances including
composite types e.g. something like

func Append[T any](s []T, v ...T)
func main() {
var (
s []any
v []io.Reader
)
s = Append(s, v...) // would infer Append[any] and then fail to compile
because []io.Reader is not assignable to []any
}

But I can't really come up with an example where this is worse than the
status quo. Or even where something that *could* compile with fully
specified instantiation then doesn't compile with inferred arguments.

The situation also becomes significantly more complex if we take assignment
context into account for inference. AIUI we currently don't and it is
something I want.

I wouldn't want to confidently state that this is something we should or
should not do.

On Tue, Oct 24, 2023 at 5:01 PM tapi...@gmail.com 
wrote:

> My another surprise is that the below partial instantiation doesn't work.
>
> s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work
> s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works
>
> On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com wrote:
>
>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>>
>> Sorry, I didn't look your full code.
>> I think the full code should work with Go toolchain 1.21.n.
>>
>>
>> Aha, it actually doesn't. I'm surprised.
>>
>>
>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>
>> How so?
>>
>> Can you give an example scenario where it could cause unintended
>> consequences?  Or some other negative?
>>
>> -Mike
>>
>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
>> wrote:
>>
>>
>> It is hard to call such type inference better. That is too aggressive.
>>
>> --
> 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/7bd4727b-46ec-4972-b9a3-f7271892bff5n%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/CAEkBMfEWgAvSqqL5mSr-Nf%2B5P%2BNkOA%2BCSbt8fi%3DRuJYKiZfYVA%40mail.gmail.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[tapi...@gmail.com]

My another surprise is that the below partial instantiation doesn't work. 

s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work
s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works

On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com wrote:

> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>
> Sorry, I didn't look your full code.
> I think the full code should work with Go toolchain 1.21.n.
>
>
> Aha, it actually doesn't. I'm surprised.
>
>
> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>
> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
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/7bd4727b-46ec-4972-b9a3-f7271892bff5n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[tapi...@gmail.com]

In the "Special situations" section of this article 
https://go.dev/blog/type-inference,
it is mentioned a bit on this.
My understanding of that chapter is, when choosing the inferred type 
argument,
the current priority is: name types > directional channel types > other 
unnamed types.

In the case of the current thread, there are two type argument candidates, 
both of
them are named types, so the type interference fails.

Maybe the priority should be: interface types > named types > directional 
channel types > other unnamed types.

On Tuesday, October 24, 2023 at 3:53:14 AM UTC+8 Mike Schinkel wrote:

> Yes, I was surprised too.  It actually took me the better part of a day 
> trying to get this to work before finally posting to the list.
>
> It turns out that this limit was actually documented by Ian Lance Taylor 
> back in February 2023:
>
> https://github.com/golang/go/issues/58650
>
> Look for the section entitled *"Inferring based on interfaces."*
>
> Again, it sure would be nice it this were possible, if for no other reason 
> than to keep others being as time-inefficient as I was while trying to 
> figure it out. 
>
> -Mike
> On Sunday, October 22, 2023 at 11:01:47 PM UTC-4 tapi...@gmail.com wrote:
>
>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>>
>> Sorry, I didn't look your full code.
>> I think the full code should work with Go toolchain 1.21.n.
>>
>>
>> Aha, it actually doesn't. I'm surprised.
>>
>>
>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>
>> How so? 
>>
>> Can you give an example scenario where it could cause unintended 
>> consequences?  Or some other negative?
>>
>> -Mike
>>
>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
>> wrote:
>>
>>
>> It is hard to call such type inference better. That is too aggressive.
>>
>>

-- 
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/ee59d818-9219-44b3-9841-51e67037a02dn%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

TD;DR;
Erratas: I mean, I got all the genericity (not "generosity") I need
(without "I shall")

I'm sorry and please accept the amendment.

El lun, 23 oct 2023 a las 18:21, Victor Giordano ()
escribió:

> Yes Ineed Mike! Generics can be good and can be bad... perhaps just as the
> OOP inheritance.
>
> And thanks Alex indeed! His answer was enlightening!
>
> TD;DR;
> Just another personal feeling.
>
> Prior to generics: with interfaces I live a happy life, I got all the
> generosity I shall need... if I wanna work with slices of interfaces I
> learn that I have to use the for range loop for converting each element of
> the interface's slice into the concrete type. I learned it from this
> article  (Look for "Values of
> []T can't be directly converted to []I, even if type T implements interface
> type I").
>
>
>
> El lun, 23 oct 2023 a las 16:59, Mike Schinkel ()
> escribió:
>
>> Absolutely, some times generics are not needed.
>>
>> I actually don't find a need to use them that often which is probably why
>> when I came across a use-case that really needed them I was so stumped as
>> to how make it work.  Kudos again to Axel for helping me recognize my
>> blindspot.
>>
>> -Mike
>> P.S. BTW, regarding your *"I mean this...
>> "* link, I already addressed
>> 
>> why that was not sufficient for the use-case earlier in the thread. #justfyi
>>
>> On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote:
>>
>>> Very interesting case.
>>>
>>> As Alex says, if you "help" the compiler writing  the actual type
>>> parameter like `Append[Suiter](slice, suiter)` it works. I have seen this
>>> before in Java when generics comes into town... I guess with time golang
>>> team with time will improve the type inference engine... this also happens
>>> with typescript... perhaps is a common trait in evolution of language
>>> compilers.
>>>
>>> Now if you allow me, I do appreciate that not using generics and using
>>> interfaces in your Append method things will work... I mean this
>>> ...
>>> I know... probably it won't fit to your coding issues... but what I feel
>>> sometimes is that generics aren't necessary and we tend to make use. I
>>> don't know.. forgive me if I'm wrong... just an opinion.
>>>
>>>
>>> El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com
>>> escribió:
>>>
 On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com
 wrote:

 Sorry, I didn't look your full code.
 I think the full code should work with Go toolchain 1.21.n.


 Aha, it actually doesn't. I'm surprised.


 On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:

 How so?

 Can you give an example scenario where it could cause unintended
 consequences?  Or some other negative?

 -Mike

 On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
 wrote:


 It is hard to call such type inference better. That is too aggressive.

 --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/eD7207kM8zA/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/c62243c1-d6af-41c1-b64d-be7d59063576n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> V
>


-- 
V

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

Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

Yes Ineed Mike! Generics can be good and can be bad... perhaps just as the
OOP inheritance.

And thanks Alex indeed! His answer was enlightening!

TD;DR;
Just another personal feeling.

Prior to generics: with interfaces I live a happy life, I got all the
generosity I shall need... if I wanna work with slices of interfaces I
learn that I have to use the for range loop for converting each element of
the interface's slice into the concrete type. I learned it from this article
 (Look for "Values of []T can't
be directly converted to []I, even if type T implements interface type I").



El lun, 23 oct 2023 a las 16:59, Mike Schinkel ()
escribió:

> Absolutely, some times generics are not needed.
>
> I actually don't find a need to use them that often which is probably why
> when I came across a use-case that really needed them I was so stumped as
> to how make it work.  Kudos again to Axel for helping me recognize my
> blindspot.
>
> -Mike
> P.S. BTW, regarding your *"I mean this...
> "* link, I already addressed
> 
> why that was not sufficient for the use-case earlier in the thread. #justfyi
>
> On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote:
>
>> Very interesting case.
>>
>> As Alex says, if you "help" the compiler writing  the actual type
>> parameter like `Append[Suiter](slice, suiter)` it works. I have seen this
>> before in Java when generics comes into town... I guess with time golang
>> team with time will improve the type inference engine... this also happens
>> with typescript... perhaps is a common trait in evolution of language
>> compilers.
>>
>> Now if you allow me, I do appreciate that not using generics and using
>> interfaces in your Append method things will work... I mean this
>> ...
>> I know... probably it won't fit to your coding issues... but what I feel
>> sometimes is that generics aren't necessary and we tend to make use. I
>> don't know.. forgive me if I'm wrong... just an opinion.
>>
>>
>> El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com
>> escribió:
>>
>>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com
>>> wrote:
>>>
>>> Sorry, I didn't look your full code.
>>> I think the full code should work with Go toolchain 1.21.n.
>>>
>>>
>>> Aha, it actually doesn't. I'm surprised.
>>>
>>>
>>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>>
>>> How so?
>>>
>>> Can you give an example scenario where it could cause unintended
>>> consequences?  Or some other negative?
>>>
>>> -Mike
>>>
>>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
>>> wrote:
>>>
>>>
>>> It is hard to call such type inference better. That is too aggressive.
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/eD7207kM8zA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/c62243c1-d6af-41c1-b64d-be7d59063576n%40googlegroups.com
> 
> .
>


-- 
V

-- 
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/CAPUu9ssfAUU%2BKQmF%3D4fo9KoTuj6%2BhAQQ5zQzs4Xr_KE47iuKnQ%40mail.gmail.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Mike Schinkel]

Absolutely, some times generics are not needed.  

I actually don't find a need to use them that often which is probably why 
when I came across a use-case that really needed them I was so stumped as 
to how make it work.  Kudos again to Axel for helping me recognize my 
blindspot.

-Mike
P.S. BTW, regarding your *"I mean this... 
"* link, I already addressed 
 why 
that was not sufficient for the use-case earlier in the thread. #justfyi

On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote:

> Very interesting case.
>
> As Alex says, if you "help" the compiler writing  the actual type 
> parameter like `Append[Suiter](slice, suiter)` it works. I have seen this 
> before in Java when generics comes into town... I guess with time golang 
> team with time will improve the type inference engine... this also happens 
> with typescript... perhaps is a common trait in evolution of language 
> compilers.
>
> Now if you allow me, I do appreciate that not using generics and using 
> interfaces in your Append method things will work... I mean this 
> ... 
> I know... probably it won't fit to your coding issues... but what I feel 
> sometimes is that generics aren't necessary and we tend to make use. I 
> don't know.. forgive me if I'm wrong... just an opinion.
>
>
> El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com 
> escribió:
>
>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>>
>> Sorry, I didn't look your full code.
>> I think the full code should work with Go toolchain 1.21.n.
>>
>>
>> Aha, it actually doesn't. I'm surprised.
>>
>>
>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>
>> How so? 
>>
>> Can you give an example scenario where it could cause unintended 
>> consequences?  Or some other negative?
>>
>> -Mike
>>
>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
>> wrote:
>>
>>
>> It is hard to call such type inference better. That is too aggressive.
>>
>>

-- 
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/c62243c1-d6af-41c1-b64d-be7d59063576n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Mike Schinkel]

Yes, I was surprised too.  It actually took me the better part of a day 
trying to get this to work before finally posting to the list.

It turns out that this limit was actually documented by Ian Lance Taylor 
back in February 2023:

https://github.com/golang/go/issues/58650

Look for the section entitled *"Inferring based on interfaces."*

Again, it sure would be nice it this were possible, if for no other reason 
than to keep others being as time-inefficient as I was while trying to 
figure it out. 

-Mike
On Sunday, October 22, 2023 at 11:01:47 PM UTC-4 tapi...@gmail.com wrote:

> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>
> Sorry, I didn't look your full code.
> I think the full code should work with Go toolchain 1.21.n.
>
>
> Aha, it actually doesn't. I'm surprised.
>
>
> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>
> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
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/d4b59845-bd40-4c24-9838-8b1210dfc205n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

Very interesting case.

As Alex says, if you "help" the compiler writing  the actual type parameter 
like `Append[Suiter](slice, suiter)` it works. I have seen this before in 
Java when generics comes into town... I guess with time golang team with 
time will improve the type inference engine... this also happens with 
typescript... perhaps is a common trait in evolution of language compilers.

Now if you allow me, I do appreciate that not using generics and using 
interfaces in your Append method things will work... I mean this 
... 
I know... probably it won't fit to your coding issues... but what I feel 
sometimes is that generics aren't necessary and we tend to make use. I 
don't know.. forgive me if I'm wrong... just an opinion.


El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com 
escribió:

> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>
> Sorry, I didn't look your full code.
> I think the full code should work with Go toolchain 1.21.n.
>
>
> Aha, it actually doesn't. I'm surprised.
>
>
> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>
> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
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/f9ccf911-c7f7-4b68-bee6-26df2eb6eb1fn%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[tapi...@gmail.com]

On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:

Sorry, I didn't look your full code.
I think the full code should work with Go toolchain 1.21.n.


Aha, it actually doesn't. I'm surprised.


On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:

How so? 

Can you give an example scenario where it could cause unintended 
consequences?  Or some other negative?

-Mike

On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com wrote:


It is hard to call such type inference better. That is too aggressive.

-- 
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/81b551a2-f8b5-45b7-88fa-b6207f7a324an%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[tapi...@gmail.com]

Sorry, I didn't look your full code.
I think the full code should work with Go toolchain 1.21.n.

On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:

> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
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/9353cb40-bda5-439f-a1a9-6b78aa7936f8n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Mike Schinkel]

How so? 

Can you give an example scenario where it could cause unintended 
consequences?  Or some other negative?

-Mike

On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com wrote:


It is hard to call such type inference better. That is too aggressive.

-- 
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/58122205-88a4-4a84-bddf-06a5a2c44197n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[tapi...@gmail.com]

On Sunday, October 22, 2023 at 4:09:51 AM UTC+8 Mike Schinkel wrote:

@Axel Wagner — 

Thank you for adding clarity to this.

Yes, it would be nice if we could get this to be handled with better type 
inference. 


It is hard to call such type inference better. That is too aggressive.
 


But unless and until then, we have our workarounds.

On Saturday, October 21, 2023 at 4:01:05 PM UTC-4 Axel Wagner wrote:

This is purely a type-inference problem. If you explicitly instantiate 
`Append`, it works: https://goplay.tools/snippet/15RFAPFPl3y
Type inference is still relatively limited. It might become possible to at 
some point omit the instantiation. I think this might be "Inferring based 
on interfaces" in https://github.com/golang/go/issues/58650
Until then, it's expected that there will be some cases where you need to 
specify the types.

On Sat, Oct 21, 2023 at 9:45 PM Mike Schinkel  wrote:

No, that pre-generics case is not sufficient for my use-case.  

For my use-case I need to be able to use other types besides []Suiter such 
as []int, e.g.:

var n []int
n = Append(n, 1)
n = Append(n, 2)
n = Append(n, 3)
n = Append(n, 4)
for _, i := range n {
fmt.Printf("Int: %d\n", i)
}

See full code in playground .
On Saturday, October 21, 2023 at 3:15:03 PM UTC-4 Dan Kortschak wrote:

On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote: 
> Recently I was trying to write a func using generics where I wanted 
> to use a slice of an interface that would contain implementers of 
> that interface and then pass those types to a generic function, but I 
> ran into this error: 
> 
> type MyStruct of MySlice{} does not match inferred type MyInterface 
> for T 
> 
> My code is complex so I wrote the simplest example for this email and 
> here is part of that code: 
> 
> type Suiter interface { 
> Suit() 
> } 
> func Append[T any](s []T, i T) []T { 
> return append(s, i) 
> } 
> func main() { 
> var s []Suiter 
> 
> //CAN GENERICS SUPPORT THIS? 
> //s = Append(s, Clubs{}) 
> //s = Append(s, Hearts{}) 
> //s = Append(s, Diamonds{}) 
> //s = Append(s, Spades{}) 
> 
> //VERSUS HAVING TO DO THIS? 
> s = Append(s, Suiter(Clubs{})) 
> s = Append(s, Suiter(Hearts{})) 
> s = Append(s, Suiter(Diamonds{})) 
> s = Append(s, Suiter(Spades{})) 
> 
> for _, suit := range s { 
> fmt.Printf("Suit: %s\n", suitName(suit)) 
> } 
> } 
> The full code is here in a playground. 
> 
> Note: My example func Append() makes no sense in real use, I only use 
> it as it should be an easily understood example to show the syntax I 
> am trying to illustrate. 
> 
> Question: Is there a way to write Append() such that I can call 
> Append(s, Clubs{}) instead of having to write Append(s, 
> Suiter(Clubs{}))? 
> 
> And if no, is there a chance that in the future Go generics will be 
> able to support that level of type inference? 
> 

The pre-generics language handles this case: 
https://go.dev/play/p/jaJF7LTSVYe 

Is there something about your real case that makes this not acceptable? 

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/805dbd4a-e2a0-426e-b61f-45b9333803f5n%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/3225354d-de49-4f77-b719-2e4665f7963fn%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Mike Schinkel]

@Axel Wagner — 

Thank you for adding clarity to this.

Yes, it would be nice if we could get this to be handled with better type 
inference. 

But unless and until then, we have our workarounds.

On Saturday, October 21, 2023 at 4:01:05 PM UTC-4 Axel Wagner wrote:

> This is purely a type-inference problem. If you explicitly instantiate 
> `Append`, it works: https://goplay.tools/snippet/15RFAPFPl3y
> Type inference is still relatively limited. It might become possible to at 
> some point omit the instantiation. I think this might be "Inferring based 
> on interfaces" in https://github.com/golang/go/issues/58650
> Until then, it's expected that there will be some cases where you need to 
> specify the types.
>
> On Sat, Oct 21, 2023 at 9:45 PM Mike Schinkel  
> wrote:
>
>> No, that pre-generics case is not sufficient for my use-case.  
>>
>> For my use-case I need to be able to use other types besides []Suiter such 
>> as []int, e.g.:
>>
>> var n []int
>> n = Append(n, 1)
>> n = Append(n, 2)
>> n = Append(n, 3)
>> n = Append(n, 4)
>> for _, i := range n {
>> fmt.Printf("Int: %d\n", i)
>> }
>>
>> See full code in playground .
>> On Saturday, October 21, 2023 at 3:15:03 PM UTC-4 Dan Kortschak wrote:
>>
>>> On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote: 
>>> > Recently I was trying to write a func using generics where I wanted 
>>> > to use a slice of an interface that would contain implementers of 
>>> > that interface and then pass those types to a generic function, but I 
>>> > ran into this error: 
>>> > 
>>> > type MyStruct of MySlice{} does not match inferred type MyInterface 
>>> > for T 
>>> > 
>>> > My code is complex so I wrote the simplest example for this email and 
>>> > here is part of that code: 
>>> > 
>>> > type Suiter interface { 
>>> > Suit() 
>>> > } 
>>> > func Append[T any](s []T, i T) []T { 
>>> > return append(s, i) 
>>> > } 
>>> > func main() { 
>>> > var s []Suiter 
>>> > 
>>> > //CAN GENERICS SUPPORT THIS? 
>>> > //s = Append(s, Clubs{}) 
>>> > //s = Append(s, Hearts{}) 
>>> > //s = Append(s, Diamonds{}) 
>>> > //s = Append(s, Spades{}) 
>>> > 
>>> > //VERSUS HAVING TO DO THIS? 
>>> > s = Append(s, Suiter(Clubs{})) 
>>> > s = Append(s, Suiter(Hearts{})) 
>>> > s = Append(s, Suiter(Diamonds{})) 
>>> > s = Append(s, Suiter(Spades{})) 
>>> > 
>>> > for _, suit := range s { 
>>> > fmt.Printf("Suit: %s\n", suitName(suit)) 
>>> > } 
>>> > } 
>>> > The full code is here in a playground. 
>>> > 
>>> > Note: My example func Append() makes no sense in real use, I only use 
>>> > it as it should be an easily understood example to show the syntax I 
>>> > am trying to illustrate. 
>>> > 
>>> > Question: Is there a way to write Append() such that I can call 
>>> > Append(s, Clubs{}) instead of having to write Append(s, 
>>> > Suiter(Clubs{}))? 
>>> > 
>>> > And if no, is there a chance that in the future Go generics will be 
>>> > able to support that level of type inference? 
>>> > 
>>>
>>> The pre-generics language handles this case: 
>>> https://go.dev/play/p/jaJF7LTSVYe 
>>>
>>> Is there something about your real case that makes this not acceptable? 
>>>
>>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/805dbd4a-e2a0-426e-b61f-45b9333803f5n%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/adfe6f16-92a5-4195-bcda-2412506c2410n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

['Axel Wagner' via golang-nuts]

This is purely a type-inference problem. If you explicitly instantiate
`Append`, it works: https://goplay.tools/snippet/15RFAPFPl3y
Type inference is still relatively limited. It might become possible to at
some point omit the instantiation. I think this might be "Inferring based
on interfaces" in https://github.com/golang/go/issues/58650
Until then, it's expected that there will be some cases where you need to
specify the types.

On Sat, Oct 21, 2023 at 9:45 PM Mike Schinkel  wrote:

> No, that pre-generics case is not sufficient for my use-case.
>
> For my use-case I need to be able to use other types besides []Suiter such
> as []int, e.g.:
>
> var n []int
> n = Append(n, 1)
> n = Append(n, 2)
> n = Append(n, 3)
> n = Append(n, 4)
> for _, i := range n {
> fmt.Printf("Int: %d\n", i)
> }
>
> See full code in playground .
> On Saturday, October 21, 2023 at 3:15:03 PM UTC-4 Dan Kortschak wrote:
>
>> On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote:
>> > Recently I was trying to write a func using generics where I wanted
>> > to use a slice of an interface that would contain implementers of
>> > that interface and then pass those types to a generic function, but I
>> > ran into this error:
>> >
>> > type MyStruct of MySlice{} does not match inferred type MyInterface
>> > for T
>> >
>> > My code is complex so I wrote the simplest example for this email and
>> > here is part of that code:
>> >
>> > type Suiter interface {
>> > Suit()
>> > }
>> > func Append[T any](s []T, i T) []T {
>> > return append(s, i)
>> > }
>> > func main() {
>> > var s []Suiter
>> >
>> > //CAN GENERICS SUPPORT THIS?
>> > //s = Append(s, Clubs{})
>> > //s = Append(s, Hearts{})
>> > //s = Append(s, Diamonds{})
>> > //s = Append(s, Spades{})
>> >
>> > //VERSUS HAVING TO DO THIS?
>> > s = Append(s, Suiter(Clubs{}))
>> > s = Append(s, Suiter(Hearts{}))
>> > s = Append(s, Suiter(Diamonds{}))
>> > s = Append(s, Suiter(Spades{}))
>> >
>> > for _, suit := range s {
>> > fmt.Printf("Suit: %s\n", suitName(suit))
>> > }
>> > }
>> > The full code is here in a playground.
>> >
>> > Note: My example func Append() makes no sense in real use, I only use
>> > it as it should be an easily understood example to show the syntax I
>> > am trying to illustrate.
>> >
>> > Question: Is there a way to write Append() such that I can call
>> > Append(s, Clubs{}) instead of having to write Append(s,
>> > Suiter(Clubs{}))?
>> >
>> > And if no, is there a chance that in the future Go generics will be
>> > able to support that level of type inference?
>> >
>>
>> The pre-generics language handles this case:
>> https://go.dev/play/p/jaJF7LTSVYe
>>
>> Is there something about your real case that makes this not acceptable?
>>
>> --
> 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/805dbd4a-e2a0-426e-b61f-45b9333803f5n%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/CAEkBMfEEBQsMR6RfHMw3nHvr7peq-Mu05X0M55XqZ%3DERVQ5Sbg%40mail.gmail.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Mike Schinkel]

No, that pre-generics case is not sufficient for my use-case.  

For my use-case I need to be able to use other types besides []Suiter such 
as []int, e.g.:

var n []int
n = Append(n, 1)
n = Append(n, 2)
n = Append(n, 3)
n = Append(n, 4)
for _, i := range n {
fmt.Printf("Int: %d\n", i)
}

See full code in playground .
On Saturday, October 21, 2023 at 3:15:03 PM UTC-4 Dan Kortschak wrote:

> On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote:
> > Recently I was trying to write a func using generics where I wanted
> > to use a slice of an interface that would contain implementers of
> > that interface and then pass those types to a generic function, but I
> > ran into this error:
> > 
> > type MyStruct of MySlice{} does not match inferred type MyInterface
> > for T
> > 
> > My code is complex so I wrote the simplest example for this email and
> > here is part of that code:
> > 
> > type Suiter interface {
> > Suit()
> > }
> > func Append[T any](s []T, i T) []T {
> > return append(s, i)
> > }
> > func main() {
> > var s []Suiter
> > 
> > //CAN GENERICS SUPPORT THIS?
> > //s = Append(s, Clubs{})
> > //s = Append(s, Hearts{})
> > //s = Append(s, Diamonds{})
> > //s = Append(s, Spades{})
> > 
> > //VERSUS HAVING TO DO THIS?
> > s = Append(s, Suiter(Clubs{}))
> > s = Append(s, Suiter(Hearts{}))
> > s = Append(s, Suiter(Diamonds{}))
> > s = Append(s, Suiter(Spades{}))
> > 
> > for _, suit := range s {
> > fmt.Printf("Suit: %s\n", suitName(suit))
> > }
> > }
> > The full code is here in a playground.
> > 
> > Note: My example func Append() makes no sense in real use, I only use
> > it as it should be an easily understood example to show the syntax I
> > am trying to illustrate.
> > 
> > Question: Is there a way to write Append() such that I can call
> > Append(s, Clubs{}) instead of having to write Append(s,
> > Suiter(Clubs{}))?
> > 
> > And if no, is there a chance that in the future Go generics will be
> > able to support that level of type inference?
> > 
>
> The pre-generics language handles this case:
> https://go.dev/play/p/jaJF7LTSVYe
>
> Is there something about your real case that makes this not acceptable?
>
>

-- 
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/805dbd4a-e2a0-426e-b61f-45b9333803f5n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

['Dan Kortschak' via golang-nuts]

On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote:
> Recently I was trying to write a func using generics where I wanted
> to use a slice of an interface that would contain implementers of
> that interface and then pass those types to a generic function, but I
> ran into this error:
> 
> type MyStruct of MySlice{} does not match inferred type MyInterface
> for T
> 
> My code is complex so I wrote the simplest example for this email and
> here is part of that code:
> 
> type Suiter interface {
> Suit()
> }
> func Append[T any](s []T, i T) []T {
> return append(s, i)
> }
> func main() {
> var s []Suiter
> 
> //CAN GENERICS SUPPORT THIS?
> //s = Append(s, Clubs{})
> //s = Append(s, Hearts{})
> //s = Append(s, Diamonds{})
> //s = Append(s, Spades{})
> 
> //VERSUS HAVING TO DO THIS?
> s = Append(s, Suiter(Clubs{}))
> s = Append(s, Suiter(Hearts{}))
> s = Append(s, Suiter(Diamonds{}))
> s = Append(s, Suiter(Spades{}))
> 
> for _, suit := range s {
> fmt.Printf("Suit: %s\n", suitName(suit))
> }
> }
> The full code is here in a playground.
> 
> Note: My example func Append() makes no sense in real use, I only use
> it as it should be an easily understood example to show the syntax I
> am trying to illustrate.
> 
> Question: Is there a way to write Append() such that I can call
> Append(s, Clubs{}) instead of having to write Append(s,
> Suiter(Clubs{}))?
> 
> And if no, is there a chance that in the future Go generics will be
> able to support that level of type inference?
> 

The pre-generics language handles this case:
https://go.dev/play/p/jaJF7LTSVYe

Is there something about your real case that makes this not acceptable?

-- 
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/9aab12f4935edebe2067bbae3c00faa5b50c79d8.camel%40kortschak.io.