On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner
<axel.wagner...@googlemail.com> wrote:
>
> On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor <i...@golang.org> wrote:
>>
>> Yes, there are various such possibilities.
>>
>> What jimmy frasche said above is correct: nothing changes in the case
>> of a type switch of a type parameter. The code now knows the type
>> list element that the type argument matched, but it can't do anything
>> that it couldn't do anyhow.
>
>
> I think there are two reasonable things that it could be allowed to do in the
> case, that aren't allowed outside:
> 1. Convert to the matched type. We have a guarantee that the matched type is
> either identical or has the same underlying type, both of which would allow a
> conversion in the language as-is. I feel allowing this conversion would be
> sufficiently useful (e.g. passing things to `strconv.Itoa` or functions from
> `math` can be very useful).
> 2. If the type is not a predeclared type, we could even take this a step
> further, as the types must be identical - so we might allow treating them as
> such. This feels natural when viewed from the "type lists are essentially sum
> types" POV. However, it would treat predeclared types more special than other
> declared types and so it may be too elaborate to put into the spec. It would
> also allow what rog suggest - but only in certain corner cases, which feels
> weird.
>
> The more I think about it, the less I understand the intention behind the
> type-switch construct introduced. I tend to agree that 1. at least should be
> possible to make it useful. But even then, it seems like kind of a big change
> for relatively limited use. What was the motivation behind that change? Is
> there discussion somewhere, of interesting use-cases this enables?
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.
See also
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type
.
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.
Ian
--
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/CAOyqgcWt25q-oboPW%3Dky4gr9GDyrTDewO8NiLjr%2Bb1MrSXMeUg%40mail.gmail.com.
