That's kind of my perspective too. Personally I adore this feature. But compiling speed is such a severe issue at work that I'm willing to part with it. (Not saying other arguments aren't important).
I'm lucky enough to work on a project that is: 1. purely Swift 2. Vigilantly monitored for compilation slow-down from complex expressions 3. Really large (enough that compiling speed is a severe problem). I think with time more and more ppl will experience the same thing. As I noted in the proposal, swiftc has space for speed improvement in this area and I believe the implementators will get there. In the mean time inference may still pose a theoretic performance upper bound. Daniel Duan Sent from my iPhone > On Apr 10, 2017, at 9:51 AM, Matthew Johnson <[email protected]> wrote: > > >> On Apr 10, 2017, at 11:38 AM, Daniel Duan <[email protected]> wrote: >> >> Using tools isn't a bad thing. Designing language assuming users are using >> tools with certain capability is kind of a bad thing. >> >> 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. >> >> 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*. > > I said “cluttering”, not “clustering” (which has a more derogatory > implication for many people). > > In any case, this is an area where there are differing perspectives each with > some merit. I think it’s best to leave it up to each of us what makes the > most sense for our code. IMO, and that of at least some others who have > commented, some code is more clear to readers with annotations and some is > more clear to readers without annotations. > > Like I said earlier, I’m willing to keep an open mind on proposals in this > area but I don’t support a wholesale ban on inference directly initialized > member declarations. It may not be possible to do something less than a > wholesale ban without introducing more confusion than we have today as to > when inference is permitted and when it isn’t. If it isn’t that’s ok with > me. If it is, I’ll consider such a proposal on its merit if one is brought > forward. > >> >> Daniel Duan >> Sent from my iPhone >> >>> On Apr 10, 2017, at 9:26 AM, Matthew Johnson <[email protected]> wrote: >>> >>> >>>> On Apr 10, 2017, at 11:22 AM, Daniel Duan <[email protected]> wrote: >>>> >>>> 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. >>> >>> 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. Most 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. >>> >>>> >>>> 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
