Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Local Type Inference vs Instance

I've tried to scan JEP-286 about local type inference. I see that this works only for local variables - understood. So this does work indeed:

public class TestClass {
    public static void main(String [] args){
        var list = new ArrayList<>();
        list.add("1");
        System.out.println(list.get(0)); // 1
    }  
}

I do see that this on the other hand does not compile:

public class TestClass {
    public var list = new ArrayList<>();
    public static void main(String [] args){

    }
}

It's obvious that it does not, since the JEP says so. Now my question:

It makes perfect sense for a public/protected member declared as var to fail, at least IMO. But why does it not compile even if it's private? I can only assume that you can still get a hold of that variable via reflection (and I can't get local fields like this)... And getting that variable would require a cast, well, a very confused cast probably.

like image 259
Eugene Avatar asked Mar 02 '18 13:03

Eugene


People also ask

What is local type inference?

Type inference occurs when a local variable is declared without an As clause and initialized. The compiler uses the type of the assigned initial value as the type of the variable. For example, each of the following lines of code declares a variable of type String . VB Copy. ' Using explicit typing.

What is the difference between type checking and type inference?

A Type Checker only verifies that the given declarations are consistent with their use. Examples: type checkers for Pascal, C. A Type Inference system generates consistent type declarations from information implicit in the program.

What is type inference in IOS?

Type inference enables a compiler to deduce the type of a particular expression automatically when it compiles your code, simply by examining the values you provide. Because of type inference, Swift requires far fewer type declarations than languages such as C or Objective-C.


1 Answers

The motivation for forbidding type inference for fields and method returns is that APIs should be stable; field access and method invocation are linked by descriptor at runtime, so things that cause subtle changes to inferred types could cause existing compiled clients to break in terrible ways if a change to the implementation caused the inferred type to change (modulo erasure.) So using this for implementation, but not for API, is a sensible guiding principle.

It is reasonable to ask "so, what about private fields and methods?" And indeed, we could well have chosen to do that. Like all design decisions, this is a tradeoff; it would enable inference to be used in more places, in exchange for more complexity in the user model. (I don't care as much about complexity in the spec or the compiler; that's our problem.) It is easier to reason about "inference for local variables yes, fields and methods no" than adding various epicyclic considerations like "but, fields and methods are OK if they are private". Drawing the line where we did also means that the compatibility consequences of changing a field or method from private to nonprivate doesn't have accidental interactions with inference.

So the short answer is, doing it this way makes the language simpler, without making the feature dramatically less useful.

like image 193
Brian Goetz Avatar answered Nov 22 '22 05:11

Brian Goetz