www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static switch

reply "Dominikus Dittes Scherkl" writes:
I wonder why there is no static switch (analogue to static if)?
Because especially if you overload a lot of operators (which is 
done e.g.
in the definition of complex and bigint) I would think something 
like

T opOpAssign(string op, T)(T x) if(op=="+" || op=="-" || op=="*" 
|| op=="/" || op=="%" || op=="^^" || op=="&" || op=="|" || 
op=="^" || op=="<<" || op==">>" || op==">>>")
{
    static switch(op)
    {
    case "+":
    case "-":
       ...
       break;
    case "*":
       ...
    }
}

would look much better than

{
    static if(op=="+" || op == "-")
    {
       ...
    }
    else static if(op == "*")
    {
       ...
    }
    else
    {
       ...
    }
}
Mar 05 2014
next sibling parent reply Orvid King <blah38621 gmail.com> writes:
Well, as long as we're talking about language design, couldn't the
first be improved more by allowing something like:

T opOpAssign(string op : in("+", "-", "*", "/", "%", "^^", "&", "|",
"^", "<<", ">>", ">>>"), T)(T x)

The `in` there is my attempt to disambiguate between this type of
constraint and what I view as the most likely syntax for built-in
tuples.

On 3/5/14, Dominikus Dittes Scherkl
<Dominikus.Scherkl continental-corporation.com> wrote:
 I wonder why there is no static switch (analogue to static if)?
 Because especially if you overload a lot of operators (which is
 done e.g.
 in the definition of complex and bigint) I would think something
 like

 T opOpAssign(string op, T)(T x) if(op=="+" || op=="-" || op=="*"
 || op=="/" || op=="%" || op=="^^" || op=="&" || op=="|" ||
 op=="^" || op=="<<" || op==">>" || op==">>>")
 {
     static switch(op)
     {
     case "+":
     case "-":
        ...
        break;
     case "*":
        ...
     }
 }

 would look much better than

 {
     static if(op=="+" || op == "-")
     {
        ...
     }
     else static if(op == "*")
     {
        ...
     }
     else
     {
        ...
     }
 }

Mar 05 2014
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2014-03-05 14:09:31 +0000, bearophile said:

 Orvid King wrote:
 
 couldn't the first be improved more by allowing something like:
 
 T opOpAssign(string op : in("+", "-", "*", "/", "%", "^^", "&", "|", 
 "^", "<<", ">>", ">>>"), T)(T x)
 
 The `in` there is my attempt to disambiguate between this type of 
 constraint and what I view as the most likely syntax for built-in 
 tuples.

While a static switch could be a little handy (I have desired it few times, despite a static foreach is much more needed), there's no strong need for that "in", You can use something like (untested): T opOpAssign(string op, T)(T x) if ("+ - * / % ^^ & | ^ << >> >>>".split.canFind(op)) Bye, bearophile

Actually, there is static foreach if you are iterating over a tuple. It's not always very obvious under what conditions the compiler evaluates foreach though. -S
Mar 05 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/5/14, 4:59 PM, Shammah Chancellor wrote:
 Actually, there is static foreach if you are iterating over a tuple.

There's one scope for iteration. We need all iterations to occur in the same scope as the foreach statement. Andrei
Mar 06 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/6/14, 9:12 AM, Dicebot wrote:
 On Thursday, 6 March 2014 at 16:58:12 UTC, Andrei Alexandrescu wrote:
 On 3/5/14, 4:59 PM, Shammah Chancellor wrote:
 Actually, there is static foreach if you are iterating over a tuple.

There's one scope for iteration. We need all iterations to occur in the same scope as the foreach statement. Andrei

Also grammar currently does not allow it to be used as declaration (which is key use case for me)

Correct! Andrei
Mar 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Orvid King wrote:

 couldn't the first be improved more by allowing something like:

 T opOpAssign(string op : in("+", "-", "*", "/", "%", "^^", "&", 
 "|", "^", "<<", ">>", ">>>"), T)(T x)

 The `in` there is my attempt to disambiguate between this type 
 of constraint and what I view as the most likely syntax for 
 built-in tuples.

While a static switch could be a little handy (I have desired it few times, despite a static foreach is much more needed), there's no strong need for that "in", You can use something like (untested): T opOpAssign(string op, T)(T x) if ("+ - * / % ^^ & | ^ << >> >>>".split.canFind(op)) Bye, bearophile
Mar 05 2014
prev sibling next sibling parent "Dominikus Dittes Scherkl" writes:
On Wednesday, 5 March 2014 at 13:34:15 UTC, Orvid King wrote:
 Well, as long as we're talking about language design, couldn't 
 the first be improved more by allowing something like:

 T opOpAssign(string op : in("+", "-", "*", "/", "%", "^^", "&", 
 "|", "^", "<<", ">>", ">>>"), T)(T x)

 The `in` there is my attempt to disambiguate between this type 
 of constraint and what I view as the most likely syntax for 
 built-in tuples.

be analogue to "static if", just syntactic suggar - I considered it only because I stumbled over the ugly "else static if()" chains in phobos.
Mar 05 2014
prev sibling next sibling parent "vitamin" <vitamin vitamin.sk> writes:
On Wednesday, 5 March 2014 at 12:51:23 UTC, Dominikus Dittes
Scherkl wrote:
 I wonder why there is no static switch (analogue to static if)?
 Because especially if you overload a lot of operators (which is 
 done e.g.
 in the definition of complex and bigint) I would think 
 something like

 T opOpAssign(string op, T)(T x) if(op=="+" || op=="-" || 
 op=="*" || op=="/" || op=="%" || op=="^^" || op=="&" || op=="|" 
 || op=="^" || op=="<<" || op==">>" || op==">>>")
 {
    static switch(op)
    {
    case "+":
    case "-":
       ...
       break;
    case "*":
       ...
    }
 }

 would look much better than

 {
    static if(op=="+" || op == "-")
    {
       ...
    }
    else static if(op == "*")
    {
       ...
    }
    else
    {
       ...
    }
 }

use: bool In(Args...)(string str, Args args){ foreach(a; args) if(str == a)return true; return false; } class Foo{ T opOpAssign(string op, T)(T x) if(op.In("+", "-", "*", "/", "%", "^^", "&", "|", "^", "<<", ">>", ">>>")){ return x; } }
Mar 05 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/5/14, 4:51 AM, Dominikus Dittes Scherkl wrote:
 I wonder why there is no static switch (analogue to static if)?

Doesn't enable anything. There'd be a ton more juice in a static foreach; it would enable a lot of great idioms. We should pursue that instead. Andrei
Mar 05 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/5/14, 10:45 AM, Dicebot wrote:
 On Wednesday, 5 March 2014 at 18:39:08 UTC, Andrei Alexandrescu wrote:
 Doesn't enable anything. There'd be a ton more juice in a static
 foreach; it would enable a lot of great idioms. We should pursue that
 instead.

 Andrei

Btw, are there any unexpected design difficulties with static foreach? Or it is just waiting for someone to do the pull request?

The one difficulty is figuring how to allow for all iterations to stay in the same scope, yet not have duplicate definitions of the iteration symbol. Probably worth a DIP. Other than that, we're a go. Andrei
Mar 05 2014
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/05/2014 07:58 PM, Andrei Alexandrescu wrote:
 On 3/5/14, 10:45 AM, Dicebot wrote:
 On Wednesday, 5 March 2014 at 18:39:08 UTC, Andrei Alexandrescu wrote:
 Doesn't enable anything. There'd be a ton more juice in a static
 foreach; it would enable a lot of great idioms. We should pursue that
 instead.

 Andrei

Btw, are there any unexpected design difficulties with static foreach? Or it is just waiting for someone to do the pull request?

The one difficulty is figuring how to allow for all iterations to stay in the same scope, yet not have duplicate definitions of the iteration symbol.

static if needs exactly the same thing, currently the following compiles: static if(is(int A)){} A b; // meh It's pretty easy to solve: Just give static if/static foreach it's own scope, but by default forward symbol insertions to the enclosing scope. Symbols introduced by the construct itself are inserted directly into its scope and not forwarded.
 Probably worth a DIP. Other than that, we're a go.

 Andrei

I will create it this weekend if nobody beats me to it.
Mar 05 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/5/14, 1:54 PM, Timon Gehr wrote:
 On 03/05/2014 07:58 PM, Andrei Alexandrescu wrote:
 On 3/5/14, 10:45 AM, Dicebot wrote:
 On Wednesday, 5 March 2014 at 18:39:08 UTC, Andrei Alexandrescu wrote:
 Doesn't enable anything. There'd be a ton more juice in a static
 foreach; it would enable a lot of great idioms. We should pursue that
 instead.

 Andrei

Btw, are there any unexpected design difficulties with static foreach? Or it is just waiting for someone to do the pull request?

The one difficulty is figuring how to allow for all iterations to stay in the same scope, yet not have duplicate definitions of the iteration symbol.

static if needs exactly the same thing, currently the following compiles: static if(is(int A)){} A b; // meh

Good point, thanks! Andrei
Mar 05 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/5/14, 1:54 PM, Timon Gehr wrote:
 Probably worth a DIP. Other than that, we're a go.

 Andrei

I will create it this weekend if nobody beats me to it.

Walter and I would preapprove implementation of static foreach if and only if a solid DIP comes about. Andrei
Mar 05 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/06/2014 12:35 AM, bearophile wrote:
 Andrei Alexandrescu:

 Walter and I would preapprove implementation of static foreach if and
 only if a solid DIP comes about.

Some suggestions for a static foreach DIP: - It should work at global scope too (I'd like with() to work at global scope too).

Of course. static foreach will be both a declaration and a statement.
 - The semantics of "static foreach (x; TypeTuple!(1, 2))" should not
 change, if possible (in alternative it could change a little, but
 eventually become a syntax error).

No. static foreach does not introduce a new scope. "TypeTuple"-foreach does. Deprecating this language feature is not in scope of the 'static foreach' DIP. It's separate, and I'd even argue for not doing it.
 - At first "foreach (x; TypeTuple!(1, 2))"  should give a warning, then
 a deprecation message, and then an error message that "static" is
 required. This makes iteration on type tuples visibly static.

It's not the same thing.
 - "static foreach_reverse (immutable i; 0 .. 10)" could be supported.

Good point.
 - "static foreach (immutable i; iota(1, 10, 2))" should work.
 - Please no tuple unpacking, because this foreach feature should die and
 be replaced by something more general and more correct.
 ...

foreach and static foreach should behave the same in all shared aspects. (Unfortunately, this statement is somewhat messy to formalize.)
Mar 06 2014
next sibling parent captaindet <2krnk gmx.net> writes:
On 2014-03-06 16:06, bearophile wrote:
 Timon Gehr:

 No. static foreach does not introduce a new scope.
 "TypeTuple"-foreach does. Deprecating this language feature is not
 in scope of the 'static foreach' DIP. It's separate, and I'd even
 argue for not doing it.

My most basic point in this ER is to require a "static" before "foreach" when you loop on TypeTuples, because the current situation is confusing for newbies and makes D code less explicit: https://d.puremagic.com/issues/show_bug.cgi?id=4085 Introducing a third type of foreach that is intermediate between the semantucs of the regular foreach and the already present typetuple foreach is ridiculous, will increase the language complexity and will make D and even more confusing for newbies. Bye, bearophile

+1
Mar 06 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/06/2014 11:06 PM, bearophile wrote:
 Introducing a third type of foreach that is intermediate between the
 semantucs of the regular foreach and the already present typetuple
 foreach is ridiculous,

Indeed.
 will increase the language complexity and will
 make D and even more confusing for newbies.

You seem to be arguing for making static foreach semantics inconsistent with static if semantics and the static foreach construct useless for generation of declarations which is among the main use cases. Is this correct?
Mar 07 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/05/2014 11:41 PM, deadalnix wrote:
 On Wednesday, 5 March 2014 at 21:54:52 UTC, Timon Gehr wrote:
 ...

 static if needs exactly the same thing, currently the following compiles:

 static if(is(int A)){}
 A b; // meh

 It's pretty easy to solve: Just give static if/static foreach it's own
 scope, but by default forward symbol insertions to the enclosing
 scope. Symbols introduced by the construct itself are inserted
 directly into its scope and not forwarded.

I don't think this is the right solution. Spewing error is better than overly complicated design.

I don't understand what your point is. Care to elaborate?
Mar 06 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/5/14, 11:40 AM, Tofu Ninja wrote:
 On Wednesday, 5 March 2014 at 18:58:49 UTC, Andrei Alexandrescu wrote:
 The one difficulty is figuring how to allow for all iterations to stay
 in the same scope, yet not have duplicate definitions of the iteration
 symbol. Probably worth a DIP. Other than that, we're a go.

 Andrei

Do you have an idea of how to solve that? If not I have an idea but it is a little silly and it would introduce a new feature so I would rather wait and hear if there are any other solutions.

My idea revolves around replacing the iteration variable(s) with the respective literal(s) before doing semantic analysis. This is probably unprecedented. Andrei
Mar 05 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 5 March 2014 at 18:39:08 UTC, Andrei Alexandrescu 
wrote:
 Doesn't enable anything. There'd be a ton more juice in a 
 static foreach; it would enable a lot of great idioms. We 
 should pursue that instead.

 Andrei

Btw, are there any unexpected design difficulties with static foreach? Or it is just waiting for someone to do the pull request?
Mar 05 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 5 March 2014 at 12:51:23 UTC, Dominikus Dittes
Scherkl wrote:
 I wonder why there is no static switch (analogue to static if)?
 Because especially if you overload a lot of operators (which is 
 done e.g.
 in the definition of complex and bigint) I would think 
 something like

 T opOpAssign(string op, T)(T x) if(op=="+" || op=="-" || 
 op=="*" || op=="/" || op=="%" || op=="^^" || op=="&" || op=="|" 
 || op=="^" || op=="<<" || op==">>" || op==">>>")
 {
    static switch(op)
    {
    case "+":
    case "-":
       ...
       break;
    case "*":
       ...
    }
 }

 would look much better than

 {
    static if(op=="+" || op == "-")
    {
       ...
    }
    else static if(op == "*")
    {
       ...
    }
    else
    {
       ...
    }
 }

Constant folding will generate code like that. What does the static buys you ?
Mar 05 2014
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 3/5/14, 4:07 PM, deadalnix wrote:
 On Wednesday, 5 March 2014 at 12:51:23 UTC, Dominikus Dittes
 Scherkl wrote:
 I wonder why there is no static switch (analogue to static if)?
 Because especially if you overload a lot of operators (which is done e.g.
 in the definition of complex and bigint) I would think something like

 T opOpAssign(string op, T)(T x) if(op=="+" || op=="-" || op=="*" ||
 op=="/" || op=="%" || op=="^^" || op=="&" || op=="|" || op=="^" ||
 op=="<<" || op==">>" || op==">>>")
 {
    static switch(op)
    {
    case "+":
    case "-":
       ...
       break;
    case "*":
       ...
    }
 }

 would look much better than

 {
    static if(op=="+" || op == "-")
    {
       ...
    }
    else static if(op == "*")
    {
       ...
    }
    else
    {
       ...
    }
 }

Constant folding will generate code like that. What does the static buys you ?

Readability.
Mar 05 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 5 March 2014 at 18:58:49 UTC, Andrei Alexandrescu 
wrote:
 The one difficulty is figuring how to allow for all iterations 
 to stay in the same scope, yet not have duplicate definitions 
 of the iteration symbol. Probably worth a DIP. Other than that, 
 we're a go.

 Andrei

Do you have an idea of how to solve that? If not I have an idea but it is a little silly and it would introduce a new feature so I would rather wait and hear if there are any other solutions.
Mar 05 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Doesn't enable anything.

Right, on the other hand a switch offers code more DRY compared to nested static ifs, and this part of the point of having a dynamic switch too. And the cognitive cost for a D programmer to remember what is a "static switch" is small (even if you inevitably need "static final switch" too if you create a "static switch"). I have never opened an enhancement request on this because the need for a static switch is not strong, but it's not zero.
 There'd be a ton more juice in a static foreach; it would 
 enable a lot of great idioms. We should pursue that instead.

 Probably worth a DIP. Other than that, we're a go.

So do you like to tag this issue as pre-approved? (The gist of this ER is that even an arbitrarily partial implementation of a static foreach is better than having none at all): https://d.puremagic.com/issues/show_bug.cgi?id=4085 Bye, bearophile
Mar 05 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 5 March 2014 at 12:51:23 UTC, Dominikus Dittes 
Scherkl wrote:
 T opOpAssign(string op, T)(T x) if(op=="+" || op=="-" || 
 op=="*" || op=="/" || op=="%" || op=="^^" || op=="&" || op=="|" 
 || op=="^" || op=="<<" || op==">>" || op==">>>")
 {
    static switch(op)
    {
    case "+":
    case "-":
       ...
       break;
    case "*":
       ...
    }
 }

 would look much better than

 {
    static if(op=="+" || op == "-")
    {
       ...
    }
    else static if(op == "*")
    {
       ...
    }
    else
    {
       ...
    }
 }

You can simply make it different overloads: T opOpAssign(string op, T)(T x) if(op=="+" || op=="-") { ... } T opOpAssign(string op, T)(T x) if(op=="*" || op=="/" || op=="%") { ... } etc.
Mar 05 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 5 March 2014 at 21:54:52 UTC, Timon Gehr wrote:
 On 03/05/2014 07:58 PM, Andrei Alexandrescu wrote:
 On 3/5/14, 10:45 AM, Dicebot wrote:
 On Wednesday, 5 March 2014 at 18:39:08 UTC, Andrei 
 Alexandrescu wrote:
 Doesn't enable anything. There'd be a ton more juice in a 
 static
 foreach; it would enable a lot of great idioms. We should 
 pursue that
 instead.

 Andrei

Btw, are there any unexpected design difficulties with static foreach? Or it is just waiting for someone to do the pull request?

The one difficulty is figuring how to allow for all iterations to stay in the same scope, yet not have duplicate definitions of the iteration symbol.

static if needs exactly the same thing, currently the following compiles: static if(is(int A)){} A b; // meh It's pretty easy to solve: Just give static if/static foreach it's own scope, but by default forward symbol insertions to the enclosing scope. Symbols introduced by the construct itself are inserted directly into its scope and not forwarded.

I don't think this is the right solution. Spewing error is better than overly complicated design.
Mar 05 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Walter and I would preapprove implementation of static foreach 
 if and only if a solid DIP comes about.

Some suggestions for a static foreach DIP: - It should work at global scope too (I'd like with() to work at global scope too). - The semantics of "static foreach (x; TypeTuple!(1, 2))" should not change, if possible (in alternative it could change a little, but eventually become a syntax error). - At first "foreach (x; TypeTuple!(1, 2))" should give a warning, then a deprecation message, and then an error message that "static" is required. This makes iteration on type tuples visibly static. - "static foreach_reverse (immutable i; 0 .. 10)" could be supported. - "static foreach (immutable i; iota(1, 10, 2))" should work. - Please no tuple unpacking, because this foreach feature should die and be replaced by something more general and more correct. Bye, bearophile
Mar 05 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 5 March 2014 at 22:54:38 UTC, Andrei Alexandrescu 
wrote:
 On 3/5/14, 11:40 AM, Tofu Ninja wrote:
 On Wednesday, 5 March 2014 at 18:58:49 UTC, Andrei 
 Alexandrescu wrote:
 The one difficulty is figuring how to allow for all 
 iterations to stay
 in the same scope, yet not have duplicate definitions of the 
 iteration
 symbol. Probably worth a DIP. Other than that, we're a go.

 Andrei

Do you have an idea of how to solve that? If not I have an idea but it is a little silly and it would introduce a new feature so I would rather wait and hear if there are any other solutions.

My idea revolves around replacing the iteration variable(s) with the respective literal(s) before doing semantic analysis. This is probably unprecedented. Andrei

Forgive me if this has a real name, but what I think is needed is some kind of partial scope construct. A way to declare a scope for a specific symbol whilst still using it in the outside scope. I think an example would make more sense than me trying to explain it. partial_scope { /*block A*/ //Things declared here are available in A and B int val = 5; } { /*block B*/ //Things declared here are available in B and the outside scope int x = val; } int y; y = x; // works y = val; // fails Things declared in block A are available in block A and block B. Anything declared in block B would be available in block B and the outside scope. Things declared in block A are not available in the outside scope. With something like this, each iteration of the static foreach would just be rewritten as a partial_scope with the iterator declared in block A.
Mar 06 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 6 March 2014 at 16:58:12 UTC, Andrei Alexandrescu 
wrote:
 On 3/5/14, 4:59 PM, Shammah Chancellor wrote:
 Actually, there is static foreach if you are iterating over a 
 tuple.

There's one scope for iteration. We need all iterations to occur in the same scope as the foreach statement. Andrei

Also grammar currently does not allow it to be used as declaration (which is key use case for me)
Mar 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 No. static foreach does not introduce a new scope. 
 "TypeTuple"-foreach does. Deprecating this language feature is 
 not in scope of the 'static foreach' DIP. It's separate, and 
 I'd even argue for not doing it.

My most basic point in this ER is to require a "static" before "foreach" when you loop on TypeTuples, because the current situation is confusing for newbies and makes D code less explicit: https://d.puremagic.com/issues/show_bug.cgi?id=4085 Introducing a third type of foreach that is intermediate between the semantucs of the regular foreach and the already present typetuple foreach is ridiculous, will increase the language complexity and will make D and even more confusing for newbies. Bye, bearophile
Mar 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 foreach and static foreach should behave the same in all shared 
 aspects. (Unfortunately, this statement is somewhat messy to 
 formalize.)

I am for deprecating unpacking of TypeTuples in foreach. Introducing such unpacking in static foreach just to deprecate it (hopefully a little) later is not wise. Bye, bearophile
Mar 06 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 6 March 2014 at 17:24:07 UTC, Timon Gehr wrote:
 On 03/05/2014 11:41 PM, deadalnix wrote:
 On Wednesday, 5 March 2014 at 21:54:52 UTC, Timon Gehr wrote:
 ...

 static if needs exactly the same thing, currently the 
 following compiles:

 static if(is(int A)){}
 A b; // meh

 It's pretty easy to solve: Just give static if/static foreach 
 it's own
 scope, but by default forward symbol insertions to the 
 enclosing
 scope. Symbols introduced by the construct itself are inserted
 directly into its scope and not forwarded.

I don't think this is the right solution. Spewing error is better than overly complicated design.

I don't understand what your point is. Care to elaborate?

Forget about it. I think you aright. I misunderstood your proposal.
Mar 06 2014
prev sibling next sibling parent Orvid King <blah38621 gmail.com> writes:
On 3/6/14, bearophile <bearophileHUGS lycos.com> wrote:
 Timon Gehr:

 foreach and static foreach should behave the same in all shared
 aspects. (Unfortunately, this statement is somewhat messy to
 formalize.)

I am for deprecating unpacking of TypeTuples in foreach. Introducing such unpacking in static foreach just to deprecate it (hopefully a little) later is not wise. Bye, bearophile

Why would we want to not unpack type tuples in a foreach? What would we be iterating over then? Unless of course the current behavior (assuming there is no comma operator :P) of `foreach (T; (ubyte, (ushort, short), uint))` is to iterate over ubyte, ushort, short, and uint? If that is the case, I would be interested to know why the decision was made. If not, then the question still remains, why would you not want it to iterate over ubyte, (ushort, short), uint?
Mar 07 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Orvid King:

 Why would we want to not unpack type tuples in a foreach?

An answer: https://github.com/D-Programming-Language/phobos/pull/1866#issuecomment-33160357 Bye, bearophile
Mar 07 2014
prev sibling parent Orvid King <blah38621 gmail.com> writes:
On 3/7/14, bearophile <bearophileHUGS lycos.com> wrote:
 Orvid King:

 Why would we want to not unpack type tuples in a foreach?

An answer: https://github.com/D-Programming-Language/phobos/pull/1866#issuecomment-33160357 Bye, bearophile

Ah, that's what I was missing, I wasn't considering the case of multiple iterator variables, nor, now that I really think about it, was I actually thinking about tuple unpacking, because the unpacking that I was talking about would be done anyways. With that in mind, I would agree that it is an anti-feature due to the fact it adds an arbitrary ambiguity to the language.
Mar 07 2014