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/94fce34e-0922-48a8-a26b-46811c06ab1en%40googlegroups.com.
