Support definitely non-nullable types

[ZacSweers]

From https://kotlinlang.org/docs/whatsnew17.html#stable-definitely-non-nullable-types

Open to suggestions on the API for this, went back and forth on an explicit asDefinitelyNonNullable() or copy(isDefinitelyNonNullable: Boolean) overload. Also open to suggestions on whether or not any of the checks are cases we should silently "fix" for them, like setting isDefinitelyNonNullable to false if copying over as nullable.

[JakeWharton]

I think modeling this as an intersection type rather than some specialization of a type variable is a better and more future-proof path.

[JakeWharton]

Very surprising behavior

[ZacSweers]

That sounds reasonable to me. API like this maybe?

TypeVariableName(..., intersects = listOf(ANY))

The thing I'm less sure about though is how to indicate that this needs to be emitted.

[JakeWharton]

I was thinking more like IntersectionTypeName(TypeVariableName("T"), ANY)

[ZacSweers]

Hmmm, is that a breaking change if TypeName is currently sealed to add another?

[JakeWharton]

It's source incompatible and will cause a runtime exception for when's without an else.

[Egorand]

What if we made isDefinitelyNonNullable private and introduced IntersectionTypeName as a function that returns TypeVariableName with isDefinitelyNonNullable set to true? While IntersectionTypeName will support any type as the second argument, we can make it fail at runtime and say that only ANY is currently supported. When intersection types become more common in Kotlin we may be close enough to KotlinPoet 2.0, at which point we can promote IntersectionTypeName to an actual subtype of TypeName.

[ZacSweers]

I think that seems reasonable. In general for 2.0, I think we should take a closer look at how kotlinc models these and consider mirroring it, including making TypeName no longer sealed. There's a few things that don't quite fit the kotlin model that are leftovers from JavaPoet. I'll add them to the 2.0 ideas issue