public var a = 10 // OK, all is clear here
public var a = "sdfsdf" // OK
public var a = someFunction() // not OK - add type of `a` explicitly
I’m not clear on why you think the third one isn’t okay; Xcode can tell you
what the type was inferred to be, you can check the function signature (alt
- click the name) which will tell the type that it returns, as well as call
up any documentation about what it does.
Well.. First of all Swift != XCode, and the OSX is not the only system where Swift is used
Yes, XCode can help a lot - should we design the language with XCode help in mind? I think we should not even think about XCode when discussing Swift features.
Second, we were discussing type inference for default parameters. I said that if we have this type inference in property - IMO there is no reason to not allow the same for default parameters. I.e. you can also use XCode to check the type of default parameter.
BUT personally I prefer to not allow type inference for properties if the assigned value is not 'simple' raw value like 10, 1.5, "sdfsdf" or probably explicit type constructor(like MyEnum.someCase; can be discussed)
The only reason you would need to set a type on the property is if you know
you’ll need to assign something less specific in future, e.g- a parent type
in a class hierarchy.
I was replying to Chris Lattner's "We have a pretty strict rule here: types are allowed to be inferred in implementations, but not interfaces"
IMO we already has type inference in interfaces, this is why IMO Swift can have type inference in default parameters.
The reason you want to have explicit type declaration - is clarity and explicitness of the code, when you understand *interface* of type just by reading it. Not always Swift code will be reviewed in XCode and you can click the function to read its result type.
On 11.05.2016 16:03, Haravikk wrote:
On 11 May 2016, at 13:49, Vladimir.S via swift-evolution >> <firstname.lastname@example.org <mailto:email@example.com>> wrote: