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

Collection expressions: use iteration type for convertibility of element types #71397

Merged
merged 6 commits into from
Jan 9, 2024

Conversation

cston
Copy link
Member

@cston cston commented Dec 21, 2023

See corresponding spec change.

Relates to test plan #66418

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Dec 21, 2023
@cston cston marked this pull request as ready for review December 22, 2023 19:10
@cston cston requested a review from a team as a code owner December 22, 2023 19:10
Copy link
Contributor

@AlekseyTs AlekseyTs left a comment

Choose a reason for hiding this comment

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

LGTM (commit 2)

@cston cston requested a review from a team December 22, 2023 20:39
{
elementType = default;
return CollectionExpressionTypeKind.ImplementsIEnumerableT;
}
Copy link
Member

Choose a reason for hiding this comment

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

Discussed offline:
It feels strange for GetCollectionExpressionTypeKind to introduce a concept of "element type" in some cases.
Could we align on the concept of iteration type for all kinds of collections and add the special cases to TryGetCollectionIterationType instead, or call TryGetCollectionIterationType here and rename elementType->iterationType?
That would simplify concepts and align with the spec better.

Copy link
Member Author

@cston cston Jan 9, 2024

Choose a reason for hiding this comment

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

Thanks for the suggestion. I agree, we should refactor these two methods, possibly moving calculation of iteration type to TryGetCollectionIterationType exclusively or having one method call the other. Let's refactor as necessary after completing other expected changes here.

base(elementConversions)
{
Debug.Assert(collectionExpressionTypeKind != CollectionExpressionTypeKind.None);
Copy link
Member

@jcouv jcouv Jan 9, 2024

Choose a reason for hiding this comment

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

consider adding assertion that elementType is not null (we already have such assertion in caller, but I think it would make sense here) #Closed

{
private List<string> _list = new();
public void Add(string s) { _list.Add(s); }
IEnumerator<string> IEnumerable<string>.GetEnumerator() => _list.GetEnumerator();
Copy link
Member

@jcouv jcouv Jan 9, 2024

Choose a reason for hiding this comment

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

_list.GetEnumerator()

nit: consider removing superfluous implementation

{
private List<T> _list = new List<T>();
public void Add(T t)
{
Console.WriteLine("Add {0}", t);
_list.Add(t);
}
IEnumerator<T> IEnumerable<T>.GetEnumerator() => _list.GetEnumerator();
Copy link
Member

@jcouv jcouv Jan 9, 2024

Choose a reason for hiding this comment

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

consider making the private IEnumerable.GetEnumerator() implementation below throw #Closed

@jcouv jcouv self-assigned this Jan 9, 2024
Copy link
Member

@jcouv jcouv left a comment

Choose a reason for hiding this comment

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

LGTM Thanks (iteration 3). Small test suggestions and a suggestion for follow-up on GetCollectionExpressionTypeKind/TryGetCollectionIterationType design

@jcouv jcouv added New Feature - Collection Expressions and removed untriaged Issues and PRs which have not yet been triaged by a lead labels Jan 9, 2024
AlekseyTs
AlekseyTs previously approved these changes Jan 9, 2024
Copy link
Contributor

@AlekseyTs AlekseyTs left a comment

Choose a reason for hiding this comment

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

LGTM (commit 4)

@AlekseyTs AlekseyTs dismissed their stale review January 9, 2024 19:51

It looks like CI is failing

Copy link
Contributor

@AlekseyTs AlekseyTs left a comment

Choose a reason for hiding this comment

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

LGTM (commit 6), assuming CI is passing

Copy link
Member

@jcouv jcouv left a comment

Choose a reason for hiding this comment

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

LGTM Thanks (iteration 6)

@cston cston merged commit 2b2c695 into dotnet:main Jan 9, 2024
25 checks passed
@cston cston deleted the use-iteration-type branch January 9, 2024 22:10
@ghost ghost added this to the Next milestone Jan 9, 2024
@Cosifne Cosifne modified the milestones: Next, 17.10 P1 Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants