Extensions for immutable collection builders (#21055) #31071
Conversation
Added extensions for immutable builders, which should be prefered over the extensions on IEnumerable because of performance benefits.
davidkaya
changed the title
|
No null checks? |
| /// </summary> | ||
| /// <param name="builder">The builder to create the immutable array from.</param> | ||
| /// <returns>An immutable array.</returns> | ||
| [Pure] |
There was a problem hiding this comment.
Given that [Pure] has no runtime impact, why isn't the attribute included in the ref assemblies so that analyzers can do their work based on it?
There was a problem hiding this comment.
Looking at it (and not the author) I'd guess that it's because none of the other definitions in the ref assembly have them and he followed the existing pattern on the assumption that someone in the past had good reason to do this.
Adding them in ref would require a dependency on System.Diagnostics.Contracts which would seem an odd thing to do.
There was a problem hiding this comment.
Agreed: this PR itself looks consistent with precedent. So my question was perhaps more directed at the authors of the ref assemblies in general. @danmosemsft @csharpfritz perhaps?
There was a problem hiding this comment.
I think I was included incorrectly on this...
There was a problem hiding this comment.
[Pure] is part of Contracts, right? We don't use or enforce those and generally have been removing contract annotations. I believe we discussed this before in the context of immutable collections in fact and @AArnott did you indicate you didn't believe in them either? In which case I guess these can all be removed unless they are somehow still useful to .NET Framework consumers even though they're not on the ref assembly and probably not consistent either.
There was a problem hiding this comment.
It seems to me we likely want an analyzer proving it adds value first.
Right. Based on the past experiments with Code Contracts, it is very hard to get a return on investment with this. The annotations do catch a few bugs, but they require a prohibitive amount of manual work to do that.
There was a problem hiding this comment.
Annotations aside, if the compiler included an analyzer with a hard coded list of most commonly misused pure functions (even just those on String) it would provide non zero value with ?no false positives. 😃
There was a problem hiding this comment.
Based on the past experiments with Code Contracts, it is very hard to get a return on investment with this.
Code Contracts preceded roslyn analyzers, and required custom build steps, VS extensions, and/or post-compilation IL-rewriting . Roslyn analyzers are proven to be effective and popular. Let's not let Code Contracts' failure deter us from tapping Analyzers for solving this simple issue.
There was a problem hiding this comment.
The Pure attribute is checked by Rule CA1806 in Microsoft.CodeQuality.Analyzers.
There was a problem hiding this comment.
Thanks for redrawing attention to this, @Grauenwolf. I've filed a separate issue to track the issue: https://github.com/dotnet/corefx/issues/34778
|
@safern ping? |
|
@davidkaya would you mind fixing the merge conflicts? |
|
@safern Should be fine now. |
Thanks. |
…otnet/corefx#31071) * Extensions for immutable builders (dotnet/corefx#21055) Added extensions for immutable builders, which should be prefered over the extensions on IEnumerable because of performance benefits. * Extension for immutable sorted dictionary builder (dotnet/corefx#21055) * Extensions for immutable builders in the reference api (dotnet/corefx#21055) * Tests for immutable builder extensions (dotnet/corefx#21055) * Null check in extensions for immutable collection builders (dotnet/corefx#21055) Commit migrated from dotnet/corefx@9f404b4
Added extensions for immutable builders, which should be prefered over the extensions on IEnumerable because of performance benefits.
Fixes #21055.