<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="">-1.<div class=""><br class=""></div><div class="">We already have a related feature for stored properties in structs and classes, and it causes a performance problem when compiling multi-file modules in non-WMO mode. Suppose you have:<div class=""><br class=""></div><div class="">— a.swift —</div><div class=""><br class=""></div><div class="">struct Box {</div><div class=""> var x = <some very complex expression here with lots of overloads and generics></div><div class="">}</div><div class=""><br class=""></div><div class="">— b.swift —</div><div class=""><br class=""></div><div class="">func takesABox(_: Box) {}</div><div class=""><br class=""></div><div class="">— c.swift —</div><div class=""><br class=""></div><div class="">func returnsABox() -> Box { return Box(x: …) }</div><div class=""><br class=""></div><div class="">When you run ‘swiftc a.swift b.swift c.swift’, we actually invoke the compiler three times:</div><div class=""><br class=""></div><div class="">swiftc -frontend -primary-file a.swift b.swift c.swift</div><div class=""><div class="">swiftc -frontend a.swift -primary-file b.swift c.swift</div></div>swiftc -frontend a.swift b.swift -primary-file c.swift<div class=""><div class=""><br class=""></div><div class="">In the first invocation, we’re emitting the declaration of ‘struct Box’ itself, so we have to type check its members, and infer the type of ‘x’. In the second invocation, we end up type checking takesABox(), which references the ‘Box’ type in its parameter list, so again we have to type check the members of ‘Box’ so that we know the ABI for ‘takesABox()’. And the third time, we’re type checking ‘returnsABox()’, which has ‘Box’ in its return type, so again, it has to be type checked so that we know its layout. This means the complex expression will be type checked a total of three times.</div><div class=""><br class=""></div><div class="">Now if you change a.swift to</div><div class=""><br class=""></div><div class="">struct Box {</div><div class=""> var x: Int = <some very complex expression></div><div class="">}</div><div class=""><br class=""></div><div class="">Then the expression only has to be type checked when compiling a.swift, so that we can emit the initializer for Box, but b.swift and c.swift immediately know the layout of Box without type checking the initializer (because the property type is declared explicitly).</div><div class=""><br class=""></div><div class="">If we allowed default argument types to be omitted, you would introduce the potential for similar compile time slowdowns. It would also create interesting circularity issues:</div><div class=""><br class=""></div><div class="">func foo(a = bar())</div><div class="">func bar(a = foo())</div><div class=""><br class=""></div><div class="">Here, you’d have recursion between the declaration checker and recursion checker when you go to type check either one of the two functions.</div><div class=""><br class=""></div><div class="">While neither of these challenges are insurmountable — we definitely plan on doing more to speed up the expression type checker, and circularity issues in declaration checking are also something we’ve been chipping away at in recent months — I would be against introducing any language features which make things worse in this regard.</div><div class=""><br class=""></div><div class="">Going back to the my original example here, Jordan Rose once suggested that stored properties inside types should always require a declared type — this might be too drastic for many people’s tastes, but I would definitely be in favor of that from an implementor's perspective ;-)</div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 10, 2017, at 1:40 PM, Kilian Koeltzsch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">I sent the message below to swift-users@ ~a day ago, but this might be a better place to ask and gather some discussion. It is a rather minor suggestion and I'm just looking for some opinions.</div><div class=""><br class=""></div><div class="">Declaring a function that has default parameters currently looks like this:</div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);">func</span><span class="" style="font-variant-ligatures: no-common-ligatures;"> foo(bar: </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(112, 61, 170);">String</span><span class="" style="font-variant-ligatures: no-common-ligatures;"> = </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(209, 47, 27);">"baz"</span><span class="" style="font-variant-ligatures: no-common-ligatures;">) {</span></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;"> </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(62, 30, 129);">print</span><span class="" style="font-variant-ligatures: no-common-ligatures;">(bar)</span></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;">}</span></div></div><div class=""><br class=""></div><div class="">Now I'm wondering if there would be any problems if it were possible to omit the type annotation for default params and let Swift's type inference handle that. </div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;"><span class="" style="color: rgb(186, 45, 162);">func</span> foo(bar = </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(209, 47, 27);">"baz"</span><span class="" style="font-variant-ligatures: no-common-ligatures;">) {</span></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;"> </span><span class="" style="font-variant-ligatures: no-common-ligatures; color: rgb(62, 30, 129);">print</span><span class="" style="font-variant-ligatures: no-common-ligatures;">(bar)</span></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;">}</span></div></div><div class=""><br class=""></div><div class="">It feels to be equivalent to omitting type annotations with variable declarations. Obviously more complex types would still require annotations being specified. Off the top of my head I can't think of any negative ramifications this might bring, be it in simple function/method declarations or protocol extensions and elsewhere. </div><div class="">Any further input or examples for situations where this might cause issues would be much appreciated :)</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Kilian</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>