> 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
