It seems that DMD already interprets some foreach's at compiletime if the argument is known at compile time:

eg:

	string FooString()
	{
		string stuff = "";
		foreach(member, __traits( allMembers, moduleName)
		{
			stuff ~= member;
		}
		return stuff;
	}

mixin(FooString());

However, for non-string templates.   They have to be written in a recursive form, which can be particularly difficult in some cases.

	template FooTemplate()  //This code is totally made up and not meant to do anything useful, or necessarily be valid.
	{
		auto FooTemplate = TypeTuple!()
		static foreach(member, __traits( allMembers, someClass)
		{
			FooTemplate = TypeTuple!(FooTemplate, __traits(getMember, someClass, member));
		}
	}

What's the consensis on something like this?

On Sun, Nov 24, 2013 at 6:40 PM, Shammah Chancellor <anonymous@coward.com> wrote:


> However, for non-string templates.   They have to be written in a recursive form, which can be particularly difficult in some cases.
>
>         template FooTemplate()  //This code is totally made up and not meant
> to do anything useful, or necessarily be valid.
>         {
>                 auto FooTemplate = TypeTuple!()
>                 static foreach(member, __traits( allMembers, someClass)
>                 {
>                         FooTemplate = TypeTuple!(FooTemplate,
> __traits(getMember, someClass, member));
>                 }
>         }
>
> What's the consensis on something like this?

The consensus might well be 'use recursion' :) That's what I'd do in your case. CT computation on types is a lot like functional programming: recursion and immutability.

Another solution would be to construct you type as a string, and then mix it in.

On Sunday, 24 November 2013 at 19:42:21 UTC, Philippe Sigaud wrote:
> On Sun, Nov 24, 2013 at 6:40 PM, Shammah Chancellor
> <anonymous@coward.com> wrote:
>
>
>> However, for non-string templates.   They have to be written in a recursive
>> form, which can be particularly difficult in some cases.
>>
>>         template FooTemplate()  //This code is totally made up and not meant
>> to do anything useful, or necessarily be valid.
>>         {
>>                 auto FooTemplate = TypeTuple!()
>>                 static foreach(member, __traits( allMembers, someClass)
>>                 {
>>                         FooTemplate = TypeTuple!(FooTemplate,
>> __traits(getMember, someClass, member));
>>                 }
>>         }
>>
>> What's the consensis on something like this?
>
> The consensus might well be 'use recursion' :) That's what I'd do in
> your case. CT computation on types is a lot like functional
> programming: recursion and immutability.

However, the current set of tools is a bit lacking in that department. Hopefully I'll be able to rectify this with my attempt at a proper std.meta package :)   Unfortunately, it's proving to a bit of a stress-test on some dustier parts of the compiler (not to mention my brain), so progress is a bit slower than I would have hoped.

On Sunday, 24 November 2013 at 17:40:14 UTC, Shammah Chancellor wrote:
> What's the consensis on something like this?

https://d.puremagic.com/issues/show_bug.cgi?id=1642

On Sun, Nov 24, 2013 at 8:46 PM, John Colvin <john.loughran.colvin@gmail.com> wrote:

> However, the current set of tools is a bit lacking in that department. Hopefully I'll be able to rectify this with my attempt at a proper std.meta package :)   Unfortunately, it's proving to a bit of a stress-test on some dustier parts of the compiler (not to mention my brain), so progress is a bit slower than I would have hoped.

You can have a look there:

https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d

and

https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d

(this one was fun: regex on type tuples!) https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d

On Sunday, 24 November 2013 at 19:57:06 UTC, Philippe Sigaud wrote:
> On Sun, Nov 24, 2013 at 8:46 PM, John Colvin
> <john.loughran.colvin@gmail.com> wrote:
>
>> However, the current set of tools is a bit lacking in that department.
>> Hopefully I'll be able to rectify this with my attempt at a proper std.meta
>> package :)   Unfortunately, it's proving to a bit of a stress-test on some
>> dustier parts of the compiler (not to mention my brain), so progress is a
>> bit slower than I would have hoped.
>
> You can have a look there:
>
> https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d
>
> and
>
> https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d
>
> (this one was fun: regex on type tuples!)
> https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d

I've been looking at that stuff recently :-)  It's pretty cool, in particular the regex stuff.

I'm wary of going overboard though, it's very tempting to keep adding functionality that is too obscure for a standard library.

On Sun, Nov 24, 2013 at 9:06 PM, John Colvin <john.loughran.colvin@gmail.com> wrote:

>> You can have a look there:
>>
>> https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d
>>
>> and
>>
>> https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d
>>
>> (this one was fun: regex on type tuples!) https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d
>
>
> I've been looking at that stuff recently :-)  It's pretty cool, in particular the regex stuff.
>
> I'm wary of going overboard though, it's very tempting to keep adding functionality that is too obscure for a standard library.

That's why I never tried to get it into Phobos :)
And, truth is, I used almost none of it, even when most of this code
is 4 years old.
Mapping/filtering/reducing tuples is the most useful part.

The regex-on-types stuff was purely for fun.

On Sunday, 24 November 2013 at 20:22:05 UTC, Philippe Sigaud wrote:
> On Sun, Nov 24, 2013 at 9:06 PM, John Colvin
> <john.loughran.colvin@gmail.com> wrote:
>
>>> You can have a look there:
>>>
>>> https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d
>>>
>>> and
>>>
>>> https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d
>>>
>>> (this one was fun: regex on type tuples!)
>>> https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d
>>
>>
>> I've been looking at that stuff recently :-)  It's pretty cool, in
>> particular the regex stuff.
>>
>> I'm wary of going overboard though, it's very tempting to keep adding
>> functionality that is too obscure for a standard library.
>
> That's why I never tried to get it into Phobos :)
> And, truth is, I used almost none of it, even when most of this code
> is 4 years old.
> Mapping/filtering/reducing tuples is the most useful part.

Yeah I'm mostly working around porting std.range and std.algorithm. They're a pretty good subset of "useful things to do with sequences of things". Even so, I suspect come review people will want it pruned a little.

On 2013-11-24 19:42:11 +0000, Philippe Sigaud said:

> The consensus might well be 'use recursion' :) That's what I'd do in
> your case. CT computation on types is a lot like functional
> programming: recursion and immutability.
> 
> Another solution would be to construct you type as a string, and then mix it in.

Yes.  That's what I'm doing, and it's ugggglyyyy.

This seems excessive:

https://github.com/schancel/gameserver/blob/master/source/messages/core.d#L176

On Sun, Nov 24, 2013 at 9:54 PM, Shammah Chancellor <anonymous@coward.com> wrote:
> On 2013-11-24 19:42:11 +0000, Philippe Sigaud said:
>
>> The consensus might well be 'use recursion' :) That's what I'd do in your case. CT computation on types is a lot like functional programming: recursion and immutability.
>>
>> Another solution would be to construct you type as a string, and then mix it in.
>
>
> Yes.  That's what I'm doing, and it's ugggglyyyy.

learn to stop worrying and love the String
(http://en.wikipedia.org/wiki/Dr._Strangelove)
:-)

> This seems excessive:
>
> https://github.com/schancel/gameserver/blob/master/source/messages/core.d#L176

Indeed :)  (btw, you're using EvaulateMessageModules, when I think you
want Eval*u*ateMessageModules)