TypeName needs isNullable

[square]

TypeName needs isNullable

[swankjesse]

And either we want a box, like NullableTypeName that holds a non-nullable type, or to put the modifier on the type directly. We put annotations directly on TypeName and that’s worked well.

[rharter]

Upon investigation, I think TypeName is the wrong place for this.

In Java, java.lang.reflect.Class extends from java.lang.reflect.Type, but that's not the same for Kotlin.

This is evident in the fact that TypeName represents things like classes, interfaces, etc., which can't be nullable. Nullability applies to things like properties, parameters, and return types (KCallable, with the nullability identified by the KType.isMarkedNullable field on the returnType property).

As a result, I see two options:

1. Adjust the model in KotlinPoet to better reflect the model in Kotlin.
2. Add the nullability checks to callable types (properties, params, functions, etc.)

The first option is a bit of a major overhaul, the second means possible code duplication.

[JakeWharton]

This is evident in the fact that TypeName represents things like classes, interfaces, etc., which can't be nullable.

It represents a reference to those components but not those components themselves. And since the reference can be nullable, it makes sense to model that as part of the type.

Kotlin models it on KType as you said, and TypeName is our version of the data modeled by it.

[swankjesse]

TypeName is intended to be “something that could be a return type, a parameter type, or a property type”.

[swankjesse]

Fix merged!
#70