Explicit typing isn’t the problem, no? From my perspective, the problem is incorrect typing, not typing per se. My proposal is that one should use explicit Any’s, which doesn’t seem to suffer from the issues you’re raising. As far as I can see, our disagreement would just be between using implicit Any and explicit Any. In the end, I’m not that committed to explicit Any, but I can’t see what harm it does.
— John On Dec 31, 2013, at 12:24 PM, Steven G. Johnson <[email protected]> wrote: > > > On Tuesday, December 31, 2013 11:12:44 AM UTC-5, Daniel Carrera wrote: > (18)+(19): I disagree. Although I could favour rules like this in a > particular project, in many cases I think that adding type annotations just > creates syntactic noise and can create a needless limitation > > I also strongly disagree with the "Always explicitly type all arguments to a > function" rule. Adding an explicit type imposes a severe cost in generality > in many cases, since it prevents duck typing. (And duck typing is extremely > important in Julia because of the lack of multiple inheritance.) > > For example, the whole "iterator" pattern in Julia relies on *not* declaring > types. This also came up in the IterativeSolvers.jl package, where > explicitly declaring arguments as AbstractArrays prevented one from using > other linear-operator objects (supporting "op * vector") that lack array-like > random access semantics. > > As I've argued elsewhere > (https://groups.google.com/d/msg/julia-users/WOsN9zTOQbg/RgJMnWdx0IoJ), the > main reasons to declare an explicit type in Julia are either to disambiguate > method dispatch or to prevent unexpected results (not MethodError exceptions). > > In any given case, you should have a clear reason for why you are declaring a > type rather than leaving an argument untyped (and you should especially have > a reason for using a concrete rather than an abstract type). > > > > >
