[generics] type switches
649 views
Skip to first unread message
thepud...@gmail.com
Feb 20, 2021, 10:43:51 PM2/20/21
to golang-nuts
Hello fellow gophers,
Ian announced the intention to update how type switches work in the generics proposal in a golang-nuts thread from this August:
It included this from Ian (which is a snippet of his item #4 from his first post there):
----------------------------------------------------------------------------------
In a type switch on a type parameter with a type list, every case
listed must be a type that appears in the type list (“default” is also
permitted, of course). A case will be chosen if it is the type matched
by the type argument, although as discussed above it may not be the exact
type argument: it may be the underlying type of the type argument. To make
that rule very clear, type switches will not be permitted for type
parameters that do not have type lists.
----------------------------------------------------------------------------------
There was a follow-on discussion in that thread on the desired type switch behavior, including gophers like Rog Peppe and Jimmy Frasche commenting on what they were hoping this meant.
I think the conclusion of that conversation might have been that adjustment in type switch behavior suggested by Ian was not adopted as part of the current proposal... but I'm not 100% sure, and wanted to check if that is indeed the case (vs. maybe it was adopted, and perhaps I am just missing how it works in the current go2go prototype, or maybe it is still planned to be adopted but maybe the proposal and/or prototype haven't been updated yet).
The most definitive comment from Ian as part of that conversation might have been:
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
Given a type parameter, there are two interesting pieces of
information. One is what the actual type argument is; we can already
determine that by writing code like "var x T; switch
(interface{})(x).(type) { ... }". The other is which type in the type
list was matched by the type argument. The latter is the purpose of
the type switch suggested here. Without something like that type
switch, there is no straightforward way for a generic function to
determine which type in a type list is matched by a type argument.
I'm not at all wedded to this. We can continue to omit it. It just
seems like adding a capability that does not otherwise exist.
----------------------------------------------------------------------------------
The current draft seems to hold out the following as a future option:
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
One way to handle this would be to permit type switches on the type T, with the
proviso that the type T would always match a type defined in the constraint. This
kind of type switch would only be permitted if the constraint lists explicit types,
and only types listed in the constraint would be permitted as cases.
----------------------------------------------------------------------------------
In any event, I am curious about the latest thinking and/or latest status. If this has been discussed at length elsewhere since that August thread, I would be happy for a pointer if anyone has one.
Thanks, and sorry if the answer is I am just confused ;-)
Best regards,
thepudds
Axel Wagner
Feb 21, 2021, 4:35:41 AM2/21/21
to thepud...@gmail.com, golang-nuts
In any event, I am curious about the latest thinking and/or latest status. If this has been discussed at length elsewhere since that August thread, I would be happy for a pointer if anyone has one.
I think for the most part, you found the discussion and the latest status - it's not clear it's a good idea, so it's left out of the proposal for now. It might get added later (where "later" most likely means "after generics have landed and we see how they're used"). There's probably also some additional discussion in #43651 and some tangentially related discussion in #41716 (one consideration is how type-switches would interact if we ever decided to adopt an extension of using type-list interfaces as sum-types), though both issues might be hard to comb through. I'm not aware of a thread more specifically concerned with this question.
Thanks, and sorry if the answer is I am just confused ;-)Best regards,thepudds
--
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/dbdc0e64-b41d-4c69-9218-5972dc3b21a3n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages