Reword callable reference and class literal resolution algorithm, explain some corner cases (#5) #43
Conversation
Reword the whole algorithm, to (hopefully) improve readability
| fun test() { | ||
| C::class // class of C | ||
| C()::class // class of C | ||
| (C)::foo // class of C.Companion |
There was a problem hiding this comment.
shouldn't this be ::class?
| 2. Resolve the unbound reference with the existing algorithm. | ||
| 1. Type-check the LHS as an **expression**. | ||
| - If the result represents a _companion object of some class_ specified with the short syntax (via the short/qualified name of the containing class), discard the result and continue to p.2. | ||
| - If the result represents an _object_ (either non-companion, or companion specified with the full syntax: `org.foo.Bar.Companion` or just `Bar.Companion`), remember the result and continue to p.2. |
There was a problem hiding this comment.
No, (Bar) is covered by the first clause because it's a companion object of some class specified with the short syntax
There was a problem hiding this comment.
What about object Foo (Foo)?
There was a problem hiding this comment.
I'm not sure what do you propose, could you elaborate? The two examples here explain what does "companion specified with the full syntax" mean, they do not relate to non-companion objects. I don't think usage of a non-companion object needs any explanation. Or are you talking about the (Foo)::class case?
UPD: discussed in person
|
No other comments from me |
| @@ -162,12 +162,24 @@ fun test() { | |||
| } | |||
| ``` | |||
|
|
|||
| Once the LHS is type-checked and its type is determined to be `T`, the type of the whole class literal expression is `kotlin.reflect.KClass<T'>` where `T'` is a type obtained by _substituting `T`'s arguments with star projections (`*`)_. Example: | |||
| Once the LHS is type-checked and its type is determined to be `T`, the type of the whole class literal expression is `KClass<erase(T)>`, where `erase(T)` represents the most accurate possible type-safe representation of the type `T` and is obtained by substituting `T`'s arguments with star projections (`*`), except when the type is an array. | |||
There was a problem hiding this comment.
Type-arguments of arrays are not fully known at runtime either: their nullability is unclear. Does it matter in this context?
There was a problem hiding this comment.
It does matter, and we may revisit it in the future, but type-checking arrayOfStrings::class to KClass<Array<*>> would be rather unhelpful from Java user's point of view. We've briefly discussed this with @erokhins and decided (for now) to type-check arrayOfStrings::class to KClass<Array<String>>. We should discuss this in detail later anyway.
There was a problem hiding this comment.
Note in JS we don't know anything about type-arguments of arrays at runtime.
|
Added a TODO about JS, we'll have to discuss later. I'm merging this set of changes now, thanks to everyone for review! |
No description provided.