Duck typing (horror) in Go

An example is in the errors package: https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/...

  template<typename T> concept CanDouble = requires(T t) {t + t; t * 2;};

  template<CanDouble F> auto foo(F t) {return t + t;}
  template<typename B> auto bar(B t) {return t + t;}

Note that in this example, foo(std::string{"abc"}) will not compile, because string doesn't satisfy all the properties of CanDouble, even though the property it doesn't satisfy isn't actually used by foo. In other words, strings don't have the structure described by CanDouble. However, bar(std::string{"abc"}) does compile, because strings can be added to strings in C++, and B is only restricted by how it's used in bar. In other words strings "walk like a duck", so they're a duck.

Yes -- supporting structural typing + also runtime casts means you support duck typing.

That's not duck typing, though. It's similar but not the same.

With duck typing there isn't an interface to cast to, but the runtime object has a method matching the one being called. If you're casting, then it's not real duck typing.

People often imagine a "metaclass" or "meta-interface" for each method to help understand how duck typing works, but it's just a mental model to understand the concept. In reality there is no interface tying the methods together, and the whole thing is done at runtime, along with a runtime error if the method doesn't exist.

    public interface ISwim { void Swim(); }

    public interface IQuack { void Quack(); }

    public interface IDuck extends ISwim, IQuack { }

    public class Mallard implements IDuck {
        public void Swim() { System.out.println("mallard swimming"); }
        public void Quack() { System.out.println("mallard quacking"); }
    }

    public class Dog implements ISwim {
        public void Swim() { System.out.println("dog swimming"); }
        public void Bark() { System.out.println("dog barking"); }
    }

    public static void quack(Object... ducks) {
        for (Object duck: ducks) {
            ((ISwim)duck).Swim();
            ((IQuack)duck).Quack();
        }
    }

    public static void main() {
        quack(new Mallard(), new Dog());
    }

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
     }

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.

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

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

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

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

The article is about how it does support duck typing in the usual sense. Why do you disagree?