I dun a DIP, possibly the best DIP ever

Walter Bright newshound2 at digitalmars.com
Fri Apr 24 20:55:19 UTC 2020


On 4/24/2020 10:10 AM, Steven Schveighoffer wrote:
> The point of this is to reduce the amount of "trivial" templates. Every time a 
> template is instantiated, it consumes memory in the compiler, it creates more 
> stuff to manage in the symbol tables, and because templates have to "be the 
> same" for every instantiation, you have weird paradoxes.

Surprisingly, I do get this!


> One of the fundamental problems with template power in D is that in order to 
> operate on lists, you need a functional-style recurse or divide and conquer, 
> which multiplies the number of templates needed by possibly hundreds or 
> thousands. This takes time, resources, and can result in things that don't 
> compile or are extremely slow to compile.
> 
> What I think this proposal does is to remove an entire class of recursive 
> templates, and replaces them with simple loops that the compiler can execute 
> blindfolded with 4 cores tied behind its back with ease, faster than the 
> template expansions required by e.g. staticMap.

No argument there.


> I think the ellipsis version is superior simply because it has more expressive 
> power (see my posts elsewhere). An ideal proposal would allow all things to be 
> handled within one expression, but the ellipsis is better in that it is 
> unambiguous and does not break code.

My issue is finding the best way to do this. Adding powerful syntax "just 
because we can" leads to an unusable language. Queue my opposition to AST macros.


> And actually, with a staticIota-like thing you could do every third tuple member 
> quite easily.
> 
> alias everyThird = staticIota!(2, Tup.length, 3); // start, end, step
> 
> alias everyThirdMember = (Tup...[everyThird])...;

Touche. Well done.

Let's not fall into the mode of only looking at the way C++ did it and not 
seeing other ways. C++ has problems (like not having arrays) that lead it in 
different directions for solving array-like problems.

What do other languages do? How are things like this expressed in mathematics?


> staticIota is kind of another primitive that is super-useful, and would be easy 
> for the compiler to provide.

Where does one stop in adding operators to the language?

Another approach to resolving the original problem (template instantiation 
bloat) is for the compiler to recognize templates like AliasSeq as "special" and 
implement them directly.


For example, AliasSeq is defined as:

   template AliasSeq(TList...) { alias AliasSeq = TList; }

This pattern is so simple it can be recognized by the compiler. (Having 
std.meta.AliasSeq being a special name known to the compiler is not necessary.)
The compiler already recognizes certain patterns, such as the expression that 
does a rotate, and then generates the CPU rotate instruction for it.


More information about the Digitalmars-d mailing list