Representing the Impractical and Impossible with JDK 10 “var”

Post by [deleted] » Mon, Mar 05, 2018, 2:37 AM UTC

kochthesecond wrote: post #79

Amelorate wrote: post #50

Earlier quoted context omitted.

Counter-argument to changing the return type of a function with var: You can change the return type of the function to another type that might break some assumptions later in the code. For example, if the code assumes it has a type Foo with a length field, and you change the return type of tha function to a Bar without that length field, the compiler will complain that Bar doesn't have a length field, rather than com…

In your example, after you manually change the return type at the caller to Bar from Foo, the usage of Foo.length and Bar.length remains and nothing will help you if they changed semantics with neither inferred nor explicit types. The access of the length field is still valid in either case.

Post by trixie_ » Mon, Mar 05, 2018, 3:08 AM UTC

exabrial wrote: post #101

trixie_ wrote: post #98

Earlier quoted context omitted.

The type definition alone wouldn't tell you if it's an enum, ordered, or no duplicates allowed... The writer would know what type they're working with through intellisense. The reader would know it's iterable based on just reading the code that follows it.. So again, what does the type info give you? Most of what you mentioned you wouldn't be able to figure out from just a type name...

List tells me it's an ordered collection of a singular superclass that allows duplicate instances. var tells me nothing.

Post by exabrial » Mon, Mar 05, 2018, 3:49 AM UTC

trixie_ wrote: post #104

exabrial wrote: post #101

Earlier quoted context omitted.

List tells me it's an ordered collection of a singular superclass that allows duplicate instances. var tells me nothing.

'var transactions' is enough information for most people to understand it's a list of some sort. If it really matters to you then use the IDE. The full type info is just not that useful. That's why most languages are moving towards inferred typing - typescript, c#, java, c++, rust, go, scala, etc...

Post by zamalek » Mon, Mar 05, 2018, 4:36 AM UTC

jrochkind1 wrote: post #63

zamalek wrote: post #25

Earlier quoted context omitted.

> You or some other maintainer will need to know what that type is later when reading the code. The Microsoft rule is to only use var when the type is obvious from the assignment. That essentially boils down to new, cast and anonymous types.

That seems to go against the OP's example benefits of very complex types or actually impossible types. The former will not be obvious from the assignment by nature of their complexity, no? The latter... well, being impossible without `var` implicit types is probably often also not obvious.

Post by Zardoz84 » Mon, Mar 05, 2018, 6:47 AM UTC

earenndil wrote: post #105

saagarjha wrote: post #32

Earlier quoted context omitted.

let as a drop-in replacement for var, or something semantically different?

Generally in languages that have a let, it means const var.