Error: type mismatch: inferred type is Int but Short was expected


#1

Hello,

I’m new to Kotlin so please excuse my newbie question(s).

I’m implementing the following class (my first Kotlin class !!!)

class Laptimer() {
    var lap: Short = 0.toShort()

    fun newLap() {
        this.lap = this.lap + 1.toShort()
    }
}

fun main(args: Array<String>) {
    val laptimer = Laptimer()
    laptimer.newLap()
    // laptimer.lap = 1000  // shouldn't be allowed
    println("Lap: ${laptimer.lap}")
}

I’m facing some problems.

I want lap to be stored as unsigned int 16 bits but I’m not really sure that unsigned int types can be used with Kotlin.

Even if I use (signed) Short I get the following error

error: type mismatch: inferred type is Int but Short was expected

This is odd because I thought that I was casting correctly using

    this.lap = this.lap + 1.toShort()

A last question is that I want lap getter be public and lap setter be private… and I’m currently stuck up (I really need to read a full book about Kotlin)

Any help will be great.

Kind regards

PS : which book do you suggest as a first Kotlin book for people with C, C++, C#, Python, Java, PHP background?


#2

Strange. It looks like that doing any math operation on 2 shorts generates an integer. After looking into this I think I can explain why.
The JVM does not support any short types (not really). Internally all numbers are at least integers. There is a conversion from int to short(i2s) but it looks like this has nothing to do with the type but it just cuts off the unneeded bits. The short still needs the same amount of memory as an int does.
Correction below

Here is an explanation from Roman Elizarov about it.

In general you should probably just use Int instead of Short, because you don’t gain anything by using Shorts. They just make your code more inconvenient.


The private setter is easy on the other hand

var lap: Int = 0
    private set

I personally don’t know any Kotlin books, but you can take a look at a list of books here.
You say you already have a programming background you might also want to take a look at the kotlin tutorials here. They might be a faster way to get an overview of all features.


#3

I want lap to be stored as unsigned int 16 bits but I’m not really sure that unsigned int types can be used with Kotlin.

Short is signed, you can consider the experimental UShort.

@Wasabi375 found the point, and it is evident here: http://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-short/plus.html

The short still needs the same amount of memory as an int does.

This is false, the JVM bytecode does not support operation on Short, this does not implies any behaviour on JIT compiler nor force any extra memory allocation.
You can conveniently use Short or UShort as needed.

which book do you suggest as a first Kotlin book for people with C, C++, C#, Python, Java, PHP background?

Having this background I strongly suggest you to read the Kotlin reference at least once, you can find it online http://kotlinlang.org/docs/reference/ and there is a printable PDF
Kotlin tutorial is a good second step.


#4

Woops, your right. I misinterpreted the fact that there are no operations (bytecode JVM) for shorts that they are treated the same on a memory level.
That being said all low level operations (+, -, *, /) don’t operate on shorts but rather on shorts which are cast to integers. So even if we had an operation on shorts returning shorts, the bytecode would still be doing something like this:

val short = (short + short).toShort()

I think this is the reason why the kotlin team decided to have it return Int.


I think the reason I got confused (about the memory) is that I can’t find any sload, sstore instructions for the JVM. It seems that local variables only support integers, but this is not the case when storing data in objects, where apparently it’s also possible to store Shorts and save memory.


I still think however that using Int and UInt is better in most cases. Int is easier to use in Kotlin and using Short or Byte is an optimization that won’t change much except in very special and rare cases.


#5

Like for example when you are working with ByteArray instead of IntArray, it can make a difference.