I knew there were good reasons for this. Thanks mates.
(I don't personally see a need for a new @nonoverriding feature, by the way.)
27. Jan 2017 22:26 by jordan_r...@apple.com:
>
>
>> On Jan 27, 2017, at 11:04, Slava Pestov via swift-users <>>
>> swift-users@swift.org>> > wrote:
>>
>>>
>>> On Jan 27, 2017, at 10:39 AM, tuuranton--- via swift-users <>>>
>>> swift-users@swift.org>>> > wrote:
>>> Yes, but why?
>>> What's the rationale for this?
>>> What would be so bad about allowing overriding a non-failable initializer
>>> with a failable initializer?
>>
>> If the non-failable initializer witnesses a non-failable protocol
>> requirement, and the subclass overrides it, what should be the runtime
>> behavior if the subclass initializer returns nil? The caller won’t expect
>> it, since the caller is calling a non-failable initializer.
>
> This > particular> objection only applies to 'required' initializers, though.
>
>
>>
>> For similar reasons, you cannot override a method that returns a
>> non-optional value with a method returning an optional value.
>
> Yes, this is true.
> Jordan
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
