<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 4, 2020 at 9:35 PM Stefan Koch via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As part of my series of templates<br>
I have done a a full instantiation of Iota!(1,5).<br>
(By hand!)<br>
And here is the result:<br>
<br>
Iota!(1,5)<br>
{<br>
{<br>
alias Iota = Seq!(1, Iota!(1 + 1, 5));<br>
}<br>
Seq!(1, Iota!(1 + 1, 5))<br>
{<br>
alias Seq = (1, Iota!(1 + 1, 5));<br>
Iota!(1 + 1, 5) => Iota!(2, 5)<br>
{<br>
alias Iota = Seq!(2, Iota!(2 +1, 5));<br>
}<br>
Seq!(2, Iota(2 + 1, 5))<br>
{<br>
alias seq = (2, Iota!(2 + 1, 5))<br>
Iota!(2 + 1, 5) => Iota!(3, 5)<br>
{<br>
alias Iota = Seq!(3, Iota!(3 +1, 5));<br>
}<br>
Seq!(3, Iota!(3 + 1, 5))<br>
{<br>
alias Seq = (3, Iota!(3 + 1, 5));<br>
Iota!(3 + 1, 5) => Iota!(4, 5)<br>
{<br>
alias Iota = Seq!(4, Iota!(4 +1, 5));<br>
Seq!(4, Iota!(4 + 1, 5))<br>
{<br>
alias seq = (4, Iota!(4 + 1, 5));<br>
Iota!(4 + 1, 5) => Iota!(5, 5)<br>
{<br>
{<br>
alias Iota = Seq!();<br>
{ Seq!() => () }.Seq => ()<br>
}<br>
}.Iota => Seq!()<br>
}.Seq => (4, Seq!())<br>
}.Iota => (3, Seq!(4, Seq!())<br>
}.Seq => (3, Seq!(4, Seq())))<br>
}.Seq => (2, (Seq!(3, Seq!(4, Seq!()))))<br>
}.Seq => (1, Seq!(2, Seq!(3, Seq(4, Seq!())))))<br>
}.Iota => (1, Seq!(2, Seq!3, Seq!4, Seq!()))))))<br>
<br>
Because it has been done manually there are probably some bugs.<br>
Can you find them all?<br></blockquote><div><br></div>Iota should be this:<div>`tuple(x .. y)` (assuming 1st-class tuples existed), or in the current language: `AliasSeq!(x .. y)`, which is syntactically invalid, but something like this really should exist.</div><div><br></div><div>Your example expansion above looks kinda broken, but it makes the point... I feel like D is currently awakening to a similar reality as the C++ dark-ages period in the mid 00's, where templates were 'discovered', books were written (by popular authors), and the worst C++ code and patterns ever written came into existence. The reaction for many of us at that time (especially in video games/embedded systems) was to ban C++ completely and revert to C for a decade until such a later time that we could be trusted again.</div><div><br></div><div>This is essentially D's manifestation of the same negligence, and I think it's time to own it and move forward.</div><div>I think there are a few obvious solutions:</div><div>1. My `...` operator DIP, map/reduce patterns are extremely common and responsible for much/most explosive template bloat</div><div>2. Recognise that templates are NOT FOR EXECUTING CODE; templates are for parameterisation of definitions.</div><div><br></div><div>There is a painfully obvious tool for executing code; functions, made up of a series of statements.</div><div>The rule of least-surprise should surely dictate that when people want to perform calculations or generate a result, they should use a function.</div><div>Sadly, functions don't work in static contexts like with types or aliases... so in D, meta with such results can only be written awkwardly with templates.</div><div>There has been discussion of type functions on and off for ages, and Stefan has recently demonstrated some concrete progress on this front... I think that's the way forward. It is the path that will lead us from the dark instantiation-bloat forest that D finds itself in today. It will be clearer, saner, and faster. A new D user will find a type function intuitive, and will never have to poison their mind with awkward FP-style recursive template expansions with weird edges and considerations.<br></div></div></div>