Why would you want lack of an optional method to be a fatal error, either?
Charles
> On Apr 27, 2016, at 5:29 PM, Andrew Bennett wrote:
>
> Hi Charles,
>
> My initial idea just had a fatalError, without a throw. It's better IMO, but
> less Swift-y. It's not obvious from the
Hi Charles,
My initial idea just had a fatalError, without a throw. It's better IMO,
but less Swift-y. It's not obvious from the Swift protocol definition that
this could happen. I'm not sure if it's possible for the extension method
to have @noreturn or similar on it.
On Thursday, 28 April
> On Apr 27, 2016, at 9:30 AM, Andrew Bennett via swift-evolution
> wrote:
>
> Sorry if this has been discussed, but have you considered dropping optional
> entirely, making it throw, and a default implementation that throws a
> selector not found exception?
>
>
Interesting idea. I tried this in a playground to see what the calling syntax
would be like:
let delegate = Optional(Delegate())
let default = 0
let value: Int = (try? delegate?.returnFive() ?? default) ?? default
value
Not quite as elegant at the call site, but it works. Sadly the rethrowing
Sorry if this has been discussed, but have you considered dropping optional
entirely, making it throw, and a default implementation that throws a
selector not found exception?
This is approximately what you would expect using it in objc. I don't think
it has the complexity discussed in the
> On Apr 26, 2016, at 3:33 AM, James Froggatt wrote:
>
> Fair enough. Upon reflection, I think my real issue is somewhat different to
> what I suggested previously.
>
> I wasn't intending to suggest such a thing would be practical, just that it
> would be a decent
Perhaps, with this thought in mind, we should consider making @objc into
something more resembling the @available syntax. Getter selector, setter
selector, copying, etc. could live there as well.
Sincerely,
Zachary Waldowski
z...@waldowski.me
On Tue, Apr 26, 2016, at 01:15 AM, Brent
Fair enough. Upon reflection, I think my real issue is somewhat different to
what I suggested previously.
I wasn't intending to suggest such a thing would be practical, just that it
would be a decent alternative to optional protocol requirements. The
alternative given in the proposal seems to
> * What is your evaluation of the proposal?
I think this proposed solution doesn't really address the problem. An
@objcOptional keyword is intended to make it clear that the feature is
fundamentally, intrinsically, for Objective-C compatibility. Separating the
keywords doesn't do that;
I support the approach of making optional requirements ObjC-only. As a nitpick,
it feels "wrong" to me to keep a decl modifier around for something that's only
a compatibility feature and not natively supported. The proposal notes that a
'objcoptional' modifier was considered and rejected, but
Sent from my iPhone
> On Apr 25, 2016, at 12:37 PM, Joe Groff wrote:
>
> I support the approach of making optional requirements ObjC-only. As a
> nitpick, it feels "wrong" to me to keep a decl modifier around for something
> that's only a compatibility feature and not
Eliminating optional protocol requirements is fine by me. The proposal mentions
‘correcting’ the optional protocol requirement pattern by changing the methods
to optional closure properties, but my feeling is that this ‘solution’ just
acts to continue and perhaps encourage the anti-pattern
Hello Swift community,
The review of "SE-0070: Make Optional Requirements Objective-C only" begins now
and runs through May 2. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md
Reviews are an important part of
13 matches
Mail list logo