-
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
IDE0028 raised erroneously for collection type with Add(T) and IEnumerable<T[]> #72956
Comments
@stephentoub do you have a real world example of this? We're aware of TheoryData, but we're trying to collect a list of all these types to help with future lang design. Thanks! |
TheoryData :) |
@stephentoub Perfect. I'll let @cston dupe this as something known. We are working on this. If you run into other real-world apis, def let us know as we want any changes here to work for all of them. Thanks! |
Collection expression conversions require the elements to be implicitly convertible to the collection iteration type. That requirement still holds in the latest proposal for target types that implement |
#73655 seems to be related to this and contains a real world example with the FluentValidation library. |
In the repro, the compiler is behaving as expected reporting an error for Reassigning to @CyrusNajmabadi since the original diagnostic IDE0028 is reported from the analyzer. |
Should this be tagged with the label "New Feature - Collection Expressions"? |
Version Used:
Version 17.11.0 Preview 1.0 [34804.211.main]
Steps to Reproduce:
Diagnostic Id:
IDE0028
Expected Behavior:
No diagnostics.
Actual Behavior:
IDE0028 triggers and the fixer rewrites the
new() { "Hello" }
to be["Hello"]
, which then fails to compile witherror CS0029: Cannot implicitly convert type 'string' to 'object[]'
.cc: @CyrusNajmabadi
The text was updated successfully, but these errors were encountered: