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?

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?

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

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.