[swift-evolution] [Pitch] Remove type-inference for stored property

Goffredo Marocchi panajev at gmail.com
Wed Apr 12 01:50:56 CDT 2017


Sent from my iPhone

> On 12 Apr 2017, at 01:18, Jakub Suder via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> wrote:
>>> 
>>> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution <swift-evolution at 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?
>>> 
>>> 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
>>> > swift-evolution at swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> -- 
>> Pranshu Goyal
>> iOS Developer
>> tlkn
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170412/ba8ec9e6/attachment.html>


More information about the swift-evolution mailing list