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

Matthew Johnson matthew at anandabits.com
Fri Apr 7 08:01:44 CDT 2017

> 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

More information about the swift-evolution mailing list