-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make System.HashCode available as standalone nuget package #24712
Comments
I'm sorry, but I must disagree. There are some fundamental differences between #24328 and this issue:
Original request:
Recent question from @CyrusNajmabadi about the availability
In PR dotnet/roslyn#24161 @CyrusNajmabadi already takes dependency on
If there are any technical restrictions or other reasons that prevent |
This sounds like it would work similarly to ValueTuple (shipped as a combination of in-box and out-of-band). I do like the idea of making HashCode available to more people sooner, but I seem to recall that what we did with ValueTuple had some complications. @karelz, do you have details/thoughts on that? |
We call these "partial OOBs" and they are incredibly hard and expensive to get right and maintain. We try really hard to avoid introducing new ones. If we want to ship HashCode as independent package, the in-box and out-of-band packages should have different assembly names. It would be basically two different types. |
@CyrusNajmabadi, would Roslyn be able to take advantage of such an out-of-band package? You indicated previously that adding a package reference as part of a code fix might be too heavyweight. |
Yes. In that we already have a mechnism to suggest nuget packages to users if they reference type names from those packages. We can also offer specific nuget packages in certain circumstances. For example, we know specifically about System.ValueTuple and we offer that package if you use tuples. That said, IMO, there's little pressure to produce such a nuget package. I think we're at a reasonable point now. We have reasonably good stories for users who are targeting newer and older frameworks. If they're targetting newer frameworks, we'll use System.HashCode. If they're targetting older ones, we'll just spit out a reasonable GetHashCode impl. IMO, this is a good-enough situation for users. It's already leaps and bounds ahead of what's the current state of affairs. |
In other words: if someone did the work to make a nuget package, i think i'd b willing to surface that in some specialized way. But I'm not specifically asking for that package to be created. I'm satisfied with where we are now. |
I think this would be more like System.Numerics.Vectors or Microsoft.Net.Http, than ValueTuple, but yes that was the intend here. I was wondering why this package is part of the core runtime at all. Couldn't this be published completely out of band? What part of the core runtime takes dependency on this?
While this is true from the IDE perspective, I'd like to point out that there are plenty developers out there, that would benefit from such a package. Take for instance all the the line-of-business application devs:
While those developers are well served by the generate equals/hashcode code fixes (as @CyrusNajmabadi pointed out), I still see great value in having System.HashCode on the other platforms because: I would also suggest to create a roslyn analyzer, that detects GetHashcode anti-patterns (e.g.
And as a last note. This package would nothing less than bring .NET on a par with Java 7 from 2011. [PS: You may have a look how reviewed JDK-6891113 back then 😄]. |
I can confirm the netfx LOB developers' hope that we'll finally get a palatable API for implementing GetHashCode. That said, I don't want a repeat of the series of pitfalls that I recall coming with partial OOB packages. I think partial OOBs could do just fine if a lot of design effort was put into specifically making them a first-class scenario on all platforms, perhaps by creating an improved way to unify types at runtime. |
That's fine. My point is that this is something you guys need to figure out :) You get to decide if this is the right choice for how you deliver and whatnot. The IDE specifically is not requesting this. I'm only pointing this out so that whoever is making the decisions here doesn't think that that ask is coming from that direction. |
Just checking in. I have multiple .NET Framework |
It seems that System.Hashcode is going to be part of a future dotnet/standard#823 This makes shipping it as a package irrelevant. |
@MaStr11 |
For anyone struggling with a need of It was created by contributors, colleagues and me to specifically address that kind of pains: https://github.com/gapotchenko/Gapotchenko.FX Readily available as a NuGet package: Enjoy and be productive. |
It seems that |
Hi, |
@fabricefou this issue is closed -- please open a new issue if you believe there's a bug or new work. |
Yes you're right. #42808 |
The new
System.HashCode
type seems to be distributed as part of the core runtime (Based on this Comment by @morganbr in #19621).System.HashCode
could could benefit a wider audience, if it is distributed as standalone (.netstandard based) package. Every .NET developer on every platform sooner or later faces the problem to implementGetHashCode
and doing so is fraught with pitfalls (there are more than 350 comments in total in this repro alone discussing a good hash code algorithm and a good API to expose it). Therefore an official standalone package with a good general purpose algorithm and a well designed API would be much appreciated. (I would even suggest to makeSystem.HashCode
part of .netstandard, but that's another topic).The text was updated successfully, but these errors were encountered: