VB Expression allows multiple expressions (if they are statements)
Having checked, this is not new to LinqPad 5, it is repeatable in LinqPad 4.
Set the language to VB Expression
Paste this code:
CStr(1).Length
CStr(2).ToString
CStr(3).ToString
'CStr(40).Length
Note no syntax errors and running returns 1, the value of the first expression (which can still be any expression AFAICT).
If you uncomment the last line, it then complains "Property access must assign to the property or use its value." interactively in LinqPad 5 and at compile time in LinqPad 4.
Note you can also combine these "statements" on one line with colons with no warning or error.
However, this might actually be a feature for people who want to use the "selection runs what's selected" feature where they temporarily switch to VB Expression to run a part of a query and don't need dozens of red wiggly underlines in LinqPad 5.
Set the language to VB Expression
Paste this code:
CStr(1).Length
CStr(2).ToString
CStr(3).ToString
'CStr(40).Length
Note no syntax errors and running returns 1, the value of the first expression (which can still be any expression AFAICT).
If you uncomment the last line, it then complains "Property access must assign to the property or use its value." interactively in LinqPad 5 and at compile time in LinqPad 4.
Note you can also combine these "statements" on one line with colons with no warning or error.
However, this might actually be a feature for people who want to use the "selection runs what's selected" feature where they temporarily switch to VB Expression to run a part of a query and don't need dozens of red wiggly underlines in LinqPad 5.
Comments
I have a good repro of this that also highlights "issues" with the new
$""syntax:Paste this into a new VB Expression:
$"{Now:yyyy-MM-dd HH:mm:ss.fff zzzzz}{vbCrLf}{Date.UtcNow.ToLocalTime:yyyy-MM-dd HH:mm:ss.fff zzzzz}"'.Dump 'Call $"{Now.ToUniversalTime:yyyy-MM-dd HH:mm:ss.fff zzzzz}{vbCrLf}{Date.UtcNow:yyyy-MM-dd HH:mm:ss.fff zzzzz}".Dump 'Call $"{Now:g}{vbCrLf}{Date.UtcNow.ToLocalTime:g}".Dump 'Call $"{Now.ToUniversalTime:g}{vbCrLf}{Date.UtcNow:g}".Dump 'Call $"{Now:r}{vbCrLf}{Date.UtcNow.ToLocalTime:r}".Dump 'Call $"{Now.ToUniversalTime:r}{vbCrLf}{Date.UtcNow:r}".DumpFirstly, if you execute it, it should work fine, displaying the UTC now twice, but with the local timezone (any issues with that outcome should be addressed to the .NET Framework :-) especially when you see the results of the commented out calls).Now try formatting this: Ctrl+E,D, or whatever you've set it to, (or just clicking on the Edit menu seems to autoformat often*):
$"{Now:yyyy-MM - dd HH: mm : ss.fff zzzzz}{vbCrLf}{Date.UtcNow.ToLocalTime: yyyy-MM - dd HH: mm : ss.fff zzzzz}"'.Dump 'Call $"{Now.ToUniversalTime: yyyy-MM - dd HH: mm : ss.fff zzzzz}{vbCrLf}{Date.UtcNow: yyyy-MM - dd HH: mm : ss.fff zzzzz}".Dump 'Call $"{Now: g}{vbCrLf}{Date.UtcNow.ToLocalTime:g}".Dump 'Call $"{Now.ToUniversalTime:g}{vbCrLf}{Date.UtcNow:g}".Dump 'Call $"{Now:r}{vbCrLf}{Date.UtcNow.ToLocalTime:r}".Dump 'Call $"{Now.ToUniversalTime:r}{vbCrLf}{Date.UtcNow:r}".DumpIt's clearly seen "statements" separated by colons to add whitespace around, and somewhere unended strings continue to the next line, and so ignore the comments and continue "formatting" "code". If you Ctrl+Z that and add aCallin front, even though it causes lots of red squiggly underlines, formatting works "as expected".This can be replicated if you change to VB Statement(s): You get exactly the same formatting results: with the
Callin front, making valid statements (or nearly so, you have to uncomment the'.Dumpat the end to get it to compile) formatting works "as expected". Removing that firstCallmeans formatting attempts to adjust whitespace around colons well into the second commented line, exactly the same as when it was an "Expression".(*) That has to be called a separate bug: if I only use the Edit menu, I cannot undo what I intended because every attempt, including the first where it is displaying "Undo ", actually undoes the "Auto-format" just enacted by clicking on the Edit menu.
Also, in some cases, each "Auto-format" performed (by clicking the Edit menu or manually via Ctrl+E,D) has to be undone individually with Ctrl+Z even though it didn't change anything after the first time. This seems to be reproed with the expression I started with above: You have to Ctrl+Z as many times as you type Ctrl+E,D to undo the bad formatting without
Callat the front, and only once no matter how many times you type Ctrl+E,D ifCallis inserted.All of the auto-format issues, including the Edit menu, are still present in v5.0.04.