> On May 11, 2016, at 08:19, Haravikk via swift-evolution > <[email protected]> wrote: > > It might be different if for example we could omit type when it can inferred > by other means as well, for example: > > protocol FooType { > func someMethod(value:String) -> Void > } > > struct Foo : FooType { > func someMethod(value) -> Void { … } // value is a String > } > > But I’m not sure if I’d want to do that or not. Generally I like things that > shorten function signatures, but on its own I’d prefer consistency over > inference in this case I think.
Without commenting on the rest of it, there’s a difference to me between something that can be inferred based on local information and something that I have to look elsewhere to figure out. In the protocol case, I’d have to notice that this method satisfies a protocol requirement and know enough about the protocol to know what the type of the parameter is. In the default argument case, I only have to know about the type of the expression, which is very often a literal. (And even when it’s not, we generally assume the return type of most functions is inferrable from the name and arguments, or we’d be requiring types for locals too.) (By the way, that’s also the history of inference for properties and globals: we knew we wanted it for locals and implemented it, and then it was immediately a little weird to have to write types elsewhere.) Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
