New blog post on the cost of compile time

H. S. Teoh hsteoh at qfbox.info
Tue Jan 17 21:58:45 UTC 2023


On Sun, Jan 15, 2023 at 11:30:25PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> https://www.schveiguy.com/blog/2023/01/the-cost-of-compile-time-in-d/
[...]

Honestly, I find templates like ReturnType in std.traits a bit of a code
smell. Same thing as Parameters, and a whole bunch of others.  Yes, it
has a pretty-sounding name, and yes, you get to avoid writing that
squint-inducing __traits(...) syntax, but if you take a step back, it
just begs the question, why can't we do this directly in the language
itself?

You pointed out that there are various reasons for it -- no easy way of
getting an instance of the type, need to handle different kinds of
callables, etc., but to me, those are all merely circumstantial issues.
It begs the question, why *isn't* there a construct to obtain an
instance of some type T (even if hypothetical, for the purposes of
introspection)?  After all, the compiler knows T inside-out, and ought
to be able to cook up a (virtual) instance of it.

The crux of the problem is that the in spite of D's metaprogramming
prowess being often promoted, the language *itself* doesn't let you do
certain common things easily.  It lets you use, e.g., typeof() in
certain cases, but in other cases you need this or that workaround or
paraphrasis, and so another std.traits wrapper template is born.  If the
language had instead been extended so that you could, for example,
extract the return type of some given callable directly, say
typeof(return(myfunc)), then none of this would have been necessary in
the first place.

Having wrappers in Phobos for doing certain things makes sense when a
particular feature or introspective capability is still new / newly
discovered: it wasn't anticipated so the language doesn't have a
construct to express it directly, so a Phobos template helps to wrap it
up in a nicer, more friendly and usable form for end users to use.  But
once a particular construct has become recurrent and a standard part of
D idiom, it deserves to be baked into the language directly. Especially
when doing so eliminates a lot of the collateral costs.


T

-- 
What's an anagram of "BANACH-TARSKI"?  BANACH-TARSKI BANACH-TARSKI.


More information about the Digitalmars-d mailing list