2 ms·

> yours was checked at runtime. Frankly, I have never heard of a term for what you have shown, so I don't know what to call it. Surely that's not the first tim

> yours was checked at runtime. Frankly, I have never heard of a term for what you have shown, so I don't know what to call it. Surely that's not the first time you've heard of run-time type casts? Well, in any case, they are colloquially called "type casts" and/or "type conversions". To be more pedantic, Java calls it "casting conversion" [0] which, in this specific case, allows one of the "narrowing reference conversion" [1] to happen. Go calls their version "type assertion" [2] but if you read what it actually does ("If T is an interface type, x.(T) asserts that the dynamic type of x implements the interface T") and compare with what Java does ("Such conversions require a test at run time to find out whether the actual reference value is a legitimate value of the new type"), I hope you would agree they are essentially the same. We can also take a look at C# [3]: it has "cast expressions" which work like this: "A cast-expression of the form (T)E, where T is a type and E is a unary-expression, performs an explicit conversion (§13.2) of the value of E to type T". And in this example, the exact kind of conversion to be performed would be 13.2.3, "Explicit reference conversions" for which the following is stated: "The explicit reference conversions are those conversions between reference-types that require run-time checks to ensure they are correct". So TFA could be written in any of those languages (or even in C++ with its dynamic_cast<T>) and look almost exactly the same because all TFA does it takes some objects, converts them up to Object type that subsumes all other types (in Golang's case, this type is called "any"), then tries to convert them down to some interface types which those objects may or may not implement, and blows up. But neither Java, C#, nor C++ have neither structural nor duck typing so TFA's claim that somehow this example shows that Go has duck or structural typing is simply baseless. [0] https://docs.oracle.com/javase/specs/jls/se6/html/conversions.html#5.5 https://docs.oracle.com/javase/specs/jls/se6/html/conversion... [1] https://docs.oracle.com/javase/specs/jls/se6/html/conversions.html#25379 https://docs.oracle.com/javase/specs/jls/se6/html/conversion... [2] https://go.dev/ref/spec#Type_assertions https://go.dev/ref/spec#Type_assertions [3] https://www.itu.dk/people/sestoft/ecma/Ecma-334.pdf https://www.itu.dk/people/sestoft/ecma/Ecma-334.pdf

randomdata 2y ago
> Surely that's not the first time you've heard of run-time type casts? Indeed – and for good reason, I'm sure. Pedantically, a cast is where the programmer says in a language "just trust me on what type this is, don't bother to check my claim". A runtime type cast doesn't make any sense. I mean, I'm fine with words evolving and whatnot. I'm not here actually trying to play language police myself. But, as it seems you want to squabble over "duck type", which is then quite humorous when you accept any random definition someone can dream up for "cast": Why not call what Java is doing duck typing? > I hope you would agree they are essentially the same. I do agree, just as I said before, that Go's type conversions are essentially the same, except checked at compile time rather than run time. There is no conversion with type assertions, however. It is merely a runtime type check. The type you have is the type you keep. Now, what is important to remember is that Go's interface is a structural type. And what is a "structural type" checked at run time? That's right: A duck type! > So TFA could be written in any of those languages It's all just 1s and 0s at the end of the day. Of course you can write something that achieves the same result in just about any language. There is more nuance at play here, though. In the case of Go, it is not "here is another way to achieve the same thing". It literally employs duck typing, as duck typing is normally understood.

randomdata 2y ago

> Surely that's not the first time you've heard of run-time type casts? Indeed – and for good reason, I'm sure. Pedantically, a cast is where the programmer says in a language "just trust me on what type this is, don't bother to check my claim". A runtime type cast doesn't make any sense. I mean, I'm fine with words evolving and whatnot. I'm not here actually trying to play language police myself. But, as it seems you want to squabble over "duck type", which is then quite humorous when you accept any random definition someone can dream up for "cast": Why not call what Java is doing duck typing? > I hope you would agree they are essentially the same. I do agree, just as I said before, that Go's type conversions are essentially the same, except checked at compile time rather than run time. There is no conversion with type assertions, however. It is merely a runtime type check. The type you have is the type you keep. Now, what is important to remember is that Go's interface is a structural type. And what is a "structural type" checked at run time? That's right: A duck type! > So TFA could be written in any of those languages It's all just 1s and 0s at the end of the day. Of course you can write something that achieves the same result in just about any language. There is more nuance at play here, though. In the case of Go, it is not "here is another way to achieve the same thing". It literally employs duck typing, as duck typing is normally understood.