I see... Still. Is there a case where `emptyList&l...

# compiler

[mbonnin]

I see... Still. Is there a case where emptyList<Value> would behave differently than emptyList<Node> ?

[mbonnin]

The reasoning was about it being an empty list so doing valueList[0] isn't valid. You could also think of concatening lists but even there, for concatening an empty list, the type argument isn't really important.

I guess what I'm leaning towards is some kind of special handling of empty list values by the compiler. It feels like there could be some help/special features there but that might as well be a rabbit hole of complexifying what is a good type system

[Drew Hamilton]

Ah OK, I see what you mean. But the type still affects what consumers of this API can do with/without casting – to adjust my example:

val valueList: List<Value> = value.children
if (valueList.isNotEmpty())
    valueList[0].name

It’s probably undesirable for an implementation detail (use of emptyList) to have an implicit effect on API signature, no?

[mbonnin]

I think I wouldn't mind too much if the compiler defaulted to List<Node> and I could always be more explicit if I really wanted a List<Value> for this specific case. But maybe that has far reaching implications so I'm ok to having to explicit the signature all the time