> 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
