-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Let null
contribute its nullability to method type re-inference
#43571
Conversation
a0126ab
to
7b66c17
Compare
var source = @" | ||
class C | ||
{ | ||
void M(string s) |
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.
string s [](start = 11, length = 8)
s
is not used.
|
||
public readonly struct Optional<T> | ||
{ | ||
public Optional(T value) => throw null!; |
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.
public Optional(T value) => throw null!; [](start = 4, length = 40)
Not used.
|
||
if (avoidTypelessExpressions && | ||
conversion.ConversionKind == ConversionKind.ImplicitReference && | ||
conversion.Operand is BoundLiteral { Type: null }) |
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.
It feels like the current behavior of null
is expected: we pass an untyped BoundLiteral
to MethodTypeInferrer
. But the behavior of default
is unexpected: we pass a typed BoundDefaultExpression
to MethodTypeInferrer
where the type was only determined after running MethodTypeInferrer
in initial binding.
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.
Just to clarify, you're saying we should keep the current behavior for null
(Infer("", null)
would infer string!
and warn, rather than string?
)?
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.
Not necessarily. I'm suggesting the arguments passed to MethodTypeInferrer
in NullableWalker
should match the typed/untyped-ness of the arguments passed to MethodTypeInferrer
in initial binding. So null
and default
would both be passed as untyped arguments. Could NullableWalker
fix up the nullability of the inferred type arguments after MethodTypeInferrer
returns? Such an approach would also need to handle lambda return types so it might get complicated.
In reply to: 416076359 [](ancestors = 416076359)
The scenario is
Infer(s, null);
withvoid Infer<T>(T t1, T t2)
. We currently inferstring!
but want to inferstring?
instead, so that no warnings are produced.The problem is that when we re-infer type arguments with nullability, typeless expressions (like the null stripped of its conversions) do not contribute its type or nullability.
Alternatives considered:
null
its type.default
,switch
and other expressions which get a different bound node once target-typed.Fixes #43536