static map as a type function

Stefan Koch uplink.coder at gmail.com
Sat Sep 26 09:56:15 UTC 2020


On Friday, 25 September 2020 at 13:33:29 UTC, Andrei Alexandrescu 
wrote:

> class TypeInfo {
>     ... existing stuff ...
>     TypeInfo addQualifier(string qual);
>     TypeInfo stripQualifier(string qualifier);
>     TypeInfo stripAllQualifiers();
>     bool implicitlyConvertsTo(Typeinfo another);
>     TypeInfo functionReturn(); // null if not a function
>     Typeinfo[] functionParameters(); // null if not a function
> }

having a string for the qualifier isn't great.
I'd much prefer an enum since the qualifier is a rightly bounded 
set of possible values.

Similarly I'd like to avoid polymorphic behavior as much as 
possible.
(It might still have to be polymorphic to work at all, but 
polyorphism should be as you would say 'curtailed' )


> This and a solution to 
> https://issues.dlang.org/show_bug.cgi?id=9945 would impart 
> tremendous power.

The solution in there is polymorphic.
It comes with all the problems of understandably and 
unpredictability that polymorphic "solutions" come with.

One of the reasons why type functions can be fast and easily be 
reasoned about is their non concrete monomorphic interface.

By removing the notion of a concrete interface the interaction 
with the compiler can be more efficient and direct.

And it also allows us to reuse existing language concepts such as 
".sizeof", ".tupleof", ".stringof" on the surface.

By adding the notion of monomorphsim (alias can't convert to any 
other type) we achieve type safety and static checking.

type functions (a misnomer really, because they can work with 
more than just types) are designed to occupy a functional and 
syntactic middle-ground between templates and functions.

perhaps I should rename them to "compiletime entity introspection 
functions" CTEIF, but that acronym is unpronounceable

or I could call them "static template emulating function and 
namespace" STEFAN? :D


More information about the Digitalmars-d mailing list