Skip to content
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

Params Collections: Implement "Better function member" section of the proposal #71271

Merged

Conversation

AlekseyTs
Copy link
Contributor

@AlekseyTs AlekseyTs requested a review from a team as a code owner December 14, 2023 23:11
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Dec 14, 2023
@AlekseyTs
Copy link
Contributor Author

@RikkiGibson, @333fred, @dotnet/roslyn-compiler Please review

// Ambiguous for inline collection expression, but 'int' is a better conversion target than 'short' in params case (exact target)
[InlineData("System.ReadOnlySpan<T>", "short[]", "System.ReadOnlySpan<System.Int32>")] // cannot convert int to short
// Ambiguous for inline collection expression, but 'int' is a better conversion target than 'long' in params case
[InlineData("System.ReadOnlySpan<long>", "T[]", "System.Int32[]")] // cannot convert long to int
Copy link
Member

@333fred 333fred Dec 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is particularly surprising. Is part of the open question you have for LDM? #Resolved

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is particularly surprising. Is part of the open question you have for LDM?

I do not find this surprising for this scenario at all. The better conversion rule can, of course, have a different effect and that is explicitly called out in the specification. Directly in the relevant section, with examples, rather than as an open question.

@AlekseyTs
Copy link
Contributor Author

@RikkiGibson, @dotnet/roslyn-compiler For the second review

@RikkiGibson RikkiGibson self-assigned this Dec 15, 2023
@@ -2653,6 +2701,14 @@ private bool IsBetterCollectionExpressionConversion(TypeSymbol t1, Conversion co
Conversions.ClassifyImplicitConversionFromType(source, destination, ref useSiteInfo).IsImplicit;
}

private bool IsBetterParamsCollectionType(TypeSymbol t1, TypeSymbol t2, ref CompoundUseSiteInfo<AssemblySymbol> useSiteInfo)
{
CollectionExpressionTypeKind kind1 = ConversionsBase.GetCollectionExpressionTypeKind(Compilation, t1, out TypeWithAnnotations type1);
Copy link
Contributor

@RikkiGibson RikkiGibson Dec 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider naming type1 and type2 something like elementType1 and elementType2 to better distinguish them from t1 and t2 #Resolved

@AlekseyTs AlekseyTs enabled auto-merge (squash) December 16, 2023 18:19
@AlekseyTs AlekseyTs merged commit 88c8859 into dotnet:features/ParamsCollections Dec 18, 2023
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Feature - ParamsCollections untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants