On 02/10/2018 07:35 AM, Timon Gehr wrote:

TL;DR: Parametrically polymorphic functions have /runtime/ type parameters. inout can be interpreted as a dependent function of type "{type y | y.among(x, const(x), immutable(x)) } delegate(type x)" and an inout function can be thought of as a function that takes inout as an argument and produces the function as the return value. This formulation is more powerful than what the inout syntax can capture, and this is what causes problems with type safety. In particular, 'inout' does not support proper lexical scoping.

TS;NM: https://gist.github.com/tgehr/769ac267d76b74109a195334ddae01c3 (Some version of this was originally intended to go to the D blog, but I wanted to wait until inout has an obviously type safe definition. It also highlights other inout issues than just type unsafety and shows how all of them might be fixed in principle by adding polymorphism.)


I'll first explain parametric polymorphism, and then what the inout problem is.

Ahh, thanks. I'm still not *completely* 100%, but those explanations definitely helped a lot. Very insightful.

Side questions:

- Does this mean that fixing the issues with inout (even if done via some replacement of inout) would necessarily involve some runtime processing in at least certain cases?

- Though I realize this may contradict the definition of "parametric polymorphism" as you've described (and also ignoring the matter of virtual functions): Would it be theoretically possible to have parametric polymorphism that's *implemented* entirely via compile-time mechanisms such as templates? Or does our template system as D has it already represent the fundamental limits of such an approach?

Incidentally, I've felt for a long while it would've been really nice if D had first-class types (for both runtime and compile time). I think a system like that, if done right, could have gone a long way to alleviating all the awkwardness and asymmetries of reflection and type handling in D. It's also why I can understand people coming from certain dynamic languages who may find our metaprogramming combersome.

Reply via email to