On Sat, 14 Mar 2026 at 06:49, Kurtis Rader <[email protected]> wrote:
> I guess I'm showing my age. But if you have to write an explicit run time
> type switch/assertion then you should assume the compile time type
> constraint might allow an unexpected type to "leak" into your function.
>
I don't understand this assertion. It seems plain untrue to me. If we
allowed you to write `fmt.Stringer | ~string` (and put a SAT solver into
the compiler to do the appropriate checks) but otherwise not changed the
language at all, then this would be accepted by the compiler:
func Stringify[T interface{ ~string | fmt.Stringer}](v T) string {
// still have to write the type switch
switch v := any(v).(type) {
case fmt.Stringer:
return v.String()
default:
return reflect.ValueOf(v).String()
}
}
This is of course somewhat error prone, you might easily forget a branch or
otherwise screw up the logic of your function. But it would mean this is
rejected by the compiler:
func main() {
println(Stringify[int](42))
}
If, instead, you use `T any`, this program would be allowed and panic at
runtime.
> If the O.P.'s example was supported by the compilation toolchain that
> might be impossible, in theory, but I would assume it's still possible if I
> have to write code to disambiguate which type I received.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGmS%2BvpBs-cPMnx0o_T_7U_g%2B21qf7S36PkSA%3DoY0QELQ%40mail.gmail.com.
