• Dominikus Dittes Scherkl (34/34) Mar 05 2014 I wonder why there is no static switch (analogue to static if)?
• Orvid King (9/43) Mar 05 2014 Well, as long as we're talking about language design, couldn't the
• bearophile (9/15) Mar 05 2014 While a static switch could be a little handy (I have desired it
• Shammah Chancellor (5/25) Mar 05 2014 Actually, there is static foreach if you are iterating over a tuple.
• Andrei Alexandrescu (4/5) Mar 06 2014 There's one scope for iteration. We need all iterations to occur in the
• Dicebot (4/10) Mar 06 2014 Also grammar currently does not allow it to be used as
• Andrei Alexandrescu (3/13) Mar 06 2014 Correct!
• Dominikus Dittes Scherkl (5/12) Mar 05 2014 Also a nice idea. But a wholy new concept. "static switch" would
• vitamin (15/49) Mar 05 2014 use:
• Andrei Alexandrescu (5/6) Mar 05 2014 Doesn't enable anything. There'd be a ton more juice in a static
• Dicebot (4/8) Mar 05 2014 Btw, are there any unexpected design difficulties with static
• Andrei Alexandrescu (5/13) Mar 05 2014 The one difficulty is figuring how to allow for all iterations to stay
• Tofu Ninja (5/10) Mar 05 2014 Do you have an idea of how to solve that? If not I have an idea
• Andrei Alexandrescu (5/15) Mar 05 2014 My idea revolves around replacing the iteration variable(s) with the
• Tofu Ninja (29/50) Mar 06 2014 Forgive me if this has a real name, but what I think is needed is
• Timon Gehr (9/24) Mar 05 2014 static if needs exactly the same thing, currently the following compiles...
• deadalnix (3/32) Mar 05 2014 I don't think this is the right solution. Spewing error is better
• Timon Gehr (2/17) Mar 06 2014 I don't understand what your point is. Care to elaborate?
• deadalnix (3/25) Mar 06 2014 Forget about it. I think you aright. I misunderstood your
• Andrei Alexandrescu (3/21) Mar 05 2014 Good point, thanks!
• Andrei Alexandrescu (4/9) Mar 05 2014 Walter and I would preapprove implementation of static foreach if and
• bearophile (18/20) Mar 05 2014 Some suggestions for a static foreach DIP:
• Timon Gehr (9/26) Mar 06 2014 No. static foreach does not introduce a new scope. "TypeTuple"-foreach
• bearophile (11/15) Mar 06 2014 My most basic point in this ER is to require a "static" before
• captaindet (2/16) Mar 06 2014 +1
• Timon Gehr (6/11) Mar 07 2014 You seem to be arguing for making static foreach semantics inconsistent
• bearophile (6/9) Mar 06 2014 I am for deprecating unpacking of TypeTuples in foreach.
• Orvid King (8/17) Mar 07 2014 Why would we want to not unpack type tuples in a foreach? What would
• bearophile (5/6) Mar 07 2014 An answer:
• Orvid King (7/13) Mar 07 2014 Ah, that's what I was missing, I wasn't considering the case of
• bearophile (15/19) Mar 05 2014 Right, on the other hand a switch offers code more DRY compared
• deadalnix (4/38) Mar 05 2014 Constant folding will generate code like that. What does the
• Ary Borenszweig (2/41) Mar 05 2014 Readability.
• Dicebot (12/41) Mar 05 2014 You can simply make it different overloads:

"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
    {
       ...
    }
}

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
     {
        ...
     }
 }

"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

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

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

"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)

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

"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.

Also a nice idea. But a wholy new concept. "static switch" would 
be analogue to "static if", just syntactic suggar - I considered 
it only because I stumbled over the ugly "else static if()" 
chains in phobos.

"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;
	}
	
}

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

"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?

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

"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.

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

"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.

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.

"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.

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?

"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.

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

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

"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

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.)

"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

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

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?

"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

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?

"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

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.

"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

"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 ?

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.

"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.