Signature method considerations


I’d love to have the possibility to type

val i: Int = get()


fun get(): Int = 0
fun get(): Float = 0f

Question that arises: what to do when you simply call get()?

Simple, similar as today when you try to call the same when you would have

fun get(i: Int = 0): Int = 0
fun get(f: Float = 0f): Float = 0f

It’s forbidden because of ambiguity

We could replicate what Swift already does

func some() -> Bool {
    return true;

func some() -> Int {
    return 1;

let valBool: Bool = some()
let valInt: Int = some()

some() // this doesn't work: Ambiguous use of 'some'

I don’t think that a feature such as that is very useful. Did you consider generics? Maybe it is enough?


I believe this is a limitation of the JVM–Maybe using something like the @JvmName annotation would allow this to compile for the JVM. See:


We are working on a wrapper for opengl (here) and we have tons of methods that return different types.

The file I linked is still incomplete, there are many inline classes to add…

How would you implement generics?

According to @gildor:

JVM includes return type to method signature, but because Java doesn’t, It wouldn’t be possible to support in Kotlin because of interop

It’s just a design decision (for the moment hopefully)

1 Like

The limitation could a compiler manage. Important is which names the method finally have in the byte code.


Sorry, you are right. With generics you can not achieve it. I thought something like that…

fun <T> some(): T { ... }

val r = some<Int>();
val r2 = some<Boolean>();

OpenGL is normally a C library and there are no equal function names, btw. C prohibits it. In which function are you thinking for example?


All of these ones


Yeah… I never liked the OpenGL API since 3.0 and higher…

So I see what you mean. As I saw for short, you are designing higher level functions, not just exposing the C functions?

inline fun <reified T> getTexLevelParameter(target: TextureTarget, level: Int, name: TexLevelParameter): T

As I said, there are different functions but you want them unite into one function name. So you did it with generics?
On other side… there is the red book(?) which is teaching OpenGL with these C functions. How does your implementation fits in? Sorry I didn’t read your code, just some snippets… :slight_smile:


Uh, why that? Things got pretty nice especially with the Direct State Access

Yeah, exactly.

Yeah, at the moment the only way I could find was to use inline reified methods.

This is basically a wrapper to reduce boiler plate code and make it less error prone as possible with inline enums, inferring automatically mandatory parameters, object-oriented design, etc etc

The logic behind remains always the same as you’d write vanilla opengl though :slight_smile:


Uh, why that? Things got pretty nice especially with the Direct State Access

The control is of course nice, and it makes everything faster. But the design of these functions is not very pretty. For example all these query functions have a strange semantic.
I tried Vulkan and I rewrote the tutorial example in C++. The query functions in Vulkan seem very clean. The semantics are all over similar. Well I don’t like the C Style functions and I wrapped them in C++ functions.

Back to kotlin… I think, you cannot implement it better. Or you put an additional parameter. But that’s not really better.

object AsInt
object AsBool
fun f(p:AsInt):Int=0
fun f(p:AsBool):Boolean=false
fun foos() {
  Assert.assertEquals( 0, f(AsInt) )
  Assert.assertEquals( false, f(AsBool) )

I don’t know OpenGL, but reading this thread I have a few suggestions:
Instead of creating separate objects like asInt etc. just create an enum with these values and make function an extension of this enum.
Then instead of f(asInt) you can call asInt.f() or even Int.class.f() without defining enum.

Also in this case you don’t need to do “when”, but just implement type-specific function.