+1<br><br>I like that python style shorthand.<br><div class="gmail_quote"><div dir="ltr">On Sat, Mar 11, 2017 at 6:36 AM Daniel Leping via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg">I'm always positive with shorthand declarations, though this is a good example of ambiguity pron case.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Signatures are signatures. Let's not mess with them.</div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Sat, 11 Mar 2017 at 11:19 Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_4531416781998788292m_-6406463334222542066Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">Hi all,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Declaring a function that has default parameters currently looks like this:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="gmail_msg">func</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> foo(bar: </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)" class="gmail_msg">String</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> = </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(209,47,27)" class="gmail_msg">"baz"</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">) {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(62,30,129)" class="gmail_msg">print</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">(bar)</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">}</span></div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"><span style="color:rgb(186,45,162)" class="gmail_msg">func</span> foo(bar = </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(209,47,27)" class="gmail_msg">"baz"</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">) {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg"> </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(62,30,129)" class="gmail_msg">print</span><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">(bar)</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class="gmail_msg"><span style="font-variant-ligatures:no-common-ligatures" class="gmail_msg">}</span></div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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="gmail_msg">Any further input or examples for situations where this might cause issues would be much appreciated :)</div></div></div></blockquote><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">I like the idea but I'm afraid I don't think I can support it.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think it is more important for function/method declarations to have as explicit a signature as possible; I mean, I'm not even that comfortable with the ability to omit -> Void on non-returning functions (I always include it just to be consistent).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As others point out, while this makes sense for types where there's only one obvious choice to infer, it's not quite so clear on things like ints where a function really needs to be absolutely clear on what type/width of int it expects, since it's not something you want to have to change in future.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">One alternative I thought of was an operator for this purpose, e.g- := (chosen since the colon kind of suits the omitted type declaration); this would allow a developer to be explicit about wanting Swift to infer the type, but it would be inconsistent with regular variables where it's always inferred, so I'm not sure if it'd be a good option anyway.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Sorry, I do agree that it feels inconsistent that a function default doesn't behave more like a variable's initialisation, but at the same time they <b class="gmail_msg">are</b> two slightly different concepts so that's not necessarily a bad thing.</div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>