Which language futures make D overcompicated?
Nick Sabalausky (Abscissa)
SeeWebsiteToContactMe at semitwist.com
Mon Feb 12 03:03:05 UTC 2018
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.
More information about the Digitalmars-d
mailing list