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
