'subscript' function can't be throwable?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

'subscript' function can't be throwable?

Jens Alfke
The current Swift 2 compiler doesn’t allow a subscript operator to throw exceptions; at least, if I declare it like this:

    public subscript(name: String) throws -> Something? { … }

I get the familiar “Consecutive declarations on a line must be separated by ‘;’” error at the “throws” keyword.

Is this an intentional design limitation, or just a compiler bug?

In my case, the subscript operator is looking up a value from a database given its key, so there are various ways it could fail aside from there not being a value.

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/962B5B1A-29FE-465C-9929-8FF3C6CD1D6B%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 'subscript' function can't be throwable?

Chris Lattner

On Jun 11, 2015, at 10:56 AM, Jens Alfke <[hidden email]> wrote:

The current Swift 2 compiler doesn’t allow a subscript operator to throw exceptions; at least, if I declare it like this:

    public subscript(name: String) throws -> Something? { … }

I get the familiar “Consecutive declarations on a line must be separated by ‘;’” error at the “throws” keyword.

Is this an intentional design limitation, or just a compiler bug?

In my case, the subscript operator is looking up a value from a database given its key, so there are various ways it could fail aside from there not being a value.

We haven’t discussed allowing subscripts and computed properties to be throwable yet, but I don’t see any obvious reason to to support them.  That said, supporting this would introduce some complexity into the model: We’d have to decide whether the getter and setter could have different throws markers.  While being able to express that would be great, allowing that would actually be quite hard and surprising for our model. We’d have to support protocol requirements, overload, etc.

In any case, we need to talk about this, we’ll do so over the next few weeks.

-Chris

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/B261FAF5-33E1-4047-917B-686C90A1F01C%40apple.com.
For more options, visit https://groups.google.com/d/optout.