Make line continuation characters optional

[DaveInCaz]

(Created this issue as a follow-up to https://github.com/WaynePhillipsEA/twinbasic/discussions/261#discussioncomment-1025905)

I always found the need for the line continuation characters _ to be quite tedious. Making them optional in the language (but I guess still accepted for backwards compatibility) would be an improvement IMO.

And as noted by @WaynePhillipsEA, line continuation characters are optional in VB.NET now.

Thanks

[EduardoVB]

¿And how would it determine if a code line has to continue in the next text line or not? Because in VB6 every new text line is a new code line, unless there is a continuation character.

I don't know how VB.Net handles that.

Continuation characters are annoying, but had a reason. Of course I also would like them to be optional, but how tB would decide if a line has to continue in the next or not?

If a line ends with a syntax error it could indicate that it follows in the next one, specially if when joined with the next line the error is fixed, but I'm not sure if that logic could always work correctly.

Or this continuation without separation character would be only available for string literals?

[mansellan]

VB.Net 10's implicit strategy is described here, although some of those constructs do not apply to twinBASIC.

I wonder if it's possible to do even better though - if a single line results in a compile error, try concatting it with the previous line and see if that works. Could get complicated though.

[EduardoVB]

It seems quite good. I think the cases where it will be used the most are String concatenations (specially SQL queries) and procedure parameters.

Perhaps better to stick to these already known rules, it will be easier for people that comes from .Net.

[WaynePhillipsEA]

The main exception I can think of is for the Print syntax, where you can legitimately end the statement with a comma. For that very specific case, we'd have to preserve backwards compatibility and not apply the implicit line continuation.

[bclothier]

TBH I'm ambivalent on the idea of adding another implicit feature to a language that already suffer from bugs arising from implicit behaviors (I'm looking at you, mister default member access).

I think I'd be in favor of automatically inserting line continuations or make a CodeLens feature(?) where it is shown when an implicit continuation is used. That way, it will still read like traditional VBA code but without the hassle of typing the underscores. Them be mighty hard on my pinkies....

[Kr00l]

My vote goes for no such thing. The _ makes the intent clear and no voodoo continuation. :)

[WaynePhillipsEA]

As a compromise I do like the idea from @bclothier of having the IDE auto-insert the line continuation character when pressing enter at the end of a line that is clearly unfinished.

[Kr00l]

As a compromise I do like the idea from @bclothier of having the IDE auto-insert the line continuation character when pressing enter at the end of a line that is clearly unfinished.

Yes, good. So SQL = SQL & "something" & and pressing ENTER after the & would then "prettify" an _ at the end?

[WaynePhillipsEA]

@Kr00l yes. Basically, when there's a missing operand on the RHS, or if a close bracket is missing, pressing enter at the end of the line would insert the line continuation character automatically.

[EduardoVB]

I totally dislike the code with line continuations characters (it is something personal of course). I don't use that for API or procedure declarations either. And I prefer to have as much 1:1 as possible of code lines with text lines. It is easier (for me) to follow the code, even if some lines go too long.

What about to apply the implicit continuation limiting it to just some few special cases?

I Propose:

1) A String literal that has opened " and never closed with another " beforte the end of the line. 2) When there was ongoing a String concatenation (also valid for Variants) and the line ends with an & 3) There is ongoing a valid item list that must come separated by commas, like an API or procedure parameters declaration, or a function that expects items separated by commas like for instance Array (1, 2, 3..., n) and the line ends with a comma (except for the Print method).

Just for those cases.

[bclothier]

See, as I outlined regarding language design, it's better when the language is consistent and only has one way of thing over having multiple choices which can ultimately hinder the productivity and readability of the language. The proposal to use implicit continuations, especially only for select scenarios, would violate the principles.

I'd rather have a consistent language over a language that has lot of hidden surprises and gotchas. There is a reason we're writing in VB*, not in C++.... ;-)

I totally agree that the line continuation characters sucks and wish it wasn't a thing but I'd argue that it's best treated as an all-or-nothing deal. "On, sorta, sometimes" is the worse option.

[DaveInCaz]

Maybe the approach to backwards compatibility for especially weird scenarios like Print + comma should be to automatically detect & convert those cases to something else which is equivalent? (Aside even from this line continuation discussion, actually). You could even have special compiler errors to detect those cases and inform + educate the programmer about the change.

[EduardoVB]

Maybe the approach to backwards compatibility for especially weird scenarios like Print + comma should be to automatically detect & convert those cases to something else which is equivalent?

I don't know of any equivalent (in VB6).

.Print A & vbTab & B & vbTab;

is not exactly the same as

.Print A, B,

Tabbed space is handled in a different way.

[EduardoVB]

See, as I outlined regarding language design, it's better when the language is consistent and only has one way of thing over having multiple choices which can ultimately hinder the productivity and readability of the language.

Then what about the prettifier removing the ' _' for those cases?

BTW, I didn't mean every line finished by a comma must follow in the next, but just the ones where there is an items enumeration ongoing.

Or another possibility is for just the two first options, that are just for String literals and String composing. Or... just the first one that is for String literals.

These are the three cases where I see useful to be able to split one code line into several text lines, and they are in order of importance.

The need of underscores could be left only for any other case (that I guess will quite rare). In all the cases cases where underscores are not required (that will be the most), the IDE would automatically remove them if they are typed or loaded from files.

Of course this should work only if the VB6 backward compatibility setting is not set.

The idea, at the end, is to get rid as much as possible of this unwanted feature or disliked by many (I guess) that some brilliant mind at some point introduced in the VB syntax.

[mansellan]

My 2c:

I share @bclothier 's dislike of multiple ways of doing things, although perhaps not as strongly. Sometimes it can help to have abbreviated aliases, although I would say that the case for doing so in BASIC is far less than with C# (for example). BASIC has always been about readability, not terseness.

In this case however, I'm not sure the benefits outweigh the costs. I would certainly like to avoid VB.Net's "Usually not needed, except when it is" opinion. On that basis, having the prettifier add the underscore if it's clear the line is unfinished when Enter is pressed seems like a good compromise.

[DaveInCaz]

Just for reference, what they did in VB.net is here https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/statements#implicit-line-continuation

I'm not advocating that approach specifically, just sharing the info because I myself wasn't very familiar with all those exact rules. I've coded in VB6 far more than VB.net.

Personally I think if the automatic insertion of _ characters could be made to work well, it seems like a reasonable approach.

I guess my original request was based along the lines of "most other languages don't have this at all, is it really even needed". But that may be unnecessarily idealistic.

[mansellan]

It might help if the continuation character had it's own semantic highlighting entry (if not already), that way it could be set to a low-contrast colour so they're visible but not too intrusive. Mid-grey perhaps?

Related: How can I change the colours for semantic highlighting @WaynePhillipsEA ? I know they're in a settings file somewhere, just not sure where...

[WaynePhillipsEA]

Related: How can I change the colours for semantic highlighting @WaynePhillipsEA ? I know they're in a settings file somewhere, just not sure where...

F1 > Preferences: Open Workspace Settings (JSON)

In that file look for the entry editor.semanticTokenColorCustomizations. Each colour theme has its own section, so find the section that relates to your active VS color theme, and you should find about 40 different elements like 'basicClass', 'basicModule' etc where you change the colors. Have fun!

[mansellan]

Thanks Wayne. In that list, I thought it might be "basicMultiLineSeperator", but it doesn't seem to be.

[WaynePhillipsEA]

Ah, that one is for the colon line separator. I don't think we've got one yet for the line continuation character. I guess we need 41 semantic colours :)

[WaynePhillipsEA]

@mansellan v0.10.3664 adds a new semantic highlighting token: basicLineContinuationCharacter

[mansellan]

Thanks @WaynePhillipsEA, works a treat.