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