hm, not sure if it's a bug or not, but I don't get a primary constructor if I don't explicitly define one. Imo it would be easier if it returned a no-arg constructor in that case. Don't think there's any value in differentiating between the two right?
Copy code
class Foo --> primaryConstructor is null
class Bar() -> primaryConstructor is not null
t
Ting-Yuan Huang
06/11/2020, 1:07 AM
Currently KSP models this directly after the grammar structure. Adding a dummy constructor should be possible. On the other hand, people may sometimes want to tell the difference?
e
evant
06/11/2020, 1:33 PM
Guess it depends on how much sugar you see here with omitting the constructor explicitly. Might be biased but the java annotation processor api does include it. Imo seems pretty similar to https://github.com/android/kotlin/issues/19
evant
06/11/2020, 10:57 PM
and another one: properties in interfaces are implicitly abstract, but
modifiers
doesn't include abstract.
evant
06/11/2020, 11:13 PM
Actually now that I've thought about it more, I think modeling directly after the grammar structure is the wrong way to go. This forces processors to build in their own logic to match the semantics of kotlin language. For example, if I want to work on public methods, I want all methods that are public, not methods that literally have the public modifier defined. Telling the difference actually sounds dangerous here since it means semantically identical programs could behave differently under the presence of a processor which seems like a very bad idea to me.