this is a bit convoluted, but I think that gca_const_items is the only feature that would allow actually doing any calculation dependent on generic params? e.g. [S; T::N + U::N] mentioned in the sibling comment would require that, because otherwise you can’t do any calculation in gca!().
I’m a bit unsure about usecase for gca_min_const_items, it would be nice to have a more practical example.
The explanation why the macro is necessary seems tautological - certain syntax won't work without the macro or macro-equivalent sugar, because it requires the macro. But why!?
I presume the macro has been invented as a hack to prototype the feature, and now the implementation is stuck with it, but what's the theoretical type system problem that prevents a clean hack-less implementation?
And why isn't existing {} or const {} sufficient? I thought this syntax has been reserved for const-evaluated values in types.
gspr | 9 hours ago
I can't wait to write stuff like in the examples, especially things like
[S; T::N + U::N]. Been wanting this since the second const generics hit.goldstein | 8 hours ago
this is a bit convoluted, but I think that
gca_const_itemsis the only feature that would allow actually doing any calculation dependent on generic params? e.g.[S; T::N + U::N]mentioned in the sibling comment would require that, because otherwise you can’t do any calculation ingca!().I’m a bit unsure about usecase for
gca_min_const_items, it would be nice to have a more practical example.kornel | 5 hours ago
The explanation why the macro is necessary seems tautological - certain syntax won't work without the macro or macro-equivalent sugar, because it requires the macro. But why!?
I presume the macro has been invented as a hack to prototype the feature, and now the implementation is stuck with it, but what's the theoretical type system problem that prevents a clean hack-less implementation?
And why isn't existing
{}orconst {}sufficient? I thought this syntax has been reserved for const-evaluated values in types.