-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Conversation
9484f9c
to
de50319
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (commit 2)
{ | ||
elementType = default; | ||
return CollectionExpressionTypeKind.ImplementsIEnumerableT; | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{ | ||
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(); |
There was a problem hiding this comment.
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
There was a problem hiding this 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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (commit 4)
There was a problem hiding this 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
There was a problem hiding this 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)
See corresponding spec change.
Relates to test plan #66418