On Tue, Oct 24, 2023 at 6:14 PM Victor Giordano <vitucho3...@gmail.com>
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 <tapir....@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
>>> <https://groups.google.com/d/msgid/golang-nuts/7bd4727b-46ec-4972-b9a3-f7271892bff5n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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
>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEWgAvSqqL5mSr-Nf%2B5P%2BNkOA%2BCSbt8fi%3DRuJYKiZfYVA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> 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/CAEkBMfE%2BkVYXRZv%3DUGfHdwO89RkekbjrT8cSRR0puor-kaYw0g%40mail.gmail.com.

Reply via email to