<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 May 2016, at 14:59, Vladimir.S <<a href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>> wrote:</div><div class=""><br class="">On 11.05.2016 16:03, Haravikk wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On 11 May 2016, at 13:49, Vladimir.S via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class=""><br class="">public var a = 10 // OK, all is clear here<br class="">public var a = "sdfsdf" // OK<br class="">public var a = someFunction() // not OK - add type of `a` explicitly<br class=""></blockquote><br class="">I’m not clear on why you think the third one isn’t okay; Xcode can tell you<br class="">what the type was inferred to be, you can check the function signature (alt<br class="">- click the name) which will tell the type that it returns, as well as call<br class="">up any documentation about what it does.<br class=""></blockquote><br class="">Well.. First of all Swift != XCode, and the OSX is not the only system where Swift is used ;-)</div></blockquote><br class=""></div><div>I don’t disagree, but nor is Xcode unique in helping to figure out what a type is; I think it’s okay to consider that any good modern IDE should be able to tell us what a type is if the compiler can. Besides, in the example, someFunction() could be buried somewhere hard to find, sure, or it could also be declared clearly earlier in the same file, or in a commonly used file for that module, in which case it’s probably very well known. I think it’s fine to infer the type in these cases because forcing the developer to supply it may not add anything, and in cases where it does it’s easy enough to just do this yourself; even if you’re maintaining unfamiliar code, it shouldn’t take long to look up the type and add it for others if you really feel you have to, but again, any good IDE should render it a non-issue.</div><div><br class=""></div><div><br class=""></div><div>As to the original issue (realised I hadn’t commented on it yet), I’m undecided; I like type inference for declarations as inference is very common for these, and I myself usually only supply a type if there’s ambiguity or I want something to become optional. My main concern is that default parameter values are relatively rare (compared to those without them), so it becomes an issue of consistency for me.</div><div>It might be different if for example we could omit type when it can inferred by other means as well, for example:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol FooType {</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someMethod(value:String) -> Void</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div><font face="Monaco" class=""><br class=""></font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Foo : FooType {</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someMethod(value) -> Void { … } // value is a String</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div><br class=""></div><div>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.</div></body></html>