The place for the VB community to join our collective voice! See https://github.com/CommunityVB/Main for more info.
?
as a shortcut for the snippet, but didn't work as it is used to show the snippet context menu. It would be nice ;)
cwl
.
@CyrusNajmabadi
Does the visual basic specification and compiler, assert atomicity within "multi-part" block structures.
For example the ElseIf
in an If Then ... End If
block.
We have the following code (as is).
' statements 0
If someCondition = True Then
' statements 1
ElseIf someCondition = False Then
' statements 2
Else
' statements 3
End If
' statements 4
is transformed into
' statements 0
If someCondition = True Then
' statements 1
Else
' *** What prevents evaluate of someCondition being different from prior evaluation.
If someCondition = False Then
' statements 2
Else
' statements 3
End If
End If
' statements 4
Is someCondition
asserted to be atomic ( non-changing ) between each usage?
As from my knowledge the lowered form does not seem to have that "ambient property", or does the transformation production obtain that "ambient property" from the transformation of an ElseIf
statement.
If it doesn't would a copy of the value of "someConditon" into "tmp" prior to the If Block, and rename the usage of "someCondition" with on this block to "tmp". Gain that guarentee.
I think this is something to do with Side-Effects and/or Contract propagation.
Otherwise, if the variable you are testing is not a local variable but instead a property of a class... the class could literally return a different result each and every check.
Alternatively (I believe) this could be resolve by using Select Case
.
If it doesn't would a copy of the value of "someConditon" into "tmp" prior to the If Block, and rename the usage of "someCondition" with on this block to "tmp". Gain that guarentee.
This would only be true if the developer honored this restriction.
is predominantly is lowered to an
If ... Then` structure, so same suitable effect exists. In a "pure" single threaded non-eventing/interuptting evaluation it trivial and can be ignored. In a non-linear evaluation environment it does, so assisting the programmer to have awareness, or code-fix.
If
checking is completely within the context of the If
statements. So multi-threaded code shouldn't be an issue (in this example - which I feel is more common). In the event the value does change, there is a high possibility this was what the developer desired/intended. Now if we talk about properties... the value of the property is controlled by the object and one would have to wonder under what conditions that this would be an issue. In some circumstances, the value changing between the If
statements may actually be desired. There are also two very different Select Case
models (lowering)... as you said there is one that is basically a bunch of individual If
statements while the (ultimately) desired lowering would be the "jump list". To my knowledge, the "jump list" version would evaluate the value once and is significantly faster than and something I tend to try to setup for under normal conditions. If the desire is to make the variable unchanging, there are (of course) mechanisms in place to assist with that as well. But I don't think there is a "blanket" mechanism or even warning that would cover all the scenarios and my gut is telling me this would create more confusion than it would potentially address any sort of pitfall. In other words, I can't imagine how one would look at the code a know whether or not this might be a potential issue across all the possible scenarios that could exist. I could, of course, be missing something... so there is always that. ;-)
and is a code fix possible?
Of course it would be better if intellisense take snippets shortcuts into account.
A nice surprise: @sharwell pointed out that there is an option to trun on this feature!
https://github.com/dotnet/roslyn/issues/37049#issuecomment-998997945
something
, otherthing
) are to be treated as having a single immutable value (or the "value" will not be altered.). Is there enough evidence to support or proof that statement, from the specification.
Imports System.Runtime.CompilerServices
Public Module Tools
<Extension>
Public Iterator Function GetEnumerator(
range As ValueTuple(Of Integer, Integer, Integer)
) As IEnumerator(Of Integer)
Dim start = range.Item1
Dim [end] = range.Item2
Dim [step] = range.Item3
If ([step] > 0) Then
For i = start To [end] Step [step]
Yield i
Next
Else
For i = start To [end] Step [step]
Yield i
Next
End If
End Function
End Module
Sub Main(args As String())
For Each i In (1, 10, 2)
Console.WriteLine(i)
Next
End Sub
readonly
is used with functions and properties to state that they can't change the values of the structure. It is a confusing word, and if VB.NET is meant to have a similar functionality some day, fourthly it can't use this keyword for this purpose, because ReadOnly is already used with properties. Luckily, vb had the perfect keyword for the job: Preserve
, which is used with ReDim to preserve the contents of the array.
public Preserve Overrides Function ToString() As string
Return ""
End Function
I'm having a hard time understanding the purpose/reasoning of this (given the provided context/example)... meaning that it's pretty much given what overriding ToString()
is "supposed" to do. Adding additional keywords/functionality to "enforce" this doesn't seem to make sense. And where would this "preserve" be? At the implementation or the origination site? If at the origination, then what if you (for the circumstances at hand) you did want to "change something" (caching including invalidation). Also, is this for a Structure
or a Class
? You mention structure, so I'll go with that for a moment.
' Take care not to change the structure when implementing the following function...
Public Overrides Function ToString() As String
Return ""
End Function
The above code serves the same purpose... another possibility is...
<ReviewIfChangesToStructureGenerateError()>
Public Overrides Function ToString() As String
Return ""
End Function
Leveraging analyzers and whatever rules your team deems appropriate.
Given that we are talking about a structure and depending on purpose of the structure, changes by the dev to the structure are pretty easy to mitigate/maintain since we are talking about a structure - the implementation details of a structure, by their very nature, is pretty light... it's a Structure
after all (not a Class
).
Additionally, it is possible to set the "properties" of a Structure
to be ReadOnly
. Why not enforce the "no changes allowed" at that level rather than at a method level? It seems odd to me that you would single out individual methods as being "read only" while others potentially not being read only.
To take this from another direction... you are mentioning a potential change to the language based (from what I determine from what you wrote) solely on "C# does this" and you are looking for a way to mirror functionality that another language has for the sake of mirroring. What problem(s) does doing this address? What is being addressed (other than mirroring)? How is this going to help me do my job (better)?
Just because another language does something a particular way (regardless of popularity) doesn't mean that all other languages should follow the same approach.