[moritzwarhier]

I have a stupid question (web dev, but also have used Java and C#).

TypeScripts type system is commonly described as implementing "structural types" (not "duck" typed)

And there are a ton of pragmatically sound gotchas around this, such as the importance of whether an object is used as an argument or a parameter, or if it is declared using an object literal.

(focusing on objects here because for primitives I'd assume that TS has almost nominal typing)

So, is there an ELI5 for the difference between structural typing and duck typing?

I'd guess that duck typing is more similar to the callee perspective in TS (give me an object with the properties I need), while structural typing is more similar to the checks performed when initializing an object literal with a declared type?

But I'm not sure if I'd be able to differentiate both terms succinctly.

What is the relationship between duck typing and "type narrowing"? Or is that more of a "structural typing" thing?

[neonsunset]

> So, is there an ELI5 for the difference between structural typing and duck typing?

Likely just semantics. You could argue that the sliver of difference is just treating something like a particular API shape hence duck typing over structurally matching to an interface. For practical purposes however it does not matter. The runtime vs compile time argument is purely an implementation detail that has no relation to structural matching aka duck typing (heh) otherwise.

In practice, I find this idea rather uncomfortable and C# has been avoiding it except for few very defined cases that are least likely to cause this confusion, like GetEnumerator and Enumerator.MoveNext+Current (it could be used as an enumerable in foreach loops but unless the type implements IEnumerable, you can't coerce it to the type).

For the cases where specialization is needed, it is usually written as

     // could also be Handle<T> where T: IDataArg to avoid boxing for structs
     // as struct generics in .net are zero-cost via monomorphization

     void Handle(IDataArg arg) {

         if (arg is IPooledArg pooled) {
             var rented = arg.Rent();
             // do something with the arg
             rented.Return();
         }

         // slow path
     }

No type confusion is possible as whatever is passed to the method has to declare it implements IDataArg. Same applies to 'arg' being 'IPooledArg' - it could have methods with names that would make it match the interface structurally but this is, quite literally, not a type-safe assumption. The authors may have explicitly decided not to expose it, or to provide explicit interface implementation that differs from pre-existing names.

All this is very upfront and you won't be finding yourself having to rename methods or be surprised when your objects or structs are used in a way they are not supposed to because their triangle-shaped type happened to fit in a square-shaped interface hole.

[moritzwarhier]

Thanks for your reply.

I think I share your perception of ugliness in TS.

It feels like in TS, most if not all of the worries around complex types originate in compromises like this, or in other words, structural/duck typing.

Also feels a bit like functions are an elephant in the room. Function types with structural typing for parameters, arguments and return values are useful.

But then you have to use overloads and "extends" in generics for the first time in order to *describe* something, and if you're like me, you might cry a little from the inside. Especially when you simultaneously chastise yourself for wasting time on ignorable TS issues.

[randomdata]

> So, is there an ELI5 for the difference between structural typing and duck typing?

While similar, structural typing is seen statically (think compile time), duck typing is seen dynamically (think run time).

[moritzwarhier]

Thanks, this makes sense, TS type narrowing only works with information known at compile-time (even when using runtime constructs for type narrowing).

So I will go on to imagine duck-typing as the classic JS way where functions started with often pretty extensive runtime checks of their parameter values.

I guess this also means that duck-typing is inherently tied to checking primitive types and/or object structures, return values etc at runtime.

[ljm]

In TS you can have two types, say:

    type A = { a: string; b: string }
    type B = { a: string; b: string; c: string }

If you created a new object like this:

    { a: “foo”, b: “bar”, c: “baz” }

It would satisfy both type A and type B.

That won’t work quite so easily in go without messing around a bit.

[mariusor]

I'm using something like this in one of my Go projects and I created explicit functions to allow programmers to use the larger type where the smaller one is required, which is normally disallowed by the language, by employing some cludgy unsafe package use and based on the assumption that the memory layout for the two types looks identical for the common "a" and "b" properties.

So far it hasn't bitten me in the behind, but I wouldn't advise anyone to use that logic for production code.

[randomdata]

Go structs are nominally typed, so that is beyond the topic of structural/duck typing. Only the interface is structurally typed.

The difference between structural typing and duck typing is that one is evaluated at compile time, while the other at runtime. Typescript is erased before runtime, so it by itself does not exhibit duck typing features, although Javascript does.