Dynamic calls have priority over extensions
This commit is contained in:
@@ -61,6 +61,16 @@ Internally, `dynamic` is represented as a flexible type `Nothing..Any?`, with th
|
||||
|
||||
`Nothing` being mentioned, there's a risk of taking `dynamic` for a bottom type in some contexts, this is not intended and should be tested carefully.
|
||||
|
||||
## Resolution rules
|
||||
|
||||
- If a receiver is `dynamic` a call is resolved as dynamic if no members match the signature (these are members of `Any`, unless we implement bounded `dynamic`)
|
||||
- Motivation: otherwise, **any** extension to **any** type that simply happens to be in scope and match the name and arguments
|
||||
will be bound for a call with a `dynamic` receiver, i.e. there's no way to force a call to be dynamic, and in the case of a `*`-import
|
||||
the code may change its semantics just because somebody added some extension in another file.
|
||||
- This means that an extension **can not** be called on a `dynamic` receiver. If needed, one can force a call to an extension by casting
|
||||
teh receiver to a static type: `(d as Foo).bar()`
|
||||
- This also means that an extension whose receiver type is `dynamic` can not be called on a `dynamic` variable without a cast
|
||||
|
||||
## Type Argument Inference
|
||||
|
||||
When expected type of a call is `dynamic`, it does not automatically provide type arguments for nested calls.
|
||||
|
||||
Reference in New Issue
Block a user