[Proposal] Option Unchecked On | Off

[rskar-git]

Under "Advanced Compiler Options..." there is "Remove integer overflow checks". That's a cool feature to have, but it's an all-or-nothing proposition.

Could we have a new Option:

Option Unchecked On

The "Remove integer overflow checks" setting could be the default. This new option would only affect the *.vb file it's in. This would make having modulus binary arithmetic operations available when needed, and regular overflow checks also available within the same project.

[Bill-McC]

Think I'd prefer a block construct

UnChecked

End UnChecked 

[rskar-git]

I'd be OK with a block construct (but would that mean the need for a complementary Checked block, or just tell folks to leave the compiler setting alone?), but the Option way is still keeping with the VB idiom, and it seemed to me to be the easier way to go. Since Partial Classes are a thing, one could still mix and match between the two modes within the same class if desired. I'm also shy of introducing yet another keyword into the language - can you imagine some poor soul out there already using Unchecked as an identifier? Who shall we burden with the square bracket fixes? :)

[Bill-McC]

VB has heavily relied on file level options, but also has compiler directives: https://github.com/dotnet/vblang/blob/master/spec/preprocessing-directives.md

So the issue of breaking due to another keyword is addressed if we keep with the # style: `#Checked Off ....

End Checked`

or "UnChecked", or something more descriptive such as IntegerOverlowChecking On|Off

[rskar-git]

To date, VB has used compiler directives for conditional compilation, and for meta-information about the source (which have no effect on compilation). I have a feeling that any compiler directive that effects compilation at a fundamental level is going to be a hard sell.

[Bill-McC]

I think VB is long overdue for compiler directives at code, rather than file level. When VB .net first came about (some 15 years ago), it had a legacy from VB6/VBA/VBScript and the file based Option Explicit, Compare and Base. It dropped Base due to vector arrays, and added Strict. Compare was kept for compatibility reasons but really should have long ago been depreciated: it's probably easier to leave it, but it can be a nasty switch thrown at project level that may not be initially obvious. I think it came from the VB3 to 4 transition with unicode introduction. Explicit is from the scripting side of things and is one I really wish didn't exist. Strict when added was a welcome addition, and makes sense at project and file level to allow for compatibility (especially with COM). And then Infer was added. Of them, today, I think we ideally should just have Strict and Infer, and both of them would have huge benefits being at block level rather than file or project level, especially Strict which would allow close to the experience of dynamic in C# without making everything strict off. IOW: just because something was done a certain way, doesn't mean it was the only way for the language going forward or that we need to add to past mistakes or limitations. I think it'd help to modernize VB and give it a greater level of conceptual compatibility with other languages such as c# if it was a block construct for checked/unchecked, and likewise "strict" and "optimize" as block directives

[AdamSpeight2008]

File level options

Option Checked On
Option Checked Off

would fit the stylistic look of VB.net

[aarondglover]

I ageee with @AdamSpeight2008 that the File level declaration is more idiomatic with the VB language. Used in conjunction with partial classes it would go someway to providing the flexibility of a block statement

[Bill-McC]

What you refer to as idiomatic is to me, more problematic. Let's say you have some code you want to fine tune to checked off, which is generally a performance tuning operation. To do so, you'd have to create and check in a new file and document it etc, just to tune existing code. And if you find it has a negative side effect, you then have to merge it back or have all these relic partial classes purely for performance tuning. That idiom is actually an abuse of partial classes, making them a maintenance hassle, when their intention was to split code spit from human code, not to split every time we want a compiler feature

[rskar-git]

@Bill-McC, even if the original motivation for partial classes was all about auto code/manual code dichotomy, they are now employed for many other accepted reasons - e.g. see http://stackoverflow.com/questions/3601901/why-use-partial-classes. It isn't problematic when the workaround is straightforward and at worse a mere annoyance. Right now I can't easily mix these integer arithmetic modes within the same assembly (like one can easily do in C#) - that's what's problematic. As things currently stand today, if I insist on mixing modes in VB into a single assembly, I must learn the ins-and-outs of .NET modules; that sort of workaround isn't straightforward.

@AdamSpeight2008, OK with Option Checked Off too. In the end, I just want an easy enough way to mix modes. I suggested Option Unchecked On because that's aligned (semantically speaking) with the compiler setting (i.e. /removeintchecks means unchecked), and because the C# keyword for it is "unchecked". On the other hand, after looking at Option Compare, what do you think of this?:

    Option Integer Unchecked
    Option Integer Checked

[Bill-McC]

@rskar-git I agree that the current way of dealing with unchecked/checked integer arithmetic in VB is unsatisfactory: that alone is not an argument for increasing Option statements at code file level. This addition would bring the possible combinations to something like twelve : and the idea of having twelve different partial classes to allow just for compiler options is ludicrous. And what when /if we add Option Otpimize, would be it be twenty four different possible partial classes. If we look at C#, unchecked is a block construct. It makes more sense that way. Also if we say something is VB style, yet ignore the reasons things were done that way, in particular the Option statements we have today, and why we have partial classes , we cannot claim it is in the spirit of VB just because it looks similar but ignores all the underlying principles: and even more so when it adds complexity. Anyway, my $0.02 worth: Strong vote against adding yet another Option at file level; strongly in favour of block level # construct

[rskar-git]

@Bill-McC, I do see the point of why a block construct would be better syntactically and practically - I certainly agree with you there. Between a block construct and a file-level Option, I would also prefer a block.

However, having said that, my main concern is on the relative level of energy that VB receives versus other projects, such as C# and F#; afterall it has been recently declared that there no longer is a priority in maintaining features parity between C# and VB. The compiler setting has been there for a very long time, perhaps since day one. Yet in all that time, apparently the checked/unchecked thing was never in the plans for VB!

If a new block can be done in about the same effort as a new Option, then great! But my gut feel is that the Option route is likely to be the much smaller job.

So that's my $0.02. Whether block or Option, just want to have it.

[gilfusion]

Just a syntax suggestion, building on the one @rskar-git suggested earlier, to make it clearer what is being checked or not as a result of these directives:

Option Overflow Checked
Option Overflow Unchecked

[rskar-git]

@gilfusion I think Option Overflow might bring its own confusion: Some may wonder if that also applies to floating-point operations too. Anyway, I was only asking for some way to have more granular control over the compiler's "Remove integer overflow checks" setting.