On Fri, Feb 11, 2022 at 2:48 PM Kamil Ziemian <kziemian...@gmail.com> wrote:
> 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.
>
It would work fine, for my case, to be required to name unused type
parameters `_`. Though I think the code would be less clear. With `type
ID[Req, Resp Message] string` it is clear what the type parameters are and
what they should be instantiated with. That's not the case with `type ID[_,
_ Message] string`.
I think there is arguably a difference between generic functions and
generic type declarations. In the former case, an argument name is rarely
needed for the documentation, whereas in the latter case it's probably
always needed. Though I'm not sure, really.
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?
>
Yes.
> 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 is non-generic code currently used in production and I would like it to
benefit from generics. The issue with type-inference came up when thinking
about that. So, no, this is not something that I made up to have an example
or anything like that. I thought about a couple alternative ways to do it
and they all don't work for one reason or another.
I feel pretty confident that this is not an instance of "designing types".
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.
>
Believe it or not, but I agree. It's just the least bad solution I could
come up with, so far.
> 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
> <https://groups.google.com/d/msgid/golang-nuts/93a49e37-d8c8-452f-a5ef-985cf7fe5bb7n%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/CAEkBMfE03jENpO7t3Qg6h0ZxkTx%2B9YbbFw7OHAFQ4VdhdY%3DOeA%40mail.gmail.com.
