Implicit line continuation before "Implements"

Lines that contain the word Implements in Method detentions as too long. It will be easier to consider this word an implicit line continuation position.

Public Iterator Function GetEnumerator() As IEnumerator
           Implements IEnumerable.GetEnumerator

This will be consistent with the class definition where the Impliments statements starts at a new line.

[AnthonyDGreen]

Agreed. Handles too! Approved.

[ericmutta]

This would be really handy! And while we are at it, lets generically say implicit line continuations are allowed around ANY keyword that appears in a function/sub declaration, not just the Implements one.

Consider the case with tuples which have a tendency to make lines really really long:

  Public Interface IFoo
    Function GetStuff() As (Foo As String, Bar As Integer, Baz As ExecutionEngineException)
  End Interface

  Public Class CFoo
    Implements IFoo

    Public Function GetStuff() As (Foo As String, Bar As Integer, Baz As ExecutionEngineException) Implements IFoo.GetStuff
      Throw New NotImplementedException()
    End Function
  End Class

With implicit line continuations around any keyword in a function/sub declaration, that GetStuff method in class CFoo could be written like this (with the editor doing the right indenting when you press Enter):

    Public Function GetStuff() 
           As (Foo As String, Bar As Integer, Baz As ExecutionEngineException) 
           Implements IFoo.GetStuff

      Throw New NotImplementedException()
    End Function

The above has implicit line continuations around the As and Implements keywords. Since Function is also a keyword, you could also do this (handy for people who like really descriptive method names):

    Public Function 
           OneReallyLongAndDescriptiveMethodNameHere() 
           As (Foo As String, Bar As Integer, Baz As ExecutionEngineException) 
           Implements IFoo.GetStuff

      Throw New NotImplementedException()
    End Function

Implicit line continuations are one of those small things that have a really big productivity boost and give VB more flexibility in formatting code. I hope to see them in more places!

@AnthonyDGreen
Same goes for From in collection intialization.

[reduckted]

Is it possible to get rid of line continuation markers everywhere? Is there anything that would definitely require a line continuation market to be parsed unambiguously?

[Echo-8-ERA]

Return statements are the only one that comes to mind. Suspect that there may be others, but I'm on my phone and can't check.

[reduckted]

Hmm, even with a Return statement, you'd know whether something should follow it based on whether you're in a Function or a Sub.

[Echo-8-ERA]

I do sometimes use the old style of returning values from functions to avoid having to declare a ret variable. If it were ever allowed to use a Return without return value (instead of using Exit Function) in functions for that case, it would break. It doesn't work though, so I guess it doesn't matter.

Well, the other one I thought of wasEnd, but I'm not sure if it still terminated the application like in classic VB.

[paul1956]

Is there any way to make it work before a . like in C#, so the next like can start with the .?

[reduckted]

Yeah, I'd love that. I guess there might be some difficulty working out what the intent is inside a With block though.

[franzalex]

Maybe the `With` block can be treated differently from the other cases. Specifically, once the parser encounters a `With` block, then it will interpret lines tarting with the `.` like it does now if the identifier after the `.` is not a member of the item initialised in the `With` block.

[ericmutta]

@paul1956 Is there any way to make it work before a . like in C#, so the next like can start with the .?

That would be pretty handy, especially if the behaviour was extended to all operators so we could do things like this:

        Dim SomeStringValue = "foo"
                            & "bar"  '<--- note the & operator was preceded by CRLF
                            & "baz"

My personal favourite would be supporting that behaviour for the comma seperator (I miss this ability from T-SQL's very flexible syntax):

    SomeFunction(
       Value1
      ,Value2  '<--- note the comma appears BEFORE the argument.
      ,Value3
    )

PS: happy new year everyone!

@AnthonyDGreen
It will be useful if you add implicit line continuation before +, -, *, , /, And, Or, Not, ....etc
I have this code in C#

var email = WordEdge
        + ValidFirstChar
        + ValidChars[0, 19]
        + "@"
        + ValidFirstChar
        + ValidChars[2, 14]
        + "."
        + ValidFirstChar
        + ValidChars[1, 9]
        + WordEdge;

Similar code doesn't work in VB.NET although no new line can start with + in VB.NET:

Dim email = WordEdge
        + ValidFirstChar
        + ValidChars(0, 19)
        + "@"
        + ValidFirstChar
        + ValidChars(2, 14)
        + "."
        + ValidFirstChar
        + ValidChars(1, 9)
        + WordEdge