```val evenCount = listOf(1, 2, 3).sumOf { if (it % 2 == 0) 1 else 0 }``` says `sumOf` is ambiguous ...

# compiler

[Alexander Maryanovsky]

val evenCount = listOf(1, 2, 3).sumOf { if (it % 2 == 0) 1 else 0 }

says sumOf is ambiguous (can’t decide between a version that returns Int and one that returns Long), but this compiles fine:

val evenCount = listOf(1, 2, 3).sumOf { 0 + if (it % 2 == 0) 1 else 0 }

[ephemient]

https://youtrack.jetbrains.com/issue/KT-46360/Type-inference-fails-to-infer-type-for-sumOf-call-with-constant-Overload-resolution-ambiguity-TypeVariableT-Int-Long

[ephemient]

I was hoping they resolve this before stabilizing BuilderInference but I'm not sure what actual plans are

[Alexander Maryanovsky]

Given how Kotlin requires explicit conversion from Float to Double, I’m surprised it’s more flexible about doing it automatically from Int to Long.

[ephemient]

it's not a cast, it's that numeric literals like 1 are not Int or Long, but a sort of magical union type that can be treated as either Int or `Long`: https://kotlinlang.org/spec/kotlin-spec.html#the-types-for-integer-literals

[Alexander Maryanovsky]

I see

[Alexander Maryanovsky]

Still, the end result is somewhat counter-intuitive. You can do

val n: Long  = 5

but not

val d: Double = 4f

[ephemient]

it only applies to integer literals, as per spec

[ephemient]

I do think it's kind problematic in ways like this, but I can see why they would have wanted byteArrayOf(1, 2, 3) to work without having to add an explicit .toByte() on each literal (as there's no character suffix for byte/short)

[Fleshgrinder]

Consistent suffixes would be the best solution.

[ephemient]

yeah, the existing literals are like Java, which has the same (1 is byte|short|int|long to match context) but with more type inference Kotlin has more challenges

[ephemient]

explicit suffixes would be nice but what would they be? B overlaps with hexadecimal. Rust-like i8/i16/etc. maybe… 🤔

[Fleshgrinder]

Obviously I’d love to switch to the Rust naming. 😉