You can make the same argument for numbers, for an easy exploration. Just look at all of the tools that you can have at your disposal by thinking of things as numbers.
Anyway, row polymorphism can technically be used with nominal typing, it's just that it usually makes sense to use structural typing instead.
The key benefit of row polymorphism is a bit of an implementation detail - it lets you get something resembling (a limited form of) subtyping in your language, without needing as complicated a type inference algorithm as fully-general subtyping requires.
Row polymorphism can be (IMO should usually be) made opt-in, so you can avoid problems like the scenario you describe.
let point = (x = 5, y = 7)
let point3d = point.Point3d(z = 0)
More here: https://www.firefly-lang.org/
The project also supports tuples that behave similarly.
var person = (name: "Joe", age: 35);
. . .
Person p = person; // tuple's name, age properties satisfy Person record
You could go further with variant structural typing, basically this is a broader form of type checking based on call compatibility, which answers the question -- is B#foo() callable as an A#foo()?
For instance, your `area` example requires `double` result types, otherwise a row type having `width` and `length` defined as `integer` columns doesn't satisfy `area`. But, result types are naturally covariant -- `integer` is a subset of `double` -- which permits us to accept `integer` in the implementation of `area`.
Similarly, parameter types are naturally contravariant -- `Shape` is contravariant to `Triangle`, thus `B#foo(Shape)` is call-compatible as a `A#foo(Triangle)`, therefore I can pass a Triangle to `B#foo(Shape)`.
The manifold project[1] for Java is one example where the type system is enhanced with this behavior using structural interfaces.
Note, this goes further with parametric types where function result types and parameter types define variance and other constraints.
skybrian•3h ago
tines•2h ago
wavemode•1h ago
This utilizes the fact that structs implement interfaces implicitly in Go, rather than explicitly.
> I'm also wondering what the difference between row-polymorphism and ad-hoc polymorphism (a la C++ templates) is
C++ templates can also be row-polymorphic. They're a lot more flexible than just row polymorphism, though, because they essentially allow you to be polymorphic over any type for which a given expression is valid syntax.
Concepts were an attempt to allow developers to rein in some of that flexibility, since it actually became a pain.
skybrian•51m ago
jerf•49m ago
It doesn't have it yet. Go is headed strongly in that direction which is why I add the "yet", but see https://github.com/golang/go/issues/70128 , especially the "future directions" note about issue #48522 which is not implemented. Prepatory work has been done but the change is not in yet.
You can embed something like compile-time row types into Go if you implement it in terms of accessor methods that can be included in an interface, rather than direct struct field access, which has its pros and cons.
But if you're reading this in 2026 or beyond, check in with Go, this may not be true anymore.
ryandv•2h ago
The AI will produce functionally equivalent code at a tenth of the cost, without needing to hire somebody who studied high-falutin computer science concepts like "polymorphism."
aatd86•1h ago
I actually believe otherwise, AI risks fossilizing our programming languages expressiveness and developper experience, shunting any possibility of improvements that is not envoded in its data set.
I think that for tools made for human consumption, AI is always going to be limited (even AGI). A case of "for us by us" is necessary.
Unless humans completely delegate the machine coding to machines and we only remain with a few legacy systems, never inspecting new machine instruction corpus. Inthe future that is.
jerf•47m ago
They may need and/or prefer different ones than we do, but this stuff isn't going to go away. Your need to understand it may, but then, most programmers don't understand this and do OK anyhow.
aatd86•1h ago
tines•1h ago
sparkie•57m ago
A difference with row types is that they don't have to be declared up front like an interface - they're basically anonymous types. You declare the row types in the type signature.
For example, a function taking some structural subtype of `Foo` and returning some structural subtype of `Bar` would be written in Go as:
In OCaml, you'd just inline the row types - there are no `Foo` or `Bar`: You can typedef row types though Rows can be declared to have an exact set of members. For example, the types `< bar : Baz.t >` and `< bar : Baz.t; ..>` are two different types. The latter can have members besides `bar`, but the former can only have the member `bar`. A type containing the fields `bar` and `qux` would be a subtype of `< bar : Bar.t; .. >`, but it would not be a subtype of `< bar : Bar.t >`.OCaml has another form of structural typing in its module system, closer to interfaces where a `module type` is declared up-front, and can be specified as the argument for a functor (parameterized module) - but this is incompatible with the row types in the object system.