5 ms·
By common definition, structural typing and duck typing end up being the exact same thing, apart from where they are evaluated. With duck typing obviously being
by randomdata 2y ago
By common definition, structural typing and duck typing end up being the exact same thing, apart from where they are evaluated. With duck typing obviously being evaluated dynamically, and structural typing being evaluated statically. Therefore, "compile time duck typing" is more commonly known as structural typing.
Consider the following in a hypothetical language that bears a striking similarity to Typescript. I will leave you to decide if that was on purpose or if it is merely coincidental.
interface Comparable { isGreaterThan(other: Comparable): boolean }
function max(a: Comparable, b: Comparable) { return a.isGreaterThan(b) ? a : b }
As usually defined, if this language accepts any type with an isGreaterThan method as a Comparable, it would be considered an example of structural typing. Types are evaluated based on their shape, not their name. This is the canonical example of structural typing! Ignore the type definitions and you get the canonical example of duck typing!!
Now, what if we rewrite that as this?
interface Comparable { >(other: Comparable): boolean }
function max(a: Comparable, b: Comparable) { return a > b ? a : b; }
Staring to look familiar? But let's go further. What if the interface could be automatically inferred by the type checker?
function max<interface Comparable>(a: Comparable, b: Comparable) { return a > b ? a : b; }
That is looking an awful lot like:
template<typename T> T max(T &a, T &b) { return a > b ? a : b; }
Of course, there is a problem here. Under use, the following will fail in the C++ version, even though both inputs "quack like a duck". The same code, any syntax differences aside, will work in our hypothetical language with structural typing.
int x = 1;
float y = 1.0;
max(x, y);
So, yes, you're quite right that your example is not a display of structural typing. But it is also not a display of duck typing (of some compile time variety or otherwise) either. Here, "quacking" is not enough to satisfy the constraints. In order to satisfy the constraints the types need to have the same name, which violates the entire idea behind duck typing.
Which is all to say: Your confusion stems from starting with a false premise.
- samatman 2y agoThe rhetorical slight of hand you're engaging in here is simple: you're starting with a language in which 1 and 1.0 quack, and then swapping in a language in which 1 and 1.0 do not quack, and hoping, perhaps, that I won't notice? Anyway, your confusion may be easily resolved by perusing the following link. https://en.wikipedia.org/wiki/Duck_typing#Templates_or_generic_types https://en.wikipedia.org/wiki/Duck_typing#Templates_or_gener...
- randomdata 2y ago> and then swapping in a language in which 1 and 1.0 do not quack Except, no. This compiles and evaluates just fine in C++. Both quack the same quack. int x = 1; float y = 1; x > y; The previously provided code fails because of the use of typename, which explicitly calls for the compiler to evaluate the type based on name. That is literally the documented purpose of the keyword. And which is exactly what duck typing is not. Duck typing doesn't need a duck to actually be a duck. If a goose walks and quacks like a duck... Close enough — it is a duck! > Anyway, your confusion may be easily resolved by perusing the following link. Imagine having such little understanding of what you are talking about that you can't do it and have to defer to the work of others. Why even bother participating in a discussion if you can't speak to it yourself? It is especially humorous when that work of someone else doesn't even state what it is purported to.