On Sunday, December 11, 2011 20:19:11 Robert Jacques wrote:
> A lot (all?) of for loop use cases seem to actually work in tuple form. For
> instance,
> 
> for(; cond; tuple(++x, y *= 2) ) {}
> 
> Will behave as expected, although there might be a performance issue.

What if one of the expression's result is void?

All in all, I think that it's ludicrous to consider changing the semantics of for loops to use a tuple instead of the comma operator. It's one thing to consider eliminating the comma operator outside of for loops. It's yet another to consider adding built-in templates beyond that, and it's going _way_ too far to change the semantics of the for loop as part of that IMHO.

for loops should be left exactly as they are, regardless of what happens with the comma operator outside of for loops.

- Jonathan M Davis

On Sun, 11 Dec 2011 20:25:07 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, December 11, 2011 20:19:11 Robert Jacques wrote:
>> A lot (all?) of for loop use cases seem to actually work in tuple form. For
>> instance,
>>
>> for(; cond; tuple(++x, y *= 2) ) {}
>>
>> Will behave as expected, although there might be a performance issue.
>
> What if one of the expression's result is void?
>
> All in all, I think that it's ludicrous to consider changing the semantics of
> for loops to use a tuple instead of the comma operator. It's one thing to
> consider eliminating the comma operator outside of for loops. It's yet another
> to consider adding built-in templates beyond that, and it's going _way_ too
> far to change the semantics of the for loop as part of that IMHO.
>
> for loops should be left exactly as they are, regardless of what happens with
> the comma operator outside of for loops.
>
> - Jonathan M Davis
>

Ah, thank you. I was observing that my standard for loop syntax actually had the same effective meaning under traditional and tuple semantics, and wasn't seeing the counter example. But,

for(; !a.empty && b.empty; a.popFront, b.popFront) {}

would never work as a tuple.

On Fri, 09 Dec 2011 15:39:09 -0000, Timon Gehr <timon.gehr@gmx.ch> wrote:
> On 12/09/2011 04:37 PM, Regan Heath wrote:
>> On Fri, 09 Dec 2011 14:54:16 -0000, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>> What you might be missing is that assert(false) is not compiled out in
>>> release mode. It emits a 'hlt' instruction which kills your program.
>>> However, your assert(c <= 0x10FFFF); will be removed in release mode.
>>
>> I was indeed missing that. I couldn't find anything about it on the
>> website. :)
>>
>> R
>>
>
> http://d-programming-language.org/expression.html#AssertExpression

I found that :p  .. but nothing about behaviour in release/debug/etc.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Regan Heath:

> > http://d-programming-language.org/expression.html#AssertExpression
> 
> I found that :p  .. but nothing about behaviour in release/debug/etc.

It's a known little wart of D2. We discussed about it some time ago. I have asked for a specific and clean way to do it, but D designers have said it's not a big enough wart to deserve an improvement. And as I have predicted, it comes around to bite people in the butt. This is the opposite of perfectionism...

Bye,
bearophile