Shin Fujishiro's std.meta has the features.

https://github.com/sinfu/phobos-sandbox

I think that module has been almost completed, but the contact with
him has been interrupted.
(I want to merge it, and it is licensed under the Boost License, but I
doubt I will do it without his reply.)

Kenji Hara

2011/9/4 David Nadlinger <see@klickverbot.at>:
> As we currently aren't reviewing anything (We still need a review manager for David's RegionAllocator or whatever we decide to receive next? Do you want to get things going Jonathan? Should I do it again? Anybody else?), I thought I would take the opportunity to ask for comments on a few little template metaprogramming helpers:
>
> https://gist.github.com/1191885
>
> Besides a few helpers for manipulating/combining template predicates, the above link contains three main:
>
> StaticFilter – like std.algorithm.filter, but for type tuples using template
> predicates.
> PApply – like the unluckily named std.functional.curry, but for template
> parameters
> Compose - alias Compose!(A, B, C) Comp; // Comp!D is now A!(B!(C!D)).
>
> I had originally whipped these up on the fly while working on some metaprogramming-heavy code, but they have proven useful in other projects as well. What do you think? Would some of these be worthy additions to Phobos? Do you have similar stuff lying around in your own code?
>
> Thanks,
> David
>

On 09/05/2011 02:14 AM, kenji hara wrote:
> Shin Fujishiro's std.meta has the features.
>
> https://github.com/sinfu/phobos-sandbox
>
> I think that module has been almost completed, but the contact with
> him has been interrupted.
> (I want to merge it, and it is licensed under the Boost License, but I
> doubt I will do it without his reply.)
>
> Kenji Hara

And this will have to be fixed:

"All members in this module are defined in the $(D meta) namespace and cannot be used without the $(D meta) qualifier:"

Users can do the renamed import themselves if they wish to, the module should not enforce it.

On 9/5/11 2:14 AM, kenji hara wrote:
> Shin Fujishiro's std.meta has the features.
>
> https://github.com/sinfu/phobos-sandbox

Oh, wow, so now (largely) the same functionality has been implemented at least three times, in Shin Fujishiro's std.meta, in Philippe Sigaud's dranges, and by myself – I guess we should really do something about this to avoid reinventing the wheel over and over again.

Luckily, all the code is Boost-licensed, so I think I will just throw the best ideas from each implementation into a big bowl (for example, I really like Shin's approach to emulating template literals with strings) and cook up a module fit for submission to the Phobos review process.

Thus, it would be great if you could let me know what you would like to see as far as metaprogramming is concerned, besides common higher-order templates like Map/Reduce/Filter, general helpers like Compose/PApply/Switch/Iota and the low-level helpers for working around quirks in the language (think checking identity for arbitrary symbols/types/ct values, being able to alias both types and values, …).

High on my list of not yet implemented ideas is wrapping __traits: templates obviously won't be able to handle some of the strange semantics e.g. of the isArithmetic family of traits, but the »raw« __traits interface suffers from impedance mismatch with higher-order templates.

David

On Sun, 04 Sep 2011 19:46:45 -0400, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Simen Kjaeraas (simen.kjaras@gmail.com)'s article
>> StaticFilter definitely should be in Phobos. StaticReduce too, but you
>> don't seem to have it on your list. I also often use StaticIota.
>> For more handy templates I feel should be in Phobos, see
>> Philippe Sigaud's dranges:
>> http://www.dsource.org/projects/dranges
>> -- =
>>    Simen
>
> Seconded.  StaticIota is extremely useful for loop unrolling optimizations, e.g.:

vote++

On 09/05/2011 03:31 AM, David Nadlinger wrote:
> On 9/5/11 2:14 AM, kenji hara wrote:
>> Shin Fujishiro's std.meta has the features.
>>
>> https://github.com/sinfu/phobos-sandbox
>
> Oh, wow, so now (largely) the same functionality has been implemented at
> least three times, in Shin Fujishiro's std.meta, in Philippe Sigaud's
> dranges, and by myself – I guess we should really do something about
> this to avoid reinventing the wheel over and over again.
>
> Luckily, all the code is Boost-licensed, so I think I will just throw
> the best ideas from each implementation into a big bowl (for example, I
> really like Shin's approach to emulating template literals with strings)
> and cook up a module fit for submission to the Phobos review process.
>
> Thus, it would be great if you could let me know what you would like to
> see as far as metaprogramming is concerned, besides common higher-order
> templates like Map/Reduce/Filter, general helpers like
> Compose/PApply/Switch/Iota and the low-level helpers for working around
> quirks in the language (think checking identity for arbitrary
> symbols/types/ct values, being able to alias both types and values, …).

Is that the correct level for addressing quirks in the language?

>
> High on my list of not yet implemented ideas is wrapping __traits:
> templates obviously won't be able to handle some of the strange
> semantics e.g. of the isArithmetic family of traits, but the »raw«
> __traits interface suffers from impedance mismatch with higher-order
> templates.
>
> David

Robert Jacques:

> > Seconded.  StaticIota is extremely useful for loop unrolling optimizations, e.g.:
> 
> vote++

vote--

StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085

Bye,
bearophile

On Mon, 05 Sep 2011 13:05:23 +0200, bearophile <bearophileHUGS@lycos.com> wrote:

> Robert Jacques:
>
>> > Seconded.  StaticIota is extremely useful for loop unrolling  
>> optimizations, e.g.:
>>
>> vote++
>
> vote--
>
> StaticIota is not the good solution. I have explained why elsewhere:
> http://d.puremagic.com/issues/show_bug.cgi?id=4085

Certainly we could sit in a corner and pray to almighty Walter that this be
implemented, when he's done with the things he wants to do with D. Oooor - we
could add StaticIota to Phobos, bypass the problem, and live happily ever after.

Yes, static foreach would be nice, but the means to do what it would do, are
easily implemented in the language as is.

-- 
  Simen

On 09/05/2011 07:31 PM, Simen Kjaeraas wrote:
> On Mon, 05 Sep 2011 13:05:23 +0200, bearophile
> <bearophileHUGS@lycos.com> wrote:
>
>> Robert Jacques:
>>
>>> > Seconded. StaticIota is extremely useful for loop unrolling
>>> optimizations, e.g.:
>>>
>>> vote++
>>
>> vote--
>>
>> StaticIota is not the good solution. I have explained why elsewhere:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4085
>
> Certainly we could sit in a corner and pray to almighty Walter that this be
> implemented, when he's done with the things he wants to do with D. Oooor
> - we
> could add StaticIota to Phobos, bypass the problem, and live happily
> ever after.
>
> Yes, static foreach would be nice, but the means to do what it would do,
> are
> easily implemented in the language as is.
>

That is some heavy C++ design style reasoning.

2011/9/6 Simen Kjaeraas <simen.kjaras@gmail.com>:
> On Mon, 05 Sep 2011 13:05:23 +0200, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> Robert Jacques:
>>
>>> > Seconded.  StaticIota is extremely useful for loop unrolling optimizations, e.g.:
>>>
>>> vote++
>>
>> vote--
>>
>> StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085
>
> Certainly we could sit in a corner and pray to almighty Walter that this be
> implemented, when he's done with the things he wants to do with D. Oooor -
> we
> could add StaticIota to Phobos, bypass the problem, and live happily ever
> after.
>
> Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is.

Agreed to Simen. The foreach statement already has loop unrolling feature. To use it, we can pass a compile-time sequence (like TypeTuple) as its aggregator.

I think it is clear language design, and not need more. Then we need staticIota.

Kenji Hara

Simen Kjaeraas:

> Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is.

Notes:
- I am not asking for a real static foreach. The main point of bug 4085 is that that even half static foreach is better than the current situation.
- "static foreach" is also a way to better document what the code is doing. I sometimes add /*static*/ before foreach to increase readability.
- Some purposes/use cases of static foreach are not covered by a staticIota.

Bye,
bearophile