Dynamic calls have priority over extensions

This commit is contained in:
Andrey Breslav
2014-11-14 19:07:08 +03:00
parent f58b30706e
commit 52f1e037c1
9 changed files with 99 additions and 43 deletions
+10
View File
@@ -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.