ILSpy

9645 Commits

54 Branches

94 Tags

91 MiB

Branch: fix/lambda-parameter-syntax

Commit Graph

Author	SHA1	Message	Date
Christoph Wille	7bf102f3b4	Keep the default literal's type when a conversion is unwrapped Making a conversion implicit by unwrapping it hands the operand to a different target type, and a default literal takes its value from that type: "S? x = new S?(default)" holds a value, while "S? x = default" is null. Unwrapping the nullable constructor around a shortened literal therefore turned "S? x = default(S)" into a null nullable. The literal is spelled out again whenever unwrapping moves it to a type other than the one it was shortened from. Converting a using resource to the declared variable type is unconditional now (except when the declaration says "var", which supplies no type): the declaration always spells the type out, so any conversion to it may stay implicit, which is also what shortens default(T) there. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	4 weeks ago
Christoph Wille	fe9f6db3ee	Emit C# 7.1 default literals where the context supplies the type Shortening default(T) is the same problem as removing the redundant cast around a lambda whose delegate type the context already fixes, so it uses the same mechanism: ConvertTo makes the explicit type implicit when the conversion is an identity conversion and the caller allows an implicit one. The literal keeps the type it was shortened from, so any later conversion to a different type - or any context that requires an explicit type, such as an overload resolution recheck falling back to CastArguments - can spell default(T) out again. That keeps the value intact where the bare literal would change it, e.g. "object o = default(SomeStruct)", which boxes a non-null struct while "default" would be null. Because the shortened literal resolves to DefaultLiteralResolveResult, CallBuilder's existing overload resolution recheck sees a real default literal and rejects ambiguous calls on its own; no separate bookkeeping about which arguments may stay untyped is needed. Only the contexts that supply no target type at all restore the explicit form: an awaited expression, and arguments of operator methods, which later become operator or cast syntax rather than calls. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	4 weeks ago

Author

SHA1

Message

Date

Christoph Wille

7bf102f3b4

Keep the default literal's type when a conversion is unwrapped

Making a conversion implicit by unwrapping it hands the operand to a
different target type, and a default literal takes its value from that
type: "S? x = new S?(default)" holds a value, while "S? x = default" is
null. Unwrapping the nullable constructor around a shortened literal
therefore turned "S? x = default(S)" into a null nullable. The literal is
spelled out again whenever unwrapping moves it to a type other than the one
it was shortened from.

Converting a using resource to the declared variable type is unconditional
now (except when the declaration says "var", which supplies no type): the
declaration always spells the type out, so any conversion to it may stay
implicit, which is also what shortens default(T) there.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

4 weeks ago

Christoph Wille

fe9f6db3ee

Emit C# 7.1 default literals where the context supplies the type

Shortening default(T) is the same problem as removing the redundant cast
around a lambda whose delegate type the context already fixes, so it uses
the same mechanism: ConvertTo makes the explicit type implicit when the
conversion is an identity conversion and the caller allows an implicit
one. The literal keeps the type it was shortened from, so any later
conversion to a different type - or any context that requires an explicit
type, such as an overload resolution recheck falling back to CastArguments
- can spell default(T) out again. That keeps the value intact where the
bare literal would change it, e.g. "object o = default(SomeStruct)", which
boxes a non-null struct while "default" would be null.

Because the shortened literal resolves to DefaultLiteralResolveResult,
CallBuilder's existing overload resolution recheck sees a real default
literal and rejects ambiguous calls on its own; no separate bookkeeping
about which arguments may stay untyped is needed. Only the contexts that
supply no target type at all restore the explicit form: an awaited
expression, and arguments of operator methods, which later become operator
or cast syntax rather than calls.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

4 weeks ago

2 Commits (fix/lambda-parameter-syntax)