5 ms·
How would you even be able to abuse inference? If someone leaves some types to be inferred and someone reading that code is confused, the compiler already knows
by Dewie 12y ago
How would you even be able to abuse inference? If someone leaves some types to be inferred and someone reading that code is confused, the compiler already knows the type of the function so it should be able to spit it out for him in something like a REPL or even to 'inline' it in the source code.
Maybe you mean that people should write some types as some kind of assertion in case the code changes (and it compiles again, coincidentally because the change produced valid but different types, somehow)? I guess the same could be said for always putting certain assertions in the code in order to make sure that assumptions are sound, for example putting "@Override" on all methods that are intended to be overrided methods in Java. And again, since types are inferred, I guess it is conceivable that it can be automated like a code-style thing as a hook, since the compiler knows the type.
- frou_dh 12y agoI guess inference can be used to mask some smelliness of deeply nested generics. It seems FUD-like to raise these types of concerns solely in the abstract, though.
- vijayaggarwal 12y agoHere's what I had in mind. Let's say class S is subclass of class C. Now, var myVariable = S() when changed to var myVariable = C() will not cause any compiler error in rest of the code. Still, it may be a logical requirement for myVariable to hold instances of type S only. Yes, the programmer can explicitly declare type if s/he wants to, but I guess apple APIs will promote the culture of using type inference. Though hopefully apple will set the best tone possible of swift coding style in their APIs.
- bunderbunder 12y agoI've known some developers who were uncomfortable with abstraction in general, and like to have everything be as explicit as possible. So when reading code along the lines of: var employee = employeeRepository.Get(12345); return employee.Name; they'll see the code as untrustworthy because without an explicit type name, you've got no idea what kind of thing 'employee' is. I suppose there's also the 'making excessive generics too easy' issue, though personally I'm not certain that excessive generics are necessarily so terrible. Oftentimes the alternative is to litter your codebase with a bunch of one-off classes that bloat the codebase without adding any value. I think I side with the camp that cites that practice as one of the things that used to really suck about working in Java.