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