New proposal: Go generics have come to play, switch type is here!

Hello everyone, I am fried fish.

I have written several articles about Go generic grammar, case introduction, and new first-hand Go news. In fact, as some proposals were accepted, new proposals gradually emerged.

No, I found that with generics, you can go a step further and spend more time. I saw a "new" proposal " proposal: spec: generics: type switch on parametric types ", which talked about the type switch requirements on the parameter types after adding generics.

Follow the fried fish to master new Go knowledge!

New proposal

The content of the new proposal is to add a new variant statement that allows the use of generics in switch statements to further constrain its type parameters.

For example:

switch type T {
case A1:
case A2, A3:
   ...
}

That is, the T type of the switch-type statement can be a generic type parameter , and the type corresponding to the case can be any type, including generic constraint types.

Assume that the type of type T may be as follows:

interface{
    C
    A
}

You can use generic approximate elements to constrain:

    interface{
        C
        A1 | A2 | ... | An
    }

There can even be a new way of writing on the case:

case interface {~T}:

After supporting generics, switch will have many possibilities in type and case , and specific feature support is required. This proposal is for this reason.

actual case

Case 1: Multi-type elements

type Stringish interface {
    string | fmt.Stringer
}

func Concat[S Stringish](x []S "S Stringish") string {
    switch type S {
    case string:
        ...
    case fmt.Stringer:
        ...
    }
 }

Type S can support string and fmt.Stringer types, and the case is implemented correspondingly.

Case 2: Approximate elements

type Constraint interface {
    ~int | ~int8 | ~string
}

func ThisSyntax[T Constraint]( "T Constraint") {
    switch type T {
    case ~int | ~int8:
        ...
    case ~string:
        ...
    }
}

func IsClearerThanThisSyntax[T Constraint]( "T Constraint") {
    switch type T {
    case interface{~int | ~int8 }:
        ...
    case interface{ ~string }:
        ...
    }
}

Type T may have many types. Approximate elements are used in the program, that is, the basic types are int, int8, and string. Any of these types can satisfy this constraint.

For this reason, switch-type is supported, and the case should also support this feature.

Controversy

Everyone might have thought about it. The taste is very familiar, as if a certain grammar can support it. Therefore, the most controversial issue under this proposal is the duplication with the original type assertion.

The original type assertion is as follows:

switch T.(type) {
case string:
   ...
default:
   ...
}

The new type discrimination is as follows:

switch type T {
case A1:
case A2, A3:
   ...
}

At first glance, in fact, the type assertion can completely replace the new one. Isn't it repeated construction and making wheels?

In fact, it is not completely replaced. The differences are as follows:

type ApproxString interface { ~string }

func F[T ApproxString](v T "T ApproxString") {
    switch (interface{})(v).(type) {
    case string:
        fmt.Println(v)
    default:
        panic("脑子没进煎鱼")
    }
}

type MyString string

func main() {
    F(MyString("脑子进煎鱼了"))
}

Can you see the difference and what is the answer?

The answer is: panic.

You may be struggling, what's the problem? The type of this incoming "brain is fried fish" is MyString , its basic type is string , and it also meets the requirements of ApproxString which is the approximate type of ~string , how can it not work...

The root cause is because his type is interface, not string type. So I got to the panic of the defalut branch.

Summarize

Today I introduced you to the latest news of Go generics. After the previous proposal was merged, there were some new developments in this proposal. However, Go officially stated that it will continue to promote the proposal after being proficient in generic practices.

I believe that the original switch.(type) and switch type likely to be processed in the same logic block at the bottom of Go, and then gradually transition.

The purpose of this proposal is order to solve some of the BUG/requirements brought by the introduction of generics, which is exactly what needs a new grammatical structure to solve.

What is your opinion on this? , please leave a message and exchange in the comment area:)

If you have any questions, welcome feedback and communication in the comment area. The best relationship between . Your likes is the greatest motivation for the creation of fried fish

The article is continuously updated, and you can read it on search [My brain is fried fish]. This article 161bb07297198e GitHub github.com/eddycjy/blog has been included. For learning Go language, you can see Go learning map and route . Welcome to Star to remind you.