The following code inserts properties for each type,

auto name = "Value"~((i == 0) ? "" : to!string(i++));

always as the i == 0 evaluate to true.


My question is, why the heck is it so hard to use basic programming structs inside CTFE's? I know that CTFE's have to work at run time also, so there is a limitation, but:

1. obviously ints work because the code below works with i as a counter but we can't do a simple compare on it... this seems like a bug.

2. foreach can be used but a simple for loop can't... makes no sense.

I know what the average response is going to be but hopefully someone will surprise me with some useful.



mixin template PropertyBuilder(T...)
{
	template _(TT...)
	{
		static string eval()
		{
			string s;
			pragma(msg, TT);
			int i = 0;
			foreach(t; TT)
			{
				auto name = "Value"~((i > 0) ? "" : to!string(i++));
				s = "@property "~t.stringof~" "~name~"();\n";
				s ~="@property "~t.stringof~" "~name~"("~t.stringof~" value);\n";
			}
			return s;
		}
		enum _ = eval();
		pragma(msg, _);
	}

	mixin("mixin(_!T);");
	
}

interface a(MT...)
{
	mixin PropertyBuilder!MT;
}

On Monday, 8 July 2013 at 11:56:40 UTC, JS wrote:
>
> The following code inserts properties for each type,
>
> auto name = "Value"~((i == 0) ? "" : to!string(i++));
>
> always as the i == 0 evaluate to true.
>
> 1. obviously ints work because the code below works with i as a counter but we can't do a simple compare on it... this seems like a bug.

this is a mistake, I'm not sure what's going on, i seems to increment but name always seems to evaluate to the largest i.

On Monday, 8 July 2013 at 11:56:40 UTC, JS wrote:
> ...

CTFE has nothing to do with it.

void main()
{
        import std.stdio;
	int i = 0;	
	writeln(i == 0 ? i : i++);
	writeln(i);
}

"i++" is evaluated lazy here. I don't know if it is a bug or matches the spec.

On Monday, 8 July 2013 at 12:03:52 UTC, JS wrote:
> On Monday, 8 July 2013 at 11:56:40 UTC, JS wrote:
>>
>> The following code inserts properties for each type,
>>
>> auto name = "Value"~((i == 0) ? "" : to!string(i++));
>>
>> always as the i == 0 evaluate to true.
>>
>> 1. obviously ints work because the code below works with i as a counter but we can't do a simple compare on it... this seems like a bug.
>
> this is a mistake, I'm not sure what's going on, i seems to increment but name always seems to evaluate to the largest i.


sheit... sorry, stupid mistake..

the issue with the foreach is still under question though, when I try to use a for loop with i and access TT[i] I get an error about i not being compile time readable. (maybe this is because of how the type tuple is defined? possibly need a index method to get the value?)

P.S. you speak about (i == 0) but your snippet has (i > 0)

On Monday, 8 July 2013 at 12:08:44 UTC, JS wrote:
> the issue with the foreach is still under question though, when I try to use a for loop with i and access TT[i] I get an error about i not being compile time readable. (maybe this is because of how the type tuple is defined? possibly need a index method to get the value?)

Because i is not a compile-time value, it is a normal variable. And TT is a type tuple, pure compile-time entity. You really need to study the documentation on this topic or frustration will continue.

On Monday, 8 July 2013 at 12:09:55 UTC, Dicebot wrote:
> P.S. you speak about (i == 0) but your snippet has (i > 0)

Thats simply because I forgot to change it.. I tried various things... it's not relevant...

the problem is back... when I remove the compare on i name is updated, when I don' t it isn't:

string name = "Value"~((i == 0) ? "" : to!string(i++));
	}

produces

@property int Value();
@property int Value(int value);
@property double Value();
@property double Value(double value);
@property long Value();
@property long Value(long value);

but

string name = "Value"~(to!string(i++));

@property int Value0();
@property int Value0(int value);
@property double Value1();
@property double Value1(double value);
@property long Value2();
@property long Value2(long value);

so the original statement was correct about i==0.

Hello there. Have you read my answer? The very first one?

1) i will never be incremented there and CTFE has nothing to do with it.
2) This topic should have been in D.learn
3) If you won't tone down your arrogance, soon there will be no one left willing to answer you.

On Monday, 8 July 2013 at 11:56:40 UTC, JS wrote:
>
> The following code inserts properties for each type,
>
> auto name = "Value"~((i == 0) ? "" : to!string(i++));
>
> always as the i == 0 evaluate to true.
>
>
> My question is, why the heck is it so hard to use basic programming structs inside CTFE's? I know that CTFE's have to work at run time also, so there is a limitation, but:
>
> 1. obviously ints work because the code below works with i as a counter but we can't do a simple compare on it... this seems like a bug.
>
> 2. foreach can be used but a simple for loop can't... makes no sense.
>
> I know what the average response is going to be but hopefully someone will surprise me with some useful.
>
>
>
> mixin template PropertyBuilder(T...)
> {
> 	template _(TT...)
> 	{
> 		static string eval()
> 		{
> 			string s;
> 			pragma(msg, TT);
> 			int i = 0;
> 			foreach(t; TT)
> 			{
> 				auto name = "Value"~((i > 0) ? "" : to!string(i++));
> 				s = "@property "~t.stringof~" "~name~"();\n";
> 				s ~="@property "~t.stringof~" "~name~"("~t.stringof~" value);\n";
> 			}
> 			return s;
> 		}
> 		enum _ = eval();
> 		pragma(msg, _);
> 	}
>
> 	mixin("mixin(_!T);");
> 	
> }
>
> interface a(MT...)
> {
> 	mixin PropertyBuilder!MT;
> }

after weeding out the bugs and unusual things, plus letting foreach manage i:

mixin template PropertyBuilder(T...)
{
	template _(TT...)
	{
		static string eval()
		{
			string s;
			foreach(i, t; TT)
			{
				auto name = "Value"~((i > 0) ? to!string(i) : "");
				s ~= "@property "~t.stringof~" "~name~"();\n";
				s ~="@property void "~name~"("~t.stringof~" value);\n";
				
			}
			return s;
		}
		enum _ = eval();
	}

	mixin("mixin(_!T);");
}

which works fine.

The i++ in to!string not having any effect is rather surprising, I agree.

On Monday, 8 July 2013 at 12:08:39 UTC, Dicebot wrote:
> On Monday, 8 July 2013 at 11:56:40 UTC, JS wrote:
>> ...
>
> CTFE has nothing to do with it.
>
> void main()
> {
>         import std.stdio;
> 	int i = 0;	
> 	writeln(i == 0 ? i : i++);
> 	writeln(i);
> }
>
> "i++" is evaluated lazy here. I don't know if it is a bug or matches the spec.

Nothing wrong with that. It's the normal behaviour in C, and it makes perfect sense if you just expand the ternary out to if/else.