> On 11 May 2016, at 14:59, Vladimir.S <sva...@gmail.com> wrote:
>
> On 11.05.2016 16:03, Haravikk wrote:
>>
>>> On 11 May 2016, at 13:49, Vladimir.S via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> 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 ;-)
I don’t disagree, but nor is Xcode unique in helping to figure out what a type
is; I think it’s okay to consider that any good modern IDE should be able to
tell us what a type is if the compiler can. Besides, in the example,
someFunction() could be buried somewhere hard to find, sure, or it could also
be declared clearly earlier in the same file, or in a commonly used file for
that module, in which case it’s probably very well known. I think it’s fine to
infer the type in these cases because forcing the developer to supply it may
not add anything, and in cases where it does it’s easy enough to just do this
yourself; even if you’re maintaining unfamiliar code, it shouldn’t take long to
look up the type and add it for others if you really feel you have to, but
again, any good IDE should render it a non-issue.
As to the original issue (realised I hadn’t commented on it yet), I’m
undecided; I like type inference for declarations as inference is very common
for these, and I myself usually only supply a type if there’s ambiguity or I
want something to become optional. My main concern is that default parameter
values are relatively rare (compared to those without them), so it becomes an
issue of consistency for me.
It might be different if for example we could omit type when it can inferred by
other means as well, for example:
protocol FooType {
func someMethod(value:String) -> Void
}
struct Foo : FooType {
func someMethod(value) -> Void { … } // value is a String
}
But I’m not sure if I’d want to do that or not. Generally I like things that
shorten function signatures, but on its own I’d prefer consistency over
inference in this case I think._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
