January 30, 2014
On Thursday, 30 January 2014 at 17:13:21 UTC, Ilya Yaroshenko wrote:
> On Thursday, 30 January 2014 at 15:28:34 UTC, Timon Gehr wrote:
>> On 01/30/2014 03:08 PM, Ilya Yaroshenko wrote:
>>>>
>>>> 2) `foreach` creates it's own scope. This won't work:
>>>>   foreach(i; TypeTuple!(1,2,3)){
>>>>       mixin("int num"~i.stringof~";");
>>>>   }
>>>>   num1=1;
>>>>   num2=2;
>>>>   num3=3;
>>>>   writeln(num1,num2,num3);
>>>
>>> ...
>>> 2) no. This should work for compile time foreach and TypeTuples. There
>>> are many examples in source code of Phobos.
>>
>> The following code fails to compile:
>>
>> import std.typetuple, std.stdio;
>> void main(){
>>    foreach(i; TypeTuple!(1,2,3)){
>>        mixin("int num"~i.stringof~";");
>>    }
>>    num1=1;
>>    num2=2;
>>    num3=3;
>>    writeln(num1,num2,num3);
>> }
>
> I am wrong, foreach always has own scope
>
>     foreach(S; TypeTuple!(string, wstring, dstring))
>     {
>         import std.conv : to;
>         S a = " a     bcd   ef gh ";
>         assert(equal(splitter(a), [to!S("a"), to!S("bcd"), to!S("ef"), to!S("gh")]));
>         a = "";
>         assert(splitter(a).empty);
>     }
>
>
> You can use mixin and format instead:
>
> import std.typetuple, std.stdio;
> void main(){
>     mixin(format("%(int num%s; %);", [1,2,3])); //<----
>     num1=1;
>     num2=2;
>     num3=3;
>     writeln(num1,num2,num3);
> }

import std.string; =)
January 30, 2014
On Thursday, 30 January 2014 at 14:08:27 UTC, Ilya Yaroshenko wrote:
> 1) You can use mixin(format("<Prolog>%(<Begin>%s<End>%)<Epilog>", CompileTimeRange)); See std.format for ranges and std.string.format.

That works for simple cases. Complex cases require that you write a function and calling it with CTFE for creating the mixin string. This can be a problem outside functions, because you are polluting the namespace. It might not be that bad for structs and classes, since you can simply make that helper function private - but for template mixins the helper function must be exposed to the code that uses the mixin.

Having complex strings mixing also means that if there is a problem in that string, the compiler will point to the line where the string is mixed in, not the one where the code that introduces the error is concentrated to the string. Having a static foreach will make the string mixins small and simple enough for this to not be a problem.

Metaprogramming by building the code strings is not something that should be encouraged(*cough* C macros *cough*), but it's currently required sometimes for complex metaprogramming in D. If we had static foreach we would still need string mixins, but at least we will be mixing in many small simple strings instead of one big complex string, and that means we could add to Phobos some helper template mixins for sanitizing the arguments for those mixins.
January 30, 2014
Andrei has stated at least once that he agrees about usefulness / necessity of declaration foreach. It is mostly matter of someone doing implementation, same as for many other "hot" discussed stuff.
January 30, 2014
On Thursday, 30 January 2014 at 11:19:33 UTC, Idan Arye wrote:
> Two problems:
>
> 1) You can't use `foreach` outside functions. That means that you write:
>     struct Foo{
>         foreach(i;TypeTuple!(1,2,3)){
>             mixin("int num"~i.stringof~";");
>         }
>     }
>

mixin({ foreach(...) { ... } }())

> 2) `foreach` creates it's own scope. This won't work:
>     foreach(i; TypeTuple!(1,2,3)){
>         mixin("int num"~i.stringof~";");
>     }
>     num1=1;
>     num2=2;
>     num3=3;
>     writeln(num1,num2,num3);

You got to mixin the whole stuff, not field by field, and you
won't have any issue.
January 31, 2014
On 1/30/14 12:33 PM, Dicebot wrote:
> Andrei has stated at least once that he agrees about usefulness /
> necessity of declaration foreach. It is mostly matter of someone doing
> implementation, same as for many other "hot" discussed stuff.

Yah, we should have an easier means of iteratively injecting stuff into a scope.

Andrei
January 31, 2014
On Thursday, 30 January 2014 at 23:06:36 UTC, deadalnix wrote:
> On Thursday, 30 January 2014 at 11:19:33 UTC, Idan Arye wrote:
>> Two problems:
>>
>> 1) You can't use `foreach` outside functions. That means that you write:
>>    struct Foo{
>>        foreach(i;TypeTuple!(1,2,3)){
>>            mixin("int num"~i.stringof~";");
>>        }
>>    }
>>
>
> mixin({ foreach(...) { ... } }())

Except it doesn't work inside classes and structs - it complains that "function literals cannot be class members". You have to define a named function and pollute the namespace.

>> 2) `foreach` creates it's own scope. This won't work:
>>    foreach(i; TypeTuple!(1,2,3)){
>>        mixin("int num"~i.stringof~";");
>>    }
>>    num1=1;
>>    num2=2;
>>    num3=3;
>>    writeln(num1,num2,num3);
>
> You got to mixin the whole stuff, not field by field, and you
> won't have any issue.

Yes, you can concatenate strings to create code. I've already answered to Ilya about that, so I'm going to copy-paste my answer:
"
Having complex strings mixing also means that if there is a
problem in that string, the compiler will point to the line where
the string is mixed in, not the one where the code that
introduces the error is concentrated to the string. Having a
static foreach will make the string mixins small and simple
enough for this to not be a problem.

Metaprogramming by building the code strings is not something
that should be encouraged(*cough* C macros *cough*), but it's
currently required sometimes for complex metaprogramming in D. If
we had static foreach we would still need string mixins, but at
least we will be mixing in many small simple strings instead of
one big complex string, and that means we could add to Phobos
some helper template mixins for sanitizing the arguments for
those mixins.
"
February 01, 2014
On 01/31/2014 03:32 AM, Idan Arye wrote:
>>>
>>
>> mixin({ foreach(...) { ... } }())
>
> Except it doesn't work inside classes and structs - it complains that
> "function literals cannot be class members". You have to define a named
> function and pollute the namespace.

This is the corresponding issue:
https://d.puremagic.com/issues/show_bug.cgi?id=7653
1 2 3
Next ›   Last »