Axel I agree that "But there is at least some potential benefit to allowing
it.". But, by my humble understanding, true question is "Would Go still
feel likes Go after this?". This question is one of the reasons why
generics was so long, decade or even more, in the making. Somewhere on
GitHub there is a discussion about unused type of arguments in the
function. I think they agree that with benefits of hindsight you should be
force to write func f(_ int) ... for any unused argument, that is need for
function signature or some similar reason. But, now this will be to much
breaking of backward compatibility with to little benefit. So I think it is
worth pondering now, even if we it is already to late to change anything in
Go 1.18.
"As I said, I'm not 100% yet on whether this is a good idea and much less
if that would be enough reason to keep allowing unused type parameters." I
like your approach. As I understand your code, because type inference works
only on types of arguments, not on types of return values, you define a
somepkg.ID to be just a string, that carries information about two
additional types. This allows Go type inference algorithm infer type of
return value from ID value and put it into place of return type of
particular instantiation of generic function. Am I right?
You are almost surly more experience Go programmer than me, so anything
that I write next may be just silly. Ian Lance Taylor give us one
Go-proverb-like advice about generics in Go: "Write code, don't design
types". Was your code created according to this rule? It doesn't look like
that to me, but I'm in no case someone who should judge it. Better gophers
should look at it and decide if this is legitimate use of type parameters.
My guts tell me that is not what I want to work with. It is some workaround
of type interference algorithm, by putting too much information in one
humble string-under-the-hood type. Dave Cheney said once that "Zen of
Python" is also valid in Go and maybe better followed by Go programmers
than by Python programmers. And this seems to be a breaking of rule
"Explicit is better implicit" and, more importantly, of Go proverb "Clear
is better than clever". But, again, so true gopher should judge your code,
not me. I just write this to start some discussion about that and I
remember that you yourself have doubts about it.
Best,
Kamil
piątek, 11 lutego 2022 o 13:56:54 UTC+1 Kamil Ziemian napisał(a):
> Thank you Jan Marcel. I see now that I wasn't precise enough. I understand
> that '[' and ']' are just tokens, even I have only intuitive understanding
> of concept of token. My problem is that as Ian Lance Taylor and other
> people said many times: adding generics will make Go more complicated. My
> problem is not in understanding why it is more complicated, but to accept
> disturbing cases of it becoming so. It less question of intellectually
> understanding, more about "feeling of Go". Which is of course hard to
> defined.
>
> I copied compilations errors, because in many cases I don't find Go
> compilers errors very useful. Don't get me wrong, in many cases there are
> fine, but messages as
> > type someDifferentInt[float64] int
> > error: float64 (type) is not an expression
> are not something that I understand. I often end up ignoring the message
> and just stare for few minutes in the line where the error was found,
> compare it to working examples, tweak code a little bit and find what
> happens. I hope that someone give me some advise how to deal with that,
> that Go errors are going to be even harder to me to read. Even if this
> advise is "Just accept it and carry on", it will be valuable.
>
> Best,
> Kamil
>
> piątek, 11 lutego 2022 o 13:38:44 UTC+1 axel.wa...@googlemail.com
> napisał(a):
>
>> On Fri, Feb 11, 2022 at 12:51 PM Kamil Ziemian <kziem...@gmail.com>
>> wrote:
>>
>>> Can someone explain me, why compiler can't throw an error when it find
>>> unused type parameter? I like that in Go unused variable, or import, is
>>> compile time error and I would appreciate the same behavior with unused
>>> type parameters.
>>>
>>
>> I'm not sure it's reason enough, but I do have a case where I want to
>> have unused type-parameters on a type.
>> Essentially, I have
>>
>> type ID string
>> func Call(ctx context.Context, id ID, req Message) (Message, error)
>>
>> which does an RPC-like call. It's used as
>>
>> r, err := framework.Call(ctx, somepkg.ID, somepkg,Request{…})
>> resp := r.(somepkg.Response)
>>
>> With generics, this would be
>>
>> type ID string
>> func Call[Req, Resp Message](context.Context, ID, Req) (Resp, error)
>>
>> But this requires writing
>>
>> resp, err := framework.Call[somepkg.Request, somepkg.Response](ctx,
>> somepkg.ID, somepkg.Request{…})
>>
>> as return types can't be inferred. Instead, I plan to do
>>
>> type ID[Req, Resp Message] string // unused type-parameters
>> func Call[Req, Resp Message](context.Context, ID[Req, Resp], Req) (Resp,
>> error)
>>
>> which allows `somepkg` to declare
>>
>> var ID = framework.ID[MyRequest, MyResponse]("my-name")
>>
>> letting the client write
>>
>> resp, err := framework.Call(ctx, somepkg.ID, somepkg.Request)
>>
>> Now somepkg.ID carries both types and is in an argument, so both types
>> can be inferred.
>>
>> As I said, I'm not 100% yet on whether this is a good idea and much less
>> if that would be enough reason to keep allowing unused type parameters. But
>> there is at least some potential benefit to allowing it.
>>
>>
>>>
>>> I need to go for a while, I will go back with more questions about what
>>> you can get when using "[]" in Go.
>>>
>>> Best,
>>> Kamil
>>>
>>> --
>>> 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/b085b991-e59e-4225-a4d6-36b2391e1dc2n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/b085b991-e59e-4225-a4d6-36b2391e1dc2n%40googlegroups.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/93a49e37-d8c8-452f-a5ef-985cf7fe5bb7n%40googlegroups.com.
