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.
Daniel Duan Sent from my iPhone > On Apr 10, 2017, at 9:16 AM, Matthew Johnson <[email protected]> wrote: > > >> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution >> <[email protected]> wrote: >> >> 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. > > 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. > >> >>> On Apr 10, 2017, at 9:07 AM, Sean Heber <[email protected]> wrote: >>> >>> 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: >>> >>> Foo foo = new Foo(); >>> >>> Every time I see that sort of thing, I cringe a little. >>> >>> IMO if you wanted to be super opinionated, the language would actually warn >>> if you did this: >>> >>> let foo: Foo = Foo() >>> >>> And offer a fixit to: >>> >>> let foo = Foo() >>> >>> With no warning for things like this because you’re obviously doing >>> something intentional: >>> >>> let foo: FooSuperclass = Foo() >>> >>> But I’d settle for no warnings and getting the inference to work in all >>> contexts. :) >>> >>> l8r >>> Sean >>> >>> >>>> On Apr 10, 2017, at 10:58 AM, Daniel Duan <[email protected]> wrote: >>>> >>>> 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. >>>>> On Apr 10, 2017, at 8:55 AM, Sean Heber <[email protected]> wrote: >>>>> >>>>> This is not really a helpful comment, but: I kinda wish they did. >>>>> >>>>> l8r >>>>> Sean >>>>> >>>>>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Neither of these works btw. >>>>>> >>>>>> func bar(myString = “hello”) >>>>>> class Baz { >>>>>> let myString = { return “hello” }() >>>>>> } >>>>>> >>>>>>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel <[email protected]> wrote: >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Why >>>>>>> >>>>>>> let myString = "hello" >>>>>>> >>>>>>> would be accepted but not >>>>>>> >>>>>>> class Foo { >>>>>>> let myString = "hello" >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution >>>>>>>> <[email protected]> a écrit : >>>>>>>> >>>>>>>> I’m still not sure whether *I* want this. But here’s a proposal >>>>>>>> anyways: https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 >>>>>>>> >>>>>>>>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> 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: >>>>>>>>> >>>>>>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> language slightly more consistent (we are not inferring types for >>>>>>>>> default parameter values in function anyways). >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> Just thought I'd float the idea to gather some quick reaction. What >>>>>>>>> do y'all think? >>>>>>>>> >>>>>>>>> Daniel Duan >>>>>>>>> _______________________________________________ >>>>>>>>> swift-evolution mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
