<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 10, 2017, at 11:38 AM, Daniel Duan <<a href="mailto:daniel@duan.org" class="">daniel@duan.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Using tools isn't a bad thing. Designing language assuming users are using tools with certain capability is kind of a bad thing.</div><div class=""><br class=""></div><div class="">Where tools *can* help is if the tools enhance the language user's experience, which is why I proposed the inference capabilities be kept for diagnostics.</div><div class=""><br class=""></div><div class="">I also disagree with the characterization that types in properties is "clustering up" the code. The value inference provided here is make the authoring experience better. I can see for obvious default expressions (string/number literal perhaps) the readability isn't degraded by too much. But it's not as clear as explicit types for the *reader*.</div></div></div></blockquote><div><br class=""></div><div>I said “cluttering”, not “clustering” (which has a more derogatory implication for many people). </div><div><br class=""></div><div>In any case, this is an area where there are differing perspectives each with some merit. I think it’s best to leave it up to each of us what makes the most sense for our code. IMO, and that of at least some others who have commented, some code is more clear to readers with annotations and some is more clear to readers without annotations. </div><div><br class=""></div><div>Like I said earlier, I’m willing to keep an open mind on proposals in this area but I don’t support a wholesale ban on inference directly initialized member declarations. It may not be possible to do something less than a wholesale ban without introducing more confusion than we have today as to when inference is permitted and when it isn’t. If it isn’t that’s ok with me. If it is, I’ll consider such a proposal on its merit if one is brought forward.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""><div class="">Daniel Duan</div>Sent from my iPhone</div><div class=""><br class="">On Apr 10, 2017, at 9:26 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 10, 2017, at 11:22 AM, Daniel Duan <<a href="mailto:daniel@duan.org" class="">daniel@duan.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I guess I'm using the word "export" loosely. Often times I find myself reading type signatures in my own codebase either because it's written by someone else on my team or by myself long time ago. I think open-source library users have the same problem. Exposure to a particular local variable is less likely.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">If you’re reading code in a codebase you work on most of the time you’ll be reading it using a tool that can give you the annotation using something like opt-click in Xcode. I don’t think it’s worth cluttering up our code with annotations that are readily available to most readers. <i class="">Most</i> of the time annotations introduce noise that reduces clarity. I don’t think relying on tools in the occasional case where the type isn’t obvious to an individual reader is a bad thing.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Daniel Duan<br class="">Sent from my iPhone<br class=""><br class=""><blockquote type="cite" class="">On Apr 10, 2017, at 9:16 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I’m not questioning the value of type inference in general. Just that there are practical implications when we want more of them. There’s a difference in inferencing type declaration properties and local variables: the former is more likely to be exported and read by others. These arguments are all in the draft proposal.<br class=""></blockquote><br class="">When a declaration is exported outside a module whoever is reading it isn’t reading the source directly. They are reading documentation or a generated header of some kind. The annotation can easily be added by tools that produce these.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Apr 10, 2017, at 9:07 AM, Sean Heber <<a href="mailto:sean@fifthace.com" class="">sean@fifthace.com</a>> wrote:<br class=""><br class="">Well, I’m not really a beginner, but for me personally, the computer is here to help me do my work and to do some of the thinking for me. I really hate repeating myself when it comes to types - especially if the types get wordy (collections, etc). Swift is pretty good about it - but these warts stick out. The idea that we should make it *less* good at this really rubs me the wrong way. How many times have you seen lines of code like this in C++-ish/C#-ish languages:<br class=""><br class="">Foo foo = new Foo();<br class=""><br class="">Every time I see that sort of thing, I cringe a little.<br class=""><br class="">IMO if you wanted to be super opinionated, the language would actually warn if you did this:<br class=""><br class="">let foo: Foo = Foo()<br class=""><br class="">And offer a fixit to:<br class=""><br class="">let foo = Foo()<br class=""><br class="">With no warning for things like this because you’re obviously doing something intentional:<br class=""><br class="">let foo: FooSuperclass = Foo()<br class=""><br class="">But I’d settle for no warnings and getting the inference to work in all contexts. :)<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 10, 2017, at 10:58 AM, Daniel Duan <<a href="mailto:daniel@duan.org" class="">daniel@duan.org</a>> wrote:<br class=""><br class="">It is helpful in the sense that it tells us what’s really inconsistent: beginner’s have to learn when inference is available when declaring their types. That’s story is sketchy.<br class=""><blockquote type="cite" class="">On Apr 10, 2017, at 8:55 AM, Sean Heber <<a href="mailto:sean@fifthace.com" class="">sean@fifthace.com</a>> wrote:<br class=""><br class="">This is not really a helpful comment, but: I kinda wish they did.<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><blockquote type="cite" class="">On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Neither of these works btw.<br class=""><br class="">func bar(myString = “hello”)<br class="">class Baz {<br class="">let myString = { return “hello” }()<br class="">}<br class=""><br class=""><blockquote type="cite" class="">On Apr 9, 2017, at 11:26 PM, Jean-Daniel <<a href="mailto:mailing@xenonium.com" class="">mailing@xenonium.com</a>> wrote:<br class=""><br class="">I’m full -1 on this one. It will make the language inconsistent. How do you explain a new comer that type inference work in some case, but not in other cases, while in both the compiler is completely capable to define the type.<br class=""><br class="">Why <br class=""><br class="">let myString = "hello" <br class=""><br class="">would be accepted but not <br class=""><br class="">class Foo {<br class=""> let myString = "hello" <br class="">}<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><br class="">I’m still not sure whether *I* want this. But here’s a proposal anyways: <a href="https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55" class="">https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55</a><br class=""><br class=""><blockquote type="cite" class="">On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" 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" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-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="">Daniel Duan<br 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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br 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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""></blockquote><br 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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""></blockquote><br class=""></blockquote><br class=""></blockquote><br 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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>