You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: using @AlekseyTs 's formalization from yesterday, i don't think this would be a break. We would still bind with the original meaning, and only fall back to the new meaning if htat fails.
@cston i don't like that approach as i think the original code they have is reasonable and they shouldn't have to add explicit types to workaround it. The particular example is somewhat egregious as i think the language is sliding backwards here. Specifically, given teh type Func<int> it seems wrong to me that an instantiation of T -> Func<int> is treated as good as an instantiation of Func<T> -> Func<int>. The latter seems to intuitively be what someone would want and expect. Even if T -> Func<int> is a possible inference, it should not be as good as Func<T> -> Func<int>. I think we should revisit this and not have people have to provide parametr types in cases like these.
Note that linq is a high pri api that we should endeavor to keep working IMO.
Version Used: 4.0.0-5.21453.15 (2bbf85b)
Steps to Reproduce:
Expected Behavior: No errors.
Actual Behavior:
@CyrusNajmabadi asked me to open an issue for discussion.
/cc @333fred @cston
The text was updated successfully, but these errors were encountered: