www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - UCFS for compile-time sequences

reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
After quick discussion with Walter last weekend, I'd like to 
propose the following adition to D syntax.

**Problem**

We do have UCFS for run-time sequences: 
`some_array.filter!my_filter.map!my_transform`. However we don't 
have such capability for compile-time sequences and one has to 
write the similar thing using old style `StaticMap!(my_transform, 
Filter!(my_filter, sequence))` or "temp variables".

**Suggestion**

Add new operator `.!` (just an idea - please suggest more 
appropriate name) so `A.!B!C` expression becomes `B!(C,A)`.

Applying it to the example above:
```d
StaticMap!(my_transform, Filter!(my_filter, sequence))
// can be replaced with:
sequence.!Filter!my_filter.!StaticMap!my_transform
```

PS I didn't think a lot about this - just wanted to share the 
idea.
Apr 15
parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 15 April 2026 at 23:33:15 UTC, Andrey Zherikov 
wrote:

 After quick discussion with Walter last weekend, I'd like to 
 propose the following adition to D syntax.

 **Problem**

 We do have UCFS for run-time sequences: 
 `some_array.filter!my_filter.map!my_transform`. However we 
 don't have such capability for compile-time sequences and one 
 has to write the similar thing using old style 
 `StaticMap!(my_transform, Filter!(my_filter, sequence))` or 
 "temp variables".

 **Suggestion**

 Add new operator `.!` (just an idea - please suggest more 
 appropriate name) so `A.!B!C` expression becomes `B!(C,A)`.

 Applying it to the example above:
 ```d
 StaticMap!(my_transform, Filter!(my_filter, sequence))
 // can be replaced with:
 sequence.!Filter!my_filter.!StaticMap!my_transform
 ```

 PS I didn't think a lot about this - just wanted to share the 
 idea.


I like it in the sense that metaprogramming feels like a 2nd 
class citizen, but why a new operator?

OTOH I wonder if we should pivot to more CTFE instead.
May 11
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 11 May 2026 at 08:49:54 UTC, Atila Neves wrote:

 OTOH I wonder if we should pivot to more CTFE instead.


There was an attempt to enable CTFE for many template 
metaprogramming aspects. The idea is to consider types 
first-class objects at CTFE, allowing you to have arrays of 
types, etc.

Zig really ran with this.

Even C++ is getting there with C++26’s reflection.
May 13
next sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 13 May 2026 at 16:29:50 UTC, Quirin Schroll wrote:

 On Monday, 11 May 2026 at 08:49:54 UTC, Atila Neves wrote:

 OTOH I wonder if we should pivot to more CTFE instead.


 There was an attempt to enable CTFE for many template 
 metaprogramming aspects. The idea is to consider types 
 first-class objects at CTFE, allowing you to have arrays of 
 types, etc.


There was Andrei's reify/process/dereify work:
https://forum.dlang.org/post/rknpkj$d7f$1 digitalmars.com

`__traits(toType, mangleString)` [got 
merged](https://dlang.org/spec/traits.html#toType), but IIRC 
using that with the above didn't perform better than `std.meta`, 
not 100% sure though (I can't find a link to confirm that).
May 13
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 13 May 2026 at 16:29:50 UTC, Quirin Schroll wrote:

 On Monday, 11 May 2026 at 08:49:54 UTC, Atila Neves wrote:

 OTOH I wonder if we should pivot to more CTFE instead.


 There was an attempt to enable CTFE for many template 
 metaprogramming aspects. The idea is to consider types 
 first-class objects at CTFE, allowing you to have arrays of 
 types, etc.


I really, really like this.
May 18