For Java, I used to write `list = yourFunctionReturningThatSet();` and then have the IDE fill in the type when it complains about the undefined variable.

Also on a function?

  var getDate() { return „no date“; }

That is often considered undesirable because it makes code less clear and compilation errors inscrutable.

For instance the rust developers consciously decided to remove that from the language, named functions must be fully typed.

Easter egg: you can use -> _ to ask the compiler what type it thinks the return type should be, given your body. Because it is only used for diagnostics it isn't fully featured and there are things it doesn't cope well with, but it is there and works most of the time.

Static type inference is "fully typed".

  def getDate = "no date"

That defines a method `getDate` with the type `() => String` in Scala.

The type is statically know, of course.

But it's recommended to use explicit return types for public methods. This helps preventing breaking public API by refactoring the implementation of a method.

No, but I think that was a good choice. In local code this is great, but in an interface contract being explicit about data type is a virtue.

For interfaces this would obviously not work (there is no implementation). But for class members it would.

I think this concept works very well in typescript and F#.

I mean interface not as a language construct, but as a declaration of how module (class, component etc) can be used. You want to see the type in such declaration, not to infer it based on implementation details.

But rust still allows declaring returning a trait instead of explicit types.