B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
H. S. Teoh
hsteoh at quickfur.ath.cx
Thu Jan 17 22:44:08 UTC 2019
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
> 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
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)
> 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
Why do conspiracy theories always come from the same people??
More information about the Digitalmars-d-announce