<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="">I am 110% AGAINST this change. Having complex expressions as a stored property initializer is bad practice anyway, and having the type prefixed in that case provides at best marginal improvement in clarity and doesn’t fix the underlying problem. <div class=""><br class=""><div class="">Type inference on simple expressions allows you to put the emphasis on the value, rather than the type—e.g. `let defaultTimeout = 5 as TimeInterval` is way easier to read and understand than `let defaultTimeout: TimeInterval = 5`; and it only gets worse if you declare something with a long class name—`let fooBarBazzerciser: MyReallyReallyLongType = MyReallyReallyLongType(argumentOne: 1, argumentTwo: 2)`—you might even have to scroll horizontally just to see what the arguments are! Clarity lost, none gained.</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 9, 2017, at 3:04 PM, T.J. Usiyan 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 would be alright with this change. The slight inconvenience, even in teaching, would be worth it, in my opinion. It is easier for developers to reason about the types intended when they are made explicit.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Apr 9, 2017 at 6:01 PM, Jon Shier 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 style="word-wrap:break-word" class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>I generally dislike any language change desired because it makes the compiler implementation easier. We saw a few such changes for Swift 3 and all of them were net negatives for the actual users of the language (to a minor extent for most, to be fair). I would hope that, as the compiler matures, these types of inference performance issues will become less of a problem. Removing a rather nice language feature, especially one that plays such a big role in the “feel” of the language, for short term gain seems rather shortsighted to me.<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon Shier<div class=""><div class="h5"><br class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 9, 2017, at 11:23 AM, Lucas Neiva via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_8962071201875937301Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""></div><div class="">If inference only works in simple cases, I think it would seem like it works unpredictability to anyone unfamiliar with the implementation details.</div><div class=""><br class=""></div><div class="">I image the question of "why do I have to declare a type here, but not in this case?" coming up.</div><div class=""><br class=""></div><div class="">Declaring types is one of the first things you have to learn anyway. Just declaring a function already requires some understanding of types. Properties are not much different IMO.</div><div class=""><br class="">On 8 Apr 2017, at 08:34, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_8962071201875937301Apple-interchange-newline"><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" 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.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></blockquote></div><div class=""><br class=""></div><div class="">Beyond just being more friendly, I think it could be considered a teaching issue. A great way to introduce beginners to custom types would be something like:</div><div class=""><br class=""></div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>struct Point {</div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>var x = 0.0</div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>var y = 0.0</div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div class=""><br class=""></div><div class="">Or:</div><div class=""><br class=""></div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>struct Person {</div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>var name = ""</div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>var age = 18</div><div class=""><span class="m_8962071201875937301Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div class=""><br class=""></div><div class="">If you have to explicitly specify types for the properties, that's another thing you need to introduce to people before you can do this.</div><div class=""><br class=""></div><div class="">On the other hand, a very limited form of inference might be fine here. Imagine if we did a sort of limited, single-pass, top-down inference which only understood a few things (literals, tuple syntax, initializer calls), stopped once it had seen enough to infer a complete type, and rejected an expression if it encountered something it didn't understand before finishing. That would probably cover most simple cases, and it would probably only allow expressions whose types were obvious enough that we could use it for arguments, too. (But of course it would mean more code in the compiler, so it might not be worth it.)</div><br class=""><div class="">
<span class="m_8962071201875937301Apple-style-span" style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div class=""><div style="font-size:12px" class="">-- </div><div style="font-size:12px" class="">Brent Royal-Gordon</div><div style="font-size:12px" class="">Architechies</div></div></span>
</div>
<br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></span><br class=""></div></blockquote></div>______________________________<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" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></div></blockquote></div><br class=""></div></div></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=""></div></div></div></div></body></html>