0

In the case of kotlin, rust and many other programming languages...

There are variables with direct implicit type declarations... Where you can see the type of a variable at the same line where it's defined and initialized.

val a = 1

if you change this code to this...

val a = 1.5f

the change can be easily addressed down the function where this variable is used...

Now if we look at this code...

fun f(): <first type> {
    return ...
}

val d = f()
val e = f2()

and if you change return type of function to this...

fun f(): <other type compatible with first type> {
    return ...
}

val d = f()   <--- Still compiles but the change is not being addressed by the programmer.
val e = f2()

All variables that store return type from the function and are defined with indirect implicit type declaration will not be addressed by the programmer and this will result in a vulnerable, fragile, or even dangerous codebase over time...

My question is similar to:

But my problem is about the indirect implicit variable declarations where you store the return type of a function to a variable with an implicit declaration which I think is dangerous and the compiler should not allow this kind of implicit declaration.

What are you guys thinking? Should be this problem addressed on the compiler level or I'm overreacting?

1 Answers1

1

“Second level” isn’t really a thing. d and e are type Any in your examples. This becomes apparent when f becomes polymorphic or its implementation is in a dll. If the compiler can’t see the implementation, it can’t infer the return type.

But when the compiler can see the implementation (function bodies, generally) it can do all sorts of good inference across many different operations, including stuff like “this is an int or a string” or “this is something with a .Name”.

Telastyn
  • 110,259