-
Notifications
You must be signed in to change notification settings - Fork 343
Added a bi-directional dictionary #2613
Added a bi-directional dictionary #2613
Conversation
Still needs tests.
I have seen tests like this (using JsonReader within async and pipes) fail intermittently on OSX. I will try to repro locally and see what's going on when I get some time. In the meantime, I will disable it.
|
@dotnet-bot test Innerloop OSX10.12 Debug Build and Test |
This will need careful review, it might take a bit of time to get to. |
… entries to reduce the number of fields the type has.
@danmosemsft Do we have any good news on this? Can't wait to have BiDictionary now :) |
@danmosemsft Is corefxlab able to consume C#8 yet or will that have to wait until after .NET Core 3 is released? Just wondering if I should update this PR for nullable references. |
Any update on this? |
with respect to C#8, @pgovind was working on the infra in this repo and can answer that. @pgovind , perhaps this is something you can help shepherd? You may have feedback on the API but being in corefxlab it does not go through the .NET API approvals process. More generally, I know we (continue to do) a less than great job at helping build a set of "non core collections". I'm exploring a possible new approach. Meantime, we can keep doing it here. |
@danmosemsft I copied related the code and published a (temp) nuget package: https://github.com/sdcb/Sdcb.Collections Hope it helps :) |
Once this is merged: #2795 we will be able to have a new enough compiler so that we set LangVersion to 8 or latest. |
Would it be possible to also add the thread-safe concurrent version of it? In relation to ConcurrentDirectionary / Dictionary. |
@Symbai I'm afraid that's beyond my current area of expertise and would require someone else with far greater concurrency knowledge than myself. |
@danmosemsft Is this experimental collections package dead? |
@TylerBrinkley no, but we have been fully occupied with work on .NET 5.0: realistically, reviewing/designing/implementing collections API is expensive and it's always going to contend for our resources vs other product work, unfortunately. As mentioned before, it would be great to find a model for collections that would allow the community to move more quickly, but still have the attributes of reliability and trustworthiness. One possibility we've discussed in the past is for several community members to create and own a project for it, which would aspire to be within the dotnet foundation ("dotnet/collections" perhaps?). So it wouldn't be owned by the .NET Libraries team, but would aim to be the de-facto, trustworthy collections package - the primary place that the .NET team would point folks to. Depending on how things pan out, I could imagine the collections in this repo potentially migrating there to start things off. With the right set of folks interested in running such a project, we could potentially help with the conversation with the DNF as well. I expect we would sometimes offer PR's there, too. I don't know whether that's an idea that resonates with folks. |
BTW, I apologize for not being more responsive. I think this illustrates we haven't found the right model to operate at a reasonable pace here (having tried two models -- working directly in the product, and working here in corefxlab) |
Thanks @danmosemsft for your response. I understand. Given the lack of resources Microsoft has dedicated to this I agree the best course of action would be to move this to a community driven project ideally under the .NET Foundation with some key members, hopefully a few from Microsoft, to curate it. I think it would be very important to state from the outset that the project's goal is not to build a new set of collections from the ground up and not to address deficiencies in the BCL collections implementations or interface hierarchy. The goal should be to complement the existing BCL collections with the hopes that some may prove useful enough to be included directly in the BCL itself. We could then Type Forward the implementation in that case. If we multi-target we would then need to maintain our own implementation copy for earlier targets. I'd love to be involved but as of late I haven't been able to dedicate nearly as much time to OSS due to various factors so for now would only be able to help in a limited fashion. |
Closes #446