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

[Vladimir.S]

On 12.04.2017 7:19, Jaden Geller wrote:
> 
>> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution 
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> On 07.04.2017 10:21, Daniel Duan via swift-evolution 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?
>>
>> Although it seems like only an implementation-side problem(i.e. "let's just improve 
>> implementation"), I see a benefits to require type for stored property *if* it is 
>> not obvious what the type is for *reader*. I.e. if we have something like this, I 
>> don't think we should require a type:
>> struct S {
>>  var x = 0
>> }
> 
> I think there is value in requiring a type annotation there. For example, this bug 
> would be avoided: https://twitter.com/benjaminencz/status/851892622213783552

I believe the pointed problem is much wider, than type-inference and I even think 
this is bug(in design?) that should be fixed at least with warning.

Please consider this example:

protocol P {
	var value : Int32 {get}
}

extension P {
	var value : Int32 {return 20}
}

class C : P {
	let value = 4_000_000_000

	/// or even this:
    	// let value : Int = 4_000_000_000
}

First, as class C conforms to P protocol, it must have *mutable* 'value' property
Second, currently it seems like class C has two 'value' properties with different 
type. It is very strange(the principle of less surprise, yes?) and as we can see 
dangerous behavior. Was bug to bugs.swift.org submitted? If so, what was the reply of 
the core team?

> 
>>
>> but I do think it will be better to require a type in such cases :
>>
>> struct S{
>>  var x = something(SomeType(), 123, "123") // can be generic func
>> }
>>
>>
>>
>>>
>>> Daniel Duan _______________________________________________
>>> swift-evolution mailing listswift-evolution at swift.org 
>>> <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>