<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 Apr 11, 2017, at 8:18 PM, Jakub Suder 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=""><div dir="ltr" class="">I'm honestly having trouble believing that this is being seriously proposed... I always saw type inference as one of the most important advantages of Swift over some older languages, the Swift ebook mentions many times how smart Swift is that it can infer types for you so that you don't have to type too much boilerplate. And here we're talking about removing this feature that was advertised from the beginning as Swift's strong point, in order to make the compilation faster? The compiler speeds will be improved, the syntax will stay with us.<div class=""><br class=""></div><div class="">Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: Bool = true". But that's my choice, not something I should be forced to do. It's something to put in style guides, not to enforce with the compiler.</div></div></div></blockquote><div><br class=""></div>To be clear, it's being "seriously proposed" in the sense that someone sent an email to a mailing list.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I agree with the sentiment of the proposal, it does add value to overall efficiency of swift and make things simpler for the swift team, but as Matthew said a blanket ban will add noise to the code. Also this particular feature is one of those niceties about swift which makes it very welcoming to new adopters.<div class=""><br class=""></div><div class="">If some middle ground can be proposed to this problem then I think we will be making a lot of people happy.<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Hi all,<br class="">
><br class="">
> In a discussion about inferring parameter types from default value, Slava brought up some performance problems caused by type inference for stored properties in side types:<br class="">
><br class="">
> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html" rel="noreferrer" target="_blank" class="">https://lists.swift.org/piperm<wbr class="">ail/swift-evolution/Week-of-<wbr class="">Mon-20170313/033882.html</a><br class="">
><br class="">
> Towards the end, the post mentioned that some Swift team members contemplated requiring types for stored properties in type declarations. I think this idea deserves some more attention. Hence this last minute idea-floating.<br class="">
><br class="">
> In addition to solving a performance headache in implementation, there're always the general benefit of making type declartion more explicit and readable (clarity for reader should out-weigh pleasure of the author). Making the<br class="">
> language slightly more consistent (we are not inferring types for default parameter values in function anyways).<br class="">
><br class="">
> The cons for doing this are obvious too: the inference makes the language feels more friendly and is, undoubtedly, a beloved feature for many. This would be a source breaking change.<br class="">
><br class="">
> Just thought I'd float the idea to gather some quick reaction. What do y'all think?<br class="">
<br class="">
</span>I’m willing to keep an open mind on this topic but I don’t think wholesale banning of inference is the right thing to do. Here is an example of a case where I do not want to give up inference. When a property is initialized inline by calling an initializer of a non-generic type (very common) any annotation is strictly redundant.<br class="">
<br class="">
struct {<br class="">
let foo = Foo()<br class="">
}<br class="">
<br class="">
Requiring a type annotation here feels very unnecessary and boilerplate-y. I adds no additional clarity to a reader of the code, only noise. Noise reduces clarity. Small amounts of unnecessary or redundant information such as in an individual stored property declaration are not that big a deal. But on balance they add up quickly and have an undesirable impact on the overall clarity of code.<br class="">
<div class="m_-8427465262460662441HOEnZb"><div class="m_-8427465262460662441h5"><br class="">
><br class="">
> Daniel Duan<br class="">
> ______________________________<wbr class="">_________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><span class="HOEnZb"><font color="#888888" class=""><br class="">
</font></span></div></div></blockquote></div><span class="HOEnZb"><font color="#888888" class=""><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="m_-8427465262460662441gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><font color="#999999" size="2" face="georgia, serif" class=""><i class="">Pranshu Goyal</i></font><div class=""><font color="#999999" size="2" face="times new roman, serif" class=""><i class="">iOS Developer</i></font></div><div class=""><font color="#999999" size="2" face="times new roman, serif" class=""><i class="">tlkn</i></font></div></div></div>
</font></span></div></div></div>
<br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></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=""></body></html>