On: Type inference has usability problems

[timw4mail]

So... the author would rather have

    // Old school
    String string = new String();

over

    // C++ style
    auto string = new String();

    // Rust style
    let string = String::new();

I don't see a single advantage to repeating the type, especially in the case where it's already apparent what the type will be.

[JulianMorrison → timw4mail]

The advantage is mostly when it's

    String s = doSomethingOpaque();

[ijpoijpoihpiuoh → JulianMorrison]

The supposed advantage. Many perfectly productive languages don't even offer the option to specify the type at all, and not just in the inference case. As far as I'm aware, nobody has ever convincingly demonstrated (with empirical data) that this is worse along any metric that people care about (development speed, bugs, cost, etc.).

A lot of people have preferences on this front. Somehow, these preferences get promoted to best practices if not moral license. Just, which approach is claimed to be better really depends on who you ask, and then mainly on whichever language that person first cut their teeth on. And nobody's going to be able to cite any well-designed study that demonstrates their preference is actually superior, because none exist.

[rwj → timw4mail]

I agree with your examples, but that code is pretty trivial. There is a point where inference can be over used, and that can cause readability issues. The OP ended with a call for empirical research.

[b_t_s → timw4mail]

You can get more strings in that line with obj-c ;P

NSString * string = [[NSString alloc] initWithString:@"myString"];

[UIZealot → timw4mail]

There's no need for type inference, nor repeating the type, especially if you're designing a new language anyway.

Why not:

  String string = new ();

[jcelerier → timw4mail]

nitpick: the C++ style is in most cases

    auto string = std::string{};

(old school being just

    std::string string;

)

[timw4mail → jcelerier]

True, but I was using String as an arbitrary example.