Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alfonso J. Ramos
    @theraot
    However, after I split the project file, I added back some analyzers I had removed, and had them run on Visual Studio Code with OmniSharp and performance is great there. Because of which I don't think Visual Studio has much excuse for its performance issues. Although, there is no CodeMaid, no IntelliCode and no Resharper in Visual Studio Code, I know those aren't to blame for Visual Studio.
    I'll push Nuget.
    Alfonso J. Ramos
    @theraot
    Ah, by the way, the issue it is not CodeLens either.
    NN
    @NN---
    I feel Rider provides a better experience than VSCode. Btw Did you try disabling Roslyn? https://blog.jetbrains.com/dotnet/2020/05/11/story-csproj-large-solutions-memory-usage/
    NN
    @NN---
    @theraot Please review the changes, and if it is possible release an updated NuGet. Dictionary annotations are super useful when you write C# 9 code for older frameworks
    Alfonso J. Ramos
    @theraot
    @NN--- Are you sure you want MaybeNullWhen instead of NotNullWhen?

    MaybeNullWhen: Specifies that when a method returns ReturnValue, the parameter may be null even if the corresponding type disallows it.

    NotNullWhen: Specifies that when a method returns ReturnValue, the parameter will not be null even if the corresponding type allows it.

    From reading that, I think either can be an issue. On one hand, NotNullWhen(true) can be a lie if what is stored is null. On the other, MaybeNullWhen(false) would require to check for null even if the generic container is defined with a not nullable type.
    Hmm… I'll go test that.
    Alfonso J. Ramos
    @theraot
    From testing: If I have MaybeNullWhen(false) and the type is not nullable, code analysis will still warn about null when false. If I have NotNullWhen(true) and the type is nullable, code analysis will not warn about null when true.
    I conclude NotNullWhen is not really useful here.
    I'll assume that if you added MaybeNullWhen, it is because it is helpful.
    I'll build the Nuget.
    Here you can see the declaration in .NET
    I copypasted from there
    You are correct. You cannot say type is not nullable if it returns true because in C# 9 T means T?? , either nullable or non nullable.
    So the only thing that is true that returning false gives you null
    Alfonso J. Ramos
    @theraot
    @NN--- Sent the Nuget. I'll do the other thing while I'm at this.
    Alfonso J. Ramos
    @theraot
    @NN--- Changed version to 4, allowed unsafe code, merged span pull request
    Can we simply copy Memory et.al, or do we need something else?
    Alfonso J. Ramos
    @theraot
    NN
    @NN---
    Probably yes, but I do not know whether it is possible to backport everything . There is some JIT magic behind some methods.
    NN
    @NN---
    seems like adding NRT annotation to dictionary is not a perfect solution .
    It makes it unexpected in code consuming the library.
    It breaks code that relied on original nullability:
    For instance
    public bool TryGetValue(TKey key,
    #if NETCOREAPP30_OR_GREATER
                [MaybeNullWhen(false)]
    #endif
                out TValue value) => _map.TryGetValue(key, out value);
    WDYT ?
    should it be reverted in order to not break ?
    It sounds like the Expression issue, it makes code for older framework to have features unavailable in newer ones :)
    So, either way you choose you have trade-offs
    Alfonso J. Ramos
    @theraot
    @NN--- Wait, is this a framework problem or a language problem?
    Ah, is this the warning saying that it does not match parent nullability?
    If it is that warning, I think users should suppress it, and that's it.
    There is something similar with notnull generic constraint, by the way
    NN
    @NN---
    It is a library consumer problem. Suppose you used Theraot 1 and didn’t have warnings. Now updated to 2 and overridden TryGetValue gives you warning . Yes the parent nullability doesn’t match. I tend to agree that it is better to annotate as close as possible to latest .NET version.
    NN
    @NN---
    @theraot Hey. There is some problem with Microsoft.Bcl and adding Range.
    Microsoft.Bcl , Microsoft.Bcl.HashCode, Microsoft.Bcl.Async add a lot of types to System.* namespaces. Theraot library does the same.
    The problem that Theraot currently doesn't depend on Microsoft.Bcl, but Range needs System.ValueTuple and System.HashCode which makes some issue Microsoft.Bcl.
    Now the question is about direction, seems like adding Microsoft.Bcl dependency to Theraot will be the simplest solution to not repeat the implementation.
    The drawback here is that Microsoft.Bcl is not updated to match the latest .NET features and semantics.
    On the other hand making own interface IAsyncDisposable means a breaking change to the whole world. Microsoft.Bcl is used by a lot of packages.
    NN
    @NN---
    Ok. The main issue was lack of net461 target. There is a subtle difference between 4.6.1 and 4.6. Microsoft.Bcl needs 4.6.1. I added a new target and will push the change.
    NN
    @NN---
    Please take a look
    It is urgent
    NN
    @NN---
    @theraot Hey. I found some unexpected issue with StringEx.Join.
    I can fix it, but a new version of library must be released.
    Is it possible ?
    NN
    @NN---
    @theraot What is the state of v4 ?