Block-scoped Option Statements

[AnthonyDGreen]

Because sometimes you only need it in that one method. Could potentially address scenario #135.

[craigajohnson]

Please yes. At present, I sometimes maintain a partial class file with Option Strict Off at the top for the occasional late-binding scenario (which VB was famous for until...).

Method scoping would be superior, though - almost as good as Dynamic Dim x to scope it to the variable level but who am I to complain!?

[AdamSpeight2008]

• Option

Function F0()
  Option  Strict Off
  Imports System.Text

End Function

This currently parses but produces an error Statement is not valid in a method on both statements, which could be made conditional feature, dependant of language version.
This is highly likely a breaking change.

---

• Local Option

Function F1()
  Local Option  Strict Off
  Local Imports System.Text

End Function

We could introduce a new contextual keyword Local that would prefix the previous statements and make them into local statements.
This also permits an additional code-fix Make Local Option / Make Local Imports

---

• Using Option ... End Using
  Another option would be to extend the scope of usage of an existing construct, like;-
  Using ... End Using

Function F2()
  Using Option  Strict Off
  Using Imports System.Text

  End Using
  End Using
End Function

Using does permit concatenating multiple usage into a single statement.

Function F3()
  Using Option Strict Off, Imports System.Text

  End Using
End Function

---

@AnthonyDGreen
Why not extend this feature to localising to any NamespaceMemberDeclaraion (vb spec) construction?

[AnthonyDGreen]

@AdamSpeight2008 How is that highly likely a breaking change? The statements aren't allowed in methods today and then they would be. That's not a breaking change.

Re: Namespace scoped Imports, as one former language designer put it "We probably put those in C# because of Java and if we had to do it over again we problem wouldn't". They add a lot of complexity everywhere (compiler, IDE) for not a whole lot of benefit.

[AnthonyDGreen]

The VB LDM looked at this issue on August 23rd and would like this proposal to go further. We also would like method-scoped Imports (which might be evil) to be put into a separate proposal. If we add an Option Checked statement (Proposal #33) for checked/unchecked arithmetic then those proposals combined would address #84 nicely without the weight of a checked/unchecked block. We'd also like to discuss making this block-scoped rather than method-scoped.

[paul1956]

Would this allow VB to support unchecked like in C#? If not where is a good place to discuss that?

[reduckted]

@paul1956, given that there is currently no Option to turn on/off unchecked arithmetic, I would assume not.

#33 does talk about an Option Unchecked, but also other possibilities like Unchecked/End Unchecked.
#84 is another one, but it seems like a duplicate of #33.

[paul1956]

#33 seems orphaned but I think getting it revived as part of this would be welcome.

[ghost]

FYI just found out that source level option strict on/off is already possible.
Just the needed syntax sucks:

1. In project properties - compile, switch off Warnings as Errors if this is on.
2. Set the top 3 errors (Implicit conversion, Late binding; call could fail at runtime and Implicit type; object assumed) to Warning.
3. Switch on Warnings as errors if you like.

Now in the code you can use "#Disable Warning BC42017, BC42016" to disable option strict and "#Enable Warning BC42017, BC42016" to enable option strict again.

By example the following code will compile (but will crash) between those compiler switches:

#Disable Warning BC42017, BC42016
        Dim x As Object = 123.0
        x.abc = 3
#Enable Warning BC42017, BC42016

So I don't think it should be very hard to implement this as:

#Option Strict Off 
        Dim x As Object = 123.0
        x.abc = 3
#Option Strict On

[JustNrik]

I prefer #Option Strict On/Off the most. If anything, I'd like With or Using keywords.