On Thu, Jan 17, 2019 at 10:20:24PM +0000, Stefan Koch via 
Digitalmars-d-announce wrote:
> On Thursday, 17 January 2019 at 19:31:24 UTC, H. S. Teoh wrote:
[...]
> > 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.

YES!  This is the way it should be.  Type-tuples become first class
citizens, and you can pass them around to functions and return them from
functions, the only stipulation being that they can only exist at
compile-time, so it's an error to use them at runtime.

In other words, they become symmetric to other built-in language types,
and can be manipulated by conventional means, instead of being an
oddball exception with special-case behaviour that requires special-case
syntax dedicated to manipulating them.  Again, the root of the problem
is asymmetry, and the solution is to make it symmetric.


> 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.

Exactly.  Yet another problem caused by the asymmetry of type-tuples
w.r.t. other built-in types, and naturally solved by making them
symmetric.


> newCTFE has the facility to be extended for this, and implementing
> type-functions is at least on my personal roadmap.

Awesome.


> 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.

Yes, let's please get the Minimum Viable Product of newCTFE merged into
master first, before we expand the scope (and delay the schedule :-P)
yet again!


[...]
> 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.

Interesting.  Is it possible to assign a "fake" mangle to type functions
that never actually gets emitted into the object code, but just enough
to make various internal compiler stuff that needs to know the mangle
work properly?


T

-- 
Why do conspiracy theories always come from the same people??

Reply via email to