> We would have to have careful definitions of what kinds of code are
permitted in a case with multiple types.
ISTM that we already have such a careful definition with generics: given a
case in a `switch x.(type)` statement of the form `T1, T2, ..., Tn`, where
`x` is of type `S`, we could define the allowed operations of `x` as if it
was a parameter to a a generic function with type constraint `interface {S;
T1 | T2 | ... | Tn}`.
So your specific `[]int, map[int]int` example wouldn't be allowed, but this
would:
switch x := v.(type) {
case int32, int64:
fmt.Println(x + 1)
}
Perhaps this could be considered a natural extension of the way that the
type of `x` becomes `S` inside the default branch of the type switch
statement.
On Fri, 25 Aug 2023 at 22:02, Ian Lance Taylor <i...@golang.org> wrote:
> On Fri, Aug 25, 2023 at 1:55 PM محمد بومنذر
> <mohammed.bu...@gmail.com> wrote:
> >
> > It's actually plain text but copied right from my editor with the theme
> styles, I'll use the playground for future examples.
>
> Thanks. Then I guess my request is to paste as plain text without styles.
>
> Ian
>
> > Thank you for clarifying. I do see how the compiled version will need to
> be repetitive, although as you mentioned this piece of code is not a common
> case.
> > في Friday, August 25, 2023 في تمام الساعة 11:43:05 PM UTC+3، كتب Ian
> Lance Taylor رسالة نصها:
> >>
> >> On Fri, Aug 25, 2023 at 7:43 AM محمد بومنذر
> >> <mohamme...@gmail.com> wrote:
> >> >
> >> > I'm writing a parser based on Go's `encoding/xml`, I tried to use the
> following pattern but it was deemed invalid:
> >> >
> >> > ```
> >> > To me, it'd make sense if it was allowed since both types are structs
> and both of them share the field `Name` with the subsequent field `Local`.
> >>
> >>
> >> Please post code as plain text or as a link to the Go playground, not
> >> as an image. Images are much harder to read, and there is no reason
> >> to use them for plain code. Thanks.
> >>
> >> We are unlikely to implement such a language feature. We would have
> >> to have careful definitions of what kinds of code are permitted in a
> >> case with multiple types. And since in general there is no reason to
> >> expect that the fields are at the same location, we would have to
> >> compile the case differently for each type anyhow. And the code might
> >> actually behave quite differently; should we permit code like
> >>
> >> switch x := v.(type) {
> >> case []int, map[int]int:
> >> return x[1]
> >> }
> >>
> >> 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/312da70b-11c3-43b1-b53e-6d1a8e622becn%40googlegroups.com
> .
>
> --
> 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/CAOyqgcUzp9p4dhzN%3DD-p2HsSvN%3DgsmiFX65RRdXqUhj5wJ8VRQ%40mail.gmail.com
> .
>
--
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/CAJhgacj9We4OZ3ikP7ENrqwLc7g2Oosae%3Dc8WQJ0ZZ3H69t%3D3g%40mail.gmail.com.
