<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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 id="AppleMailSignature"><br></div><div id="AppleMailSignature">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 id="AppleMailSignature"><br></div><div id="AppleMailSignature">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 id="AppleMailSignature"><br><div>Daniel Duan</div>Sent from my iPhone</div><div><br>On Apr 10, 2017, at 9:26 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><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><br class=""></div><div>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">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">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">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">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">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></body></html>