I see... Still. Is there a case where `emptyList&l...
# compiler
I see... Still. Is there a case where
would behave differently than
The reasoning was about it being an empty list so doing
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
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:
Copy code
val valueList: List<Value> = value.children
if (valueList.isNotEmpty())
It’s probably undesirable for an implementation detail (use of
) to have an implicit effect on API signature, no?
I think I wouldn't mind too much if the compiler defaulted to
and I could always be more explicit if I really wanted a
for this specific case. But maybe that has far reaching implications so I'm ok to having to explicit the signature all the time