Multiple `For` or `For Each` Control Variables Per Statement

[AdamSpeight2008]

For ... Next Loop

Given the following section of code, it can be written as

For x = 0 To 9
  For y = 0 To 9
    Console.WriteLine($"{x} * {y} = {x*y}")
  Next
Next

or

For x = 0 To 9
  For y = 0 To 9
    Console.WriteLine($"{x} * {y} = {x*y}")
Next x. y

Yet we can not write

For x = 0 To 9, y = 0 To 9
    Console.WriteLine($"{x} * {y} = {x*y}")
Next x. y

or

For x = 0 To 9, y = 0 To 9
    Console.WriteLine($"{x} * {y} = {x*y}")
Next '  equivalent to Next y : Next x

We should enable the last two scenario to compile.
Note: For what if the inner code contains exit continue `

---

For Each ... Next Loop

Premise
The premise of this feature is to allow the user to specify multiple iterators on a single For Each.

Basic Structrure

For Each x In xs, y In ys
   ' ...
   ' exit       ' exits ys iterator
   ` exit x     ' exits xs iterator
   ' continue   ' goto next iteration of ys
   ' continue x ' goto next iteration of xs
   ' Next       ' an error? / goto next iteration of ys then xs?
Next y , x

Example

Public Overrides ReadOnly Property AdditionalLocations As IReadOnlyList(Of Location)
  Get
    Dim builder = ArrayBuilder(Of Location).GetInstance()
    For Each sym In AmbiguousSymbols, l In sym.Locations
      builder.Add(l)
    Next l, sym
    Return builder.ToImmutableAndFree()
  End Get
End Property

semantically equivalent to the following

Public Overrides ReadOnly Property AdditionalLocations As IReadOnlyList(Of Location)
  Get
    Dim builder = ArrayBuilder(Of Location).GetInstance()
    For Each sym In AmbiguousSymbols
      For Each l In sym.Locations
        builder.Add(l)
      Next
    Next
    Return builder.ToImmutableAndFree()
  End Get
End Property

Edit For Each already supports this syntax.

[zspitz]

My own feeling regarding Exit, Continue and Next without a specifier, is that it should apply to the entire loop body. Even though the mental model here is of multiple nested loops, the code as is written contains only a single loop body.

[Bill-McC]

Doesn't seem to be adding anything, just skipping a line. As this is to do with iterating, doesn't LINQ address this ?

[DWAK-ATTK]

I agree w/ Bill-McC. This doesn't appear to be adding anything of substantial value to the language. If you want a language designed for brevity, there's C#. Personally I like the verbosity of VB and would oppose any feature designed solely for the purpose of removing code clarity.

[zspitz]

@DWAK-ATTK I would suggest that a better reason to prefer VB.NET over C# is not because C# was designed for brevity, but because C#'s brevity is in it's usage of symbols. From that perspective, there is no reason for VB.NET to discourage less/smaller syntax, as long as that doesn't come at the cost of a hodgepodge of curly braces and angle brackets.. (NB. are there any official documents / links describing the design goals of VB.NET?)

As an example of smaller syntax: VB.NET has a For ... Each syntax even though you could express this using calls to the GetEnumerator interface methods.

Also, there is a limit to how far we can go to avoid C#-like brevity with symbols. Mathematical operations, assignment, value equality testing and string formatting are all expressed using symbols in VB.NET. If the goal is to avoid symbols entirely, why don't we have Plus, Minus, Times and DividedBy operators?

---

would oppose any feature designed solely for the purpose of removing code clarity.

Are you saying that this (currently supported syntax):

For Each asm In AppDomain.CurrentDomain.GetAssemblies
    For Each t In asm.GetTypes
        For Each m In t.GetMethods
            Console.WriteLine(m.Name)
Next m, t, asm

is clearer / more useful than this?

For Each asm In AppDomain.CurrentDomain.GetAssemblies, t In asm.GetTypes, m in t.GetMethods
    Console.WriteLine(m.Name)
Next

[DWAK-ATTK]

@zspitz
You put words in my mouth and then ask me to defend them. I will not. If you wish to address the words that I did say then I am willing to discuss that.

As for the question you pose regarding the example of currently supported syntax vs proposed syntax: In my opinion the currently supported syntax is far superior, though I prefer matching Next statements for each For statement.

Having separate For statements makes it easy to set up processing at each loop "level". Ditto for matching Next statements.

Allowing the proposed syntax means that a single For statement could kick off multiple nested loops. For a single statement to do that doesn't sit well with me. As I visually scan through the code base I expect, to the degree possible, each statement to do a single task.

[Bill-McC]

@zspitz

Are you saying that this (currently supported syntax):

For Each asm In AppDomain.CurrentDomain.GetAssemblies
    For Each t In asm.GetTypes
        For Each m In t.GetMethods
            Console.WriteLine(m.Name)
Next asm, t, m

Won't compile. You'll be forced to put the m, t, asm in the correct order, or omit them.

[AdamSpeight2008]

@DWAK-ATTK The query For Each syntax does also permit

For Each asm In AppDomain.CurrentDomain.GetAssemblies,
	   t In asm.GetTypes,
	   m In t.GetMethods
    Console.WriteLine(m.Name)
Next

[Bill-McC]

@AdamSpeight2008 The query syntax requires a "From" . Not sure what that sample is, but it isn't LINQ.

And I think that really adds to the reasons not to do this:
(a) we already have alternative LINQ syntax,
(b) doesn't add any new functionality
(c) could be confusing with query syntax as to whether or not it is an expression or multiple statements

[AdamSpeight2008]

@Bill-McC
Could you provide an example(s) to support your claim?

(c) could be confusing with query syntax as to whether or not it is an expression or multiple statements

Since the introduction of implicit line continuations and multi-line lambdas, the line between expression and multiple statements is a little blurry. This proposal is not about LINQ but unify the disconnect between the For structures, where one does allow multiple iteration definitions per a single For and the other doesn't.

[AnthonyDGreen]

@AdamSpeight2008

I strongly agree with this. There's a strong precedent in the language that multiple statements (and query clauses) can be combined into one comma separated list. We see this with Imports, field and variable declarations, the From and Let query clauses, the Next statement as you point out, the Using statement, the Case statement, the Inherits and Implements statement, and probably a few more I'm forgetting. I think this idea is completely consistent with the existing syntactic conventions of the language.

[Bill-McC]

@AdamSpeight2008 Still can't get that code to compile: shows as syntax error. Are you sure it works ? What version of VB ?

For Each asm In AppDomain.CurrentDomain.GetAssemblies,
	   t In asm.GetTypes,
	   m In t.GetMethods
    Console.WriteLine(m.Name)
Next

[Bill-McC]

@AnthonyDGreen Strongly disagree. This comma list proposed dictates a specific order; an outer and inner. The only place that exists that I can think of in VB is within LINQ and I suggest it stays confined to LINQ.