Sent from my iPhone > On 12 Apr 2017, at 01:18, Jakub Suder via swift-evolution > <[email protected]> wrote: > > I'm honestly having trouble believing that this is being seriously > proposed... I always saw type inference as one of the most important > advantages of Swift over some older languages, the Swift ebook mentions many > times how smart Swift is that it can infer types for you so that you don't > have to type too much boilerplate.
I think Swift and its compiler have. A lot of other strong points beyond type inference and emphasis on static typing too, but type inference has a very very real cost and sooner or later the language and its community will have to deal with compile times that are a lot slower (some people were reporting about 2+ times slower) than a similar project in Objective-C... that is a very real productivity cost. > And here we're talking about removing this feature that was advertised from > the beginning as Swift's strong point, in order to make the compilation > faster? The compiler speeds will be improved, the syntax will stay with us. > > Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: > Bool = true". But that's my choice, not something I should be forced to do. > It's something to put in style guides, not to enforce with the compiler. > > >> On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution >> <[email protected]> wrote: >> I agree with the sentiment of the proposal, it does add value to overall >> efficiency of swift and make things simpler for the swift team, but as >> Matthew said a blanket ban will add noise to the code. Also this particular >> feature is one of those niceties about swift which makes it very welcoming >> to new adopters. >> >> If some middle ground can be proposed to this problem then I think we will >> be making a lot of people happy. >> >>> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution >>> <[email protected]> wrote: >>> >>> > On Apr 7, 2017, at 2: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? >>> >>> I’m willing to keep an open mind on this topic but I don’t think wholesale >>> banning of inference is the right thing to do. Here is an example of a >>> case where I do not want to give up inference. When a property is >>> initialized inline by calling an initializer of a non-generic type (very >>> common) any annotation is strictly redundant. >>> >>> struct { >>> let foo = Foo() >>> } >>> >>> Requiring a type annotation here feels very unnecessary and boilerplate-y. >>> I adds no additional clarity to a reader of the code, only noise. Noise >>> reduces clarity. Small amounts of unnecessary or redundant information >>> such as in an individual stored property declaration are not that big a >>> deal. But on balance they add up quickly and have an undesirable impact on >>> the overall clarity of code. >>> >>> > >>> > 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 >> >> >> >> -- >> Pranshu Goyal >> iOS Developer >> tlkn >> >> _______________________________________________ >> 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
