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