Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    CyrusNajmabadi
    @CyrusNajmabadi
    currently snippets are in maintenance mode only
    so this would be backlogged unless you can contribute the fixes.
    we've mentioned this before, but backlog items are already lower pri than what the team can currently afford to look at.
    Mohammad Hamdy Ghanem
    @VBAndCs
    I am putting these notes if the filed isue dotnet/roslyn#37049
    Adam Speight
    @AdamSpeight2008

    @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.

    CyrusNajmabadi
    @CyrusNajmabadi
    1. it entirely depends on what 'someCondition' is (like a field/prop/parameter/local).
    if it's a field/prop, definitely not. indeed, it's the opposite. each time it will be read from teh original source
    if it's a parmaeter/local. sure. however, it will depend on what is in the rest of hte method
    for example, if it's captured by some lambda and the lambda mutates it, then it will be different
    so, absent any more info about the code, i cannot say
    but i can certainly say you can only depend on this if your code operates in a very specific fashion.
    Adam Speight
    @AdamSpeight2008
    @CyrusNajmabadi
    How do we advise the programmer that this suitable exists, and is a code fix possible? I can only think of using sencasing it within a SyncLock(someCondition) ... End SyncLock We'd need the notion of immutable usage, and enforcement.
    Cory Smith
    @DualBrain
    * What prevents evaluate of someCondition being different from prior evaluation.
    You could put this variable in an immutable property/class...

    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.

    (Unless, of course, that variable was some sort of immutable property.)
    Adam Speight
    @AdamSpeight2008
    Adam Speight
    @AdamSpeight2008
    'Select Caseis predominantly is lowered to anIf ... 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.
    Cory Smith
    @DualBrain
    I suppose I'm not following what is trying to be resolved here. I mean I do get the idea that the value could change under some conditions... but there are many ways to ensure that the code executed against a variable is safe (isn't going to change). If you pass in a variable to a method, that variable is (if Byval) local to that routine... so the only code that will modify that variable within the scope of the 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. ;-)
    CyrusNajmabadi
    @CyrusNajmabadi
    How do we advise the programmer that this suitable exists,
    I don't know how to read your question.
    and is a code fix possible?
    A code fix for what?
    It's unclear what the problem is that you're even describing.
    Mohammad Hamdy Ghanem
    @VBAndCs

    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

    Adam Speight
    @AdamSpeight2008
    It's hard for me to explain, as it very abstract especially the exact terms.
    I think that if we consider Nullable References as a form of "value tracking" (is this allways non-null etc), we could also in theory also track mutability of "variable".
    Adam Speight
    @AdamSpeight2008
    If the specification states that, within this context / region / section. That these variables (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.
    Cristian FRC
    @cristianlt23
    I wish you all a Merry Christmas and a New Year full of achievements!๐Ÿงก ๐Ÿ’› ๐Ÿ’š ๐Ÿ’™ ๐Ÿ’œ
    Cristian FRC
    @cristianlt23
    @VBAndCs , I missed you, I'm glad you came back!!!
    Mohammad Hamdy Ghanem
    @VBAndCs
    Thanks @cristianlt23 .I am in a c# mode now. Happy new year.
    Luckly, I am dicovering somethings about vb via c#, like the cw snippet, and adding a GetEnumeration inner or extension method to classes to be supported with for each. This allows using this syntax for example
    Foe Each i in (1, 5)
    Mohammad Hamdy Ghanem
    @VBAndCs
    Console.writeline(i)
    Next
    Sorry, GetEnumerator.
    Using gitter app.
    Mohammad Hamdy Ghanem
    @VBAndCs
    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
    Mohammad Hamdy Ghanem
    @VBAndCs
    In c#, 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
    Cory Smith
    @DualBrain

    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.

    Cory Smith
    @DualBrain
    So I suppose the shorter response is simply... why? What problem is this addressing?
    CyrusNajmabadi
    @CyrusNajmabadi
    I agree. Those are all good questions.
    I'm not even really sure what you're trying to do in the c# version.
    (shown in the c# channel)
    Real world cases would be helpful. Thanks!
    Cory Smith
    @DualBrain

    Both of these links tell you what you can do... but neither provide any reason(s), scenario(s), case(s) as to WHY. Worse still, reading through the documentation it appears that in C# 7 they added this and in subsequent releases added even more "stuff" to shore up the addition of this... and even after all of that there are caveats, compromises and potential gotchas that you have to watch out for. All of this knowledge without once specifying any sort of reason as to why you might want to venture down this particular rabbit hole.

    With that said, someone mentioned in the Roslyn channel

    readonly types and members was specifically added to make it easier to pass structs around by reference without accidentally creating copies of them.

    OK, so there is now a reason. However, I have to wonder the value of this in something like VB. What circumstance(s) is a VB dev needing something like this where there is such a performance/memory impact that they could encounter where having a copy of a structure is an issue? I can imagine it happening in theory, but really having a hard time thinking of a circumstance like this in practice. Worse still is the fact that in order to "guarantee" that the struct isn't copied, variables are potentially copied within the implementation of the method(s) unless the "variable" (member) is already read only... so unless the member is already read only the copy isn't necessarily completely prevented (meaning there will be an impact "somewhere").

    CyrusNajmabadi
    @CyrusNajmabadi
    Right. Furthermore, we specifically added these features because teh copy-beahvior has been the default for C# structs since 1.0