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.
> On Apr 10, 2017, at 9:07 AM, Sean Heber <s...@fifthace.com> 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 <dan...@duan.org> 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 <s...@fifthace.com> 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 >>>> <swift-evolution@swift.org> 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 <mail...@xenonium.com> 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 >>>>>> <swift-evolution@swift.org> 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 >>>>>>> <swift-evolution@swift.org> 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 >>>>>>> swift-evolution@swift.org >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution