71 lines
3.9 KiB
Markdown
71 lines
3.9 KiB
Markdown
# improved common type
|
|
|
|
* [x] Proposed
|
|
* [ ] Prototype: None
|
|
* [ ] Implementation: None
|
|
* [ ] Specification: See below
|
|
|
|
## Summary
|
|
[summary]: #summary
|
|
|
|
There is a situation in which the current common-type algorithm results are counter-intuitive, and results in the programmer adding what feels like a redundant cast to the code. With this change, an expression such as `condition ? 1 : null` would result in a value of type `int?`.
|
|
|
|
## Motivation
|
|
[motivation]: #motivation
|
|
|
|
This is a common cause of what feels to the programmer like needless boilerplate code.
|
|
|
|
## Detailed design
|
|
[design]: #detailed-design
|
|
|
|
We modify the specification for [finding the best common type of a set of expressions](https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#finding-the-best-common-type-of-a-set-of-expressions) to affect the following situation:
|
|
|
|
- If one expression is of a non-nullable value type `T` and the other is a null literal, the result is of type `T?`.
|
|
|
|
This is expected to affect the following aspects of the language:
|
|
|
|
- the [ternary expression](https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#conditional-operator)
|
|
- implicitly types [array creation expression](https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#array-creation-expressions)
|
|
- inferring the [return type of a lambda](https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#inferred-return-type) for type inference
|
|
|
|
More precisely, we change the following sections of the specification (insertions in bold, deletions in strikethrough):
|
|
|
|
> #### Output type inferences
|
|
>
|
|
> An *output type inference* is made *from* an expression `E` *to* a type `T` in the following way:
|
|
>
|
|
> * If `E` is an anonymous function with inferred return type `U` ([Inferred return type](expressions.md#inferred-return-type)) and `T` is a delegate type or expression tree type with return type `Tb`, then a *lower-bound inference* ([Lower-bound inferences](expressions.md#lower-bound-inferences)) is made *from* `U` *to* `Tb`.
|
|
> * Otherwise, if `E` is a method group and `T` is a delegate type or expression tree type with parameter types `T1...Tk` and return type `Tb`, and overload resolution of `E` with the types `T1...Tk` yields a single method with return type `U`, then a *lower-bound inference* is made *from* `U` *to* `Tb`.
|
|
> * Otherwise, if `E` is an expression with type `U`, then a *lower-bound inference* is made *from* `U` *to* `T`.
|
|
> * **Otherwise, if `E` is a constant expression with value `null`, then a *null bound* is added to `T`**
|
|
> * Otherwise, no inferences are made.
|
|
|
|
> #### Fixing
|
|
>
|
|
> An *unfixed* type variable `Xi` with a set of bounds is *fixed* as follows:
|
|
>
|
|
> * The set of *candidate types* `Uj` starts out as the set of all types in the set of bounds for `Xi`.
|
|
> * We then examine each bound for `Xi` in turn: For each exact bound `U` of `Xi` all types `Uj` which are not identical to `U` are removed from the candidate set. For each lower bound `U` of `Xi` all types `Uj` to which there is *not* an implicit conversion from `U` are removed from the candidate set. For each upper bound `U` of `Xi` all types `Uj` from which there is *not* an implicit conversion to `U` are removed from the candidate set.
|
|
> * If among the remaining candidate types `Uj` there is a unique type `V` from which there is an implicit conversion to all the other candidate types, then ~~`Xi` is fixed to `V`.~~
|
|
> - **If `V` is a value type and there is a *null bound* for `Xi`, then `Xi` is fixed to `V?`**
|
|
> - **Otherwise `Xi` is fixed to `V`**
|
|
> * Otherwise, type inference fails.
|
|
|
|
## Drawbacks
|
|
[drawbacks]: #drawbacks
|
|
|
|
There may be some incompatibilities introduced by this proposal.
|
|
|
|
## Alternatives
|
|
[alternatives]: #alternatives
|
|
|
|
None.
|
|
|
|
## Unresolved questions
|
|
[unresolved]: #unresolved-questions
|
|
|
|
- [ ] What is the severity of incompatibility introduced by this proposal, and how can it be moderated?
|
|
|
|
## Design meetings
|
|
|
|
None.
|