News for hackers. Stuff that matters.
Re:Names are not type safety by codygman on Monday November 02, 2020 @05:28PM (#24974237)
> Is Go fundamentally type-unsafe?

Interface{} and nil pointers point to yes.

Re:Names are not type safety by platinumrad on Monday November 02, 2020 @07:46PM (#24975166)
Neither of those is incompatible with Cardelli's definition of type safety. `interface{}` is not `void *`. Null pointer errors are not untrapped.
Re:Names are not type safety by lmm on Tuesday November 03, 2020 @07:33PM (#24985622)
Cardelli's definitions are extremely odd; if you take them literally then Python is type safe but Java is not.

In everyday language a downcast, even a checked one, is not a type-safe operation, and so to the extent that Go's limited type system makes it impractical to write programs without downcasts I'd say that Go is fundamentally type-unsafe.

Re:Names are not type safety by Joker_vD on Thursday November 05, 2020 @09:44AM (#24998655)
Well, it's a matter of taste, I guess. In my opinion any downcast that reliably distinguishes between valid and invalid values is type-safe. The behaviour of

    defer func() {
        if e := recover(); e != nil {
            fmt.Printf("not a string %v\n", e)
        }
    }()
    v := interface{}(5)
    u := v.(string)
    fmt.Println(u)
is well-defined: it will print "not a string", always.
Re:Names are not type safety by lmm on Friday November 06, 2020 @02:37AM (#25005800)
By that logic there's no such thing as a non-type-safe language, because all programs have behaviour.

Normally one would say a checked downcast like that is not type-safe, because you can't reason locally about the type behaviour of the downcast based on knowing the type of v. You would have to know the value of v, which is a Turing-complete problem in the general case.