• Lionello Lunesu (11/11) Oct 30 2006 Is this according to the spec?
• Sean Kelly (5/17) Oct 30 2006 I'd say this represents undefined behavior. If the compiler simply
• Karen Lanrap (4/5) Oct 30 2006 No. According to the specs the index cannot be "inout" for arrays.
• Chris Nicholson-Sauls (10/20) Oct 30 2006 I don't believe the posted example used the index as 'inout' -- which is...
• Karen Lanrap (3/5) Oct 30 2006 That is impossible with 'in' parameters to a block.
• Chris Nicholson-Sauls (9/19) Oct 30 2006 I don't think that's the case. Try foreaching over an associative array...
• Karen Lanrap (2/3) Oct 30 2006 Why then to forbid "inout"?
• Lionello Lunesu (5/10) Oct 31 2006 Changing the key of an element in an AA would change the order of the
• Karen Lanrap (4/6) Oct 31 2006 Allowing for the "feature" Chris wants:

Lionello Lunesu <lio lunesu.remove.com> writes:

Is this according to the spec?

#void main(char[] args[])







I'm changing the key (index) inside the foreach, and foreach actually 
uses my index. The example above prints every other character.

L.

Sean Kelly <sean f4.ca> writes:

Lionello Lunesu wrote:
 Is this according to the spec?
 
 #void main(char[] args[])






 
 I'm changing the key (index) inside the foreach, and foreach actually 
 uses my index. The example above prints every other character.

I'd say this represents undefined behavior.  If the compiler simply 
converts the foreach to a for loop then you will see the above behavior, 
but it doesn't have to...


Sean

Karen Lanrap <karen digitaldaemon.com> writes:

Lionello Lunesu wrote:

 Is this according to the spec?

No. According to the specs the index cannot be "inout" for arrays.

Therefore "++i" is allowed but should have no effect on the number of 
executions of the body of the foreach statement.

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Karen Lanrap wrote:
 Lionello Lunesu wrote:
 
 
Is this according to the spec?

 
 
 No. According to the specs the index cannot be "inout" for arrays.
 
 Therefore "++i" is allowed but should have no effect on the number of 
 executions of the body of the foreach statement.

I don't believe the posted example used the index as 'inout' -- which is,
indeed, 
considered illegal by the spec.  Instead it was a normal 'in' index, which was
being 
manually advanced to skip an iteration.  As far as I am aware, no this isn't
covered by 
the spec.  However, maybe it should be, and should be allowed; it is a very
useful way to 
have consumer elements in things like parameter lists.  Or if we could get a
"skip" analog 
to break/continue... which I think has been discussed to some depth before.

(I admit to having written a few snips of code that rely on this behavior. 
Naughty? 
Sure.  But it worked like a charm.)

-- Chris Nicholson-Sauls

Karen Lanrap <karen digitaldaemon.com> writes:

Chris Nicholson-Sauls wrote:

 Instead it was a normal 'in' index, which was being manually
 advanced to skip an iteration.

That is impossible with 'in' parameters to a block.

Therefore indexes are buggily implemented as 'inout'.  

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Karen Lanrap wrote:
 Chris Nicholson-Sauls wrote:
 
 
Instead it was a normal 'in' index, which was being manually
advanced to skip an iteration.

 
 
 That is impossible with 'in' parameters to a block.
 
 Therefore indexes are buggily implemented as 'inout'.  

I don't think that's the case.  Try foreaching over an associative array and
setting the 
value of the key.  If the index were silently inout then the array would have
differing 
data afterward, which it does not.

It is not a parameter, but a variable within a scope like any other. 
Therefore, you can 
do essentially anything you want with it.  The fact that the loop is controlled
by those 
changes, only means that the foreach is rewritten effeciently, by not making
invisible 
temp variables to store loop state.  I would consider that a feature.

-- Chris Nicholson-Sauls

Karen Lanrap <karen digitaldaemon.com> writes:

Chris Nicholson-Sauls wrote:

 I would consider that a feature. 

Why then to forbid "inout"? 

Lionello Lunesu <lio lunesu.remove.com> writes:

Karen Lanrap wrote:
 Chris Nicholson-Sauls wrote:
 
 I would consider that a feature. 

 
 Why then to forbid "inout"? 

Changing the key of an element in an AA would change the order of the 
items. And what would you expect changing the 'key' (=index) of an 
element in a normal array would do? (Move the element to a different index?)

L.

Karen Lanrap <karen digitaldaemon.com> writes:

Lionello Lunesu wrote:

 what would you expect changing the 'key' (=index) of an element
 in a normal array would do?

Allowing for the "feature" Chris wants:

"inout i" == assignments to i change the number of iterations
"      i" == no such change happens