This project is read-only.

VS2014CTP3 language features


How does one enable the experimental language features in the CTP3 of VS2014?

For C#6 language feature you add
to the Project file,

But how do you do the same for

In particular the guards on case statements.


ADGreen wrote Oct 12, 2014 at 1:11 AM

Hey Adam,

We haven't put any features for VB under the experimental flag except for the null conditional access (?.) operator which was under experimental internally but has since been promoted to Visual Basic "14" and will be available by default in the next preview. Other features of Visual Basic "14" such as multiline string literals, year-first date literals, and partial modules and interfaces, are already available by default.

Regarding guard clauses on Select Case statements specifically there are several open design questions that we're not confident should be rushed for this release, including:

1) Should guard clauses create a decision tree where their common case clauses are evaluated once or should the case statements be evaluated once per case statement as they are today:
Dim y As Integer ' This is passed ByRef
Select Case x
    Case M(y) When y < 0
    Case M(y) When y = 0
    Case M(y) When y > 0
End Select
In this example if y is > 0 should M be executed once or thrice?

2) Should guard clauses apply once per Case clause, once per Case statement, or should we find a way to allow for either?
' Once per clause.
Case M(y) When y > 0, N(x) When x IsNot Nothing
' Once per statement.
Case M(y), N(x) When y > 0 OrElse x IsNot Nothing
' Both?
Case (M(y) When y > 0, N(x)) When y > 10 OrElse x IsNot Nothing
When we initially considered the feature we were most focused on how it would work in conjunction with another VB "14" candidate feature - TypeCase (Select Case on type) and for that feature the consequences of design choices for #1 especially are less apparent because a type-check itself is side-effect free (it's not observable which choice we made). We've gone back and forth over these choices and still aren't completely confident but whatever we decide will be very important to the future design considerations for adding full-fledge pattern matching to the language. Rather than rush them we've decided to withdraw them for VB "14" and continue to iterate on their design in future experimental previews of VB "15" instead.


Anthony D. Green, Program Manager, Visual Basic and C# Languages Team

AdamSpeight2008 wrote Oct 12, 2014 at 5:07 AM

My vote is one per statement, as you alway add another case.

If any of these clauses are true andalso the following condition is true then do this.
If {cl0, cl1, cl2, cl3}.Any() AndAlso guard() Then do this.
If you decide to allow multiple guard. Force the pretty-printter to have them on seperate lines with the when vertically aligned with each other.
Case 1 When x,
     2 When y  :  do_this
Which would allow comments to be added on the end of each line.

Should "we" evaluate M(y) more than once? Probably no. Lazily.
Imagine the M(y) returns random number or a mutable static.
Lets say rgat M is this
Functon M(y)
Static x as integer
Return x
End Function 
Each evaluate of a case statement would a different value
Also i think case blocks are not evaluated as a single block of code before continuing say like sync blocks.
So it possible for values change between case statements, non obviously and be pain to debug hessenbug.

Should it "take snapshot" of the values before starting the evaluation? Then it wouls make it hacw lambda semantucs.

If it is possible detect at compile-time(?) purity of the function call, if foybd to be pure tge it wouldnt matter. Whuch be a case for lazy evaluate.