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
> <swift-evolution@swift.org> a écrit :
>
> I’m still not sure whether *I* want this. But here’s a proposal anyways:
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
> <https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55>
>
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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
>>
>> <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
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
