On Thursday, 17 January 2019 at 19:31:24 UTC, H. S. Teoh wrote:
On Thu, Jan 17, 2019 at 06:03:07PM +0000, Paul Backus via
Digitalmars-d-announce wrote: [...]
[2]
https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/
[...]
Coming back to the D example at the end, I totally agree with
the sentiment that D templates, in spite of their significant
improvements over C++ syntax, ultimately still follow the same
recursive model. Yes, you can use CTFE to achieve the same
thing at runtime, but it's not the same thing, and CTFE cannot
manipulate template argument lists (aka AliasSeq aka whatever
it is you call them). This lack of symmetry percolates down
the entire template system, leading to the necessity of the
hack that Bartosz refers to.
Had template argument lists / AliasSeq been symmetric w.r.t.
runtime list manipulation, we would've been able to write a
foreach loop that manipulates the AliasSeq in the most readable
way without needing to resort to hacks or recursive templates.
For 2 years I have pondered this problem, and I did come up with
a solution.
It's actually not that hard to have CTFE interact with
type-tuples.
You can pass them as function parameters, or return them if you
wish.
Of course a type-tuple returning ctfe function, is compile-time
only.
This solved one more problem that ctfe has:
helper functions required for ctfe can only be omitted from the
binary, if you use the trick of putting them into a module which
is the import path but never explicitly given on the command line.
newCTFE has the facility to be extended for this, and
implementing type-functions is at least on my personal roadmap.
At Dconf 2018 Andrei and Walter said, a DIP which is
substantiated enough might make it.
However due to lack of time, (and productivity-reducing internal
changes) it will take some time until I can get started on this.
Also I plan for newCTFE to be in shape before I add
type-manipulation abilities.
Cheers,
Stefan
P.S. There is one caveat: because of how type-functions work they
cannot, you cannot create a non-anonymous symbol inside a
type-function, because there is no way to infer a mangle.
You can however create an anonymous symbol and alias it inside a
template body, which gives it a mangle and it can behave like a
regular symbol.
