Re: [go-nuts] Re: Why causes []any trouble in type equations?

In the first example, the inferred type is `float64`, so the signature of the function is `func do([]float64)`. You can obviously pass a `[]float64` to it. If X is a concrete (i.e. non-interface) type, then `func F[T X]()` is syntactic sugar for `func F[T interface{ X }]()`, which is a constraint t

[go-nuts] [security] Go 1.21.3 and Go 1.20.10 are released

Hello gophers, We have just released Go versions 1.21.3 and 1.20.10, minor point releases. These minor releases include 1 security fixes following the security policy : - net/http: rapid stream resets can cause excessive work A malicious HTTP/2 client whi

[go-nuts] Re: Why causes []any trouble in type equations?

Hallöchen! Kurtis Rader writes: > This has nothing to do with generics. It is a FAQ regarding the > conversion of a container type value. You cannot modify the type of > the object in a container in a called context. This has been true > before generics was introduced. Ignoring generics what do y

Re: [go-nuts] In golang spec, if it cast the variable, pointer that cast returns is changed?

Hi, Note that this has nothing to do with casting. `after` and `before` are not pointers, they're plain old `int` variables (or `DefinedInt` in your example but that does not change anything). When you do `after := whatever`, you're declaring (and assigning) a new variable `after` to hold the same

[go-nuts] In golang spec, if it cast the variable, pointer that cast returns is changed?

Hello! In golang spec, if it cast the variable, pointer that cast returns is changed? Consider the following code. Do the pointers `before` and `after` hold different values? ```go package main import "fmt" type DefinedInt int func main() { var before int before = 1 after := DefinedInt(befo

Re: [go-nuts] Why causes []any trouble in type equations?

This has nothing to do with generics. It is a FAQ regarding the conversion of a container type value. You cannot modify the type of the object in a container in a called context. This has been true before generics was introduced. Ignoring generics what do you think should happen if you call a funct

Re: [go-nuts] Why causes []any trouble in type equations?

In the second case, the type argument is inferred to be `[]float64`. The constraint on `T` in `do` is that it has to be `[]any`. `[]float64` is not `[]any`, the two are different types, so instantiation fails. Note that even if you explicitly instantiate `do` to `[]any`, you still could not pass a

[go-nuts] Why causes []any trouble in type equations?

Hallöchen! The two most recent Go blog articles make we wonder why package main func do[T []E, E any](slice T) { } func main() { var a []float64 do(a) } is valid while package main func do[T []any](slice T) { } func main() {