I've drafted a proposal to allow property and subscript accessors to throw errors:
I've left a lot of the rationale for particular design decisions for the "Alternatives considered" section, so please take a look at that before you ask, for instance, why this proposal doesn't import any Objective-C methods as throwing subscript accessors.
Throwing Properties and Subscripts
Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author(s): Brent Royal-Gordon <https://github.com/brentdax>
Status: Draft
Review manager: TBD
<GitHub - beccadax/swift-evolution at throwing-properties-draft
Functions, methods, and initializers can be marked throws to indicate that they can fail by throwing an error, but properties and subscripts cannot. This proposal extends properties and subscripts to support throws and rethrows accessors, and also specifies logic for bridging these accessors to and from Objective-C.
Swift-evolution thread: Proposal: Allow Getters and Setters to Throw <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001165.html>
<GitHub - beccadax/swift-evolution at throwing-properties-draft
Sometimes, something that is genuinely getter- or setter-like needs to be able to throw an error. This is particularly common with properties which convert between formats:
var image: UIImage
var imageData: NSData {
get {
return UIImagePNGRepresentation(image)
}
set {
image = UIImage(data: newValue) ?? throw OopsICantThrowHere
}
}
Or which access some external resource which may not be able to perform the operation:
var avatar: UIImage {
get {
let data = try NSData(contentsOfURL: avatarURL, options: ) /* can't try here! */
return UIImage(data: data)
}
}
The current best solution to this problem is to write a method instead of a property. This can lead to unnatural API designs; the class AVAudioSession alone, for instance, has no less than ten mismatched property/setter method pairs:
var category: String { get }
func setCategory(_ category: String) throws
var mode: String { get }
func setMode(_ mode: String) throws
var inputGain: Float { get }
func setInputGain(_ gain: Float) throws
var preferredSampleRate: Double { get }
func setPreferredSampleRate(_ sampleRate: Double) throws
var preferredIOBufferDuration: NSTimeInterval { get }
func setPreferredIOBufferDuration(_ duration: NSTimeInterval) throws
var preferredInputNumberOfChannels: Int { get }
func setPreferredInputNumberOfChannels(_ count: Int) throws
var preferredOutputNumberOfChannels: Int { get }
func setPreferredOutputNumberOfChannels(_ count: Int) throws
var preferredInput: AVAudioSessionPortDescription? { get }
func setPreferredInput(_ inPort: AVAudioSessionPortDescription?) throws
var inputDataSource: AVAudioSessionDataSourceDescription? { get }
func setInputDataSource(_ dataSource: AVAudioSessionDataSourceDescription?) throws
var outputDataSource: AVAudioSessionDataSourceDescription? { get }
func setOutputDataSource(_ dataSource: AVAudioSessionDataSourceDescription?) throws
While most classes aren't nearly this bad, you see the same problem elsewhere in the frameworks. The Mac-only CoreWLAN framework has similar mismatched property/setter method pairs (though it also has other bridging issues; I suspect it's too obscure to have been audited yet):
func wlanChannel() -> CWChannel!
func setWLANChannel(_ channel: CWChannel!, error error: NSErrorPointer) -> Bool
func powerOn() -> Bool
func setPower(_ power: Bool, error error: NSErrorPointer) -> Bool
When the getter can throw, it gets even worse. NSURL has an awkward pair of methods to get "resource values" which would be better expressed as a throwing read-write subscript:
func getResourceValue(_ value: AutoreleasingUnsafeMutablePointer<AnyObject?>, forKey key: String) throws
func setResourceValue(_ value: AnyObject?, forKey key: String) throws
<GitHub - beccadax/swift-evolution at throwing-properties-draft solution
Swift can handle these cases better by allowing getters and setters to throw.
<GitHub - beccadax/swift-evolution at throwing-properties-draft computed properties
You can mark a computed property accessor as throwing by putting throws after the get or set keyword:
var property: Int {
get throws { ... }
set throws { ... }
}
subscript(index: Int) -> Bool {
get throws { ... }
set throws { ... }
}
The throwing behavior of the getter and setter are completely independent; a throwing getter can be paired with a non-throwing setter, or vice versa.
var property: Int {
get throws { ... }
set { ... }
}
subscript(index: Int) -> Bool {
get { ... }
set throws { ... }
}
A protocol (or, if added later, an abstract class) can specify the throwing behavior of properties and subscripts it requires:
protocol MyProtocol {
var property: Int { get throws set throws }
subscript(index: Int) -> Bool { get throws set throws }
}
<GitHub - beccadax/swift-evolution at throwing-properties-draft stored properties
A stored property can also be given a throwing setter by giving it a willSet accessor that throws:
var property: Int {
willSet throws {
guard newValue >= 0 else {
throw MyError.PropertyOutOfRange (newValue)
}
}
}
<GitHub - beccadax/swift-evolution at throwing-properties-draft throwing property accessors from Objective-C
When a readonly property foo of type T is imported from Objective-C, but a method like this exists on the same type:
- (BOOL)setFoo:(T)value error:(NSError**)error;
Swift will import foo as a readwrite property with a throwing setter.
If SE-0044 Import as member <https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md> is accepted, we should also be able to apply the swift_name attribute to methods of these forms to create properties with throwing getters:
- (nullable T)foo:(NSError**)error; // property is not optional
- (BOOL)getFoo:(T*)outValue error:(NSError**)error;
No imports for throwing subscript accessors are specified.
These transformations should be applied to both classes and protocols.
<GitHub - beccadax/swift-evolution at throwing-properties-draft throwing property and subscript accessors to Objective-C
A throwing setter for a property foo of type T should be exposed to Objective-C as:
- (void)setFoo:(T)value error:(NSError**)error;
A throwing getter for a property foo of type T, where T is not optional but can be nullable in Objective-C, should be exposed to Objective-C as:
- (nullable T)foo:(NSError**)error;
Otherwise, the getter should be exposed as:
- (BOOL)getFoo:(nonnull T*)outValue error:(NSError**)error;
A throwing setter for a subscript of type T with an index of type I, if marked with @objc(name), should be compatible with this signature:
- (BOOL)setFoo:(T)value atIndex:(I)index error:(NSError**)error;
A throwing getter for a subscript of type T with index I, where T is not optional but can be nullable in Objective-C, should be compatible with this signature:
- (nullable T)fooAtIndex:(I)index error:(NSError**)error;
Otherwise, the getter should be have a name compatible with this signature:
- (BOOL)getFoo:(nonnull T*)outValue atIndex:(I)index error:(NSError**)error;
Throwing subscript accessors which are not marked with @objc(name) will not be exposed to Objective-C.
These transformations should be applied to both classes and @objc protocols.
<GitHub - beccadax/swift-evolution at throwing-properties-draft design
<GitHub - beccadax/swift-evolution at throwing-properties-draft with rethrows
rethrows is not supported on properties, but it is supported on subscripts. The rethrowing behavior depends only on the subscript's parameters, not the setter's newValue; that is, a particular subscript access can throw iff at least one of the functions inside the square brackets can throw.
<GitHub - beccadax/swift-evolution at throwing-properties-draft accessors and inout parameters
A throwing property or subscript access can be passed as an inout parameter. The call it is passed to must be marked with the try keyword.
To avoid unpredictable interactions between inout and throwing accessors, Swift will guarantee the getter is invoked once before the call and the setter once after the call. The compiler will not apply optimizations which might cause errors to be thrown in the middle of the function.
<GitHub - beccadax/swift-evolution at throwing-properties-draft requirement compatibility
An implementation can be "less" throwing than a requirement it is intended to satisfy. That is:
A throwing accessor requirement can be fulfilled by a throwing, rethrowing, or non-throwing accessor.
A rethrowing accessor requirement can be fulfilled by a rethrowing or non-throwing accessor.
A non-throwing accessor requirement can be fulfilled only by a non-throwing accessor.
These definitions apply to protocol (and abstract class) conformance, subclass overrides, and library resilience. (Note that last point: Swift must permit an accessor to be made less throwing without breaking binary compatibility.)
When overriding a throwing accessor, the override must explicitly state the expected level of throwing behavior; omitting the keyword means the accessor is non-throwing. That is, in this example, Subclass.foo's setter is not automatically throws:
class Superclass {
var foo: Int {
willSet throws { ... }
}
}
class Subclass: Superclass {
override var foo: Int {
set { try super.foo = newValue }
// Error: nonthrowing setter includes throwing statement
}
}
<GitHub - beccadax/swift-evolution at throwing-properties-draft
The internal materializeForSet is as throwing as the "most" throwing of get and set.
FIXME: Beyond that, I have no idea. Sorry. Please help me fill this out.
<GitHub - beccadax/swift-evolution at throwing-properties-draft on existing code
Some APIs will be imported differently, breaking call sites. The Swift compiler will need to provide fix-it and migration support for these cases.
<GitHub - beccadax/swift-evolution at throwing-properties-draft considered
<GitHub - beccadax/swift-evolution at throwing-properties-draft setters to be at least as throwing as getters
Calling a setter often implicitly involves calling a getter, so it may make sense to require the setter to be at least as throwing as the getter. Absent feedback to this effect from implementors, however, my instinct is to leave them independent, as there may be use cases where a get can throw but a set cannot. (For instance, if an instance faults in data from an external source on demand, but only writes that data back when a save() call is invoked, get may throw if it's unable to fault in the data, but set would never need to throw.)
<GitHub - beccadax/swift-evolution at throwing-properties-draft rethrows setters throwing if newValue is throwing
newValue is sort of like a parameter to the setter, so it might technically be more consistent for rethrows to consider newValue when deciding if a particular invocation throws or not. However, I can't imagine a case where this would be appropriate behavior, and considering only the subscript parameters makes the getter and setter work better together.
<https://github.com/brentdax/swift-evolution/tree/throwing-properties-draft#dont-include-willset-throws>Don't include willSet throws
The use of willSet throws to make a stored property throwing is a bit funky and could be omitted. I decided to include it because, if it does not exist, people will fake it with private properties anyway.
<GitHub - beccadax/swift-evolution at throwing-properties-draft didSet throws
There is no technical reason not to support didSet throws accessors, which would allow stored properties to be made throwing. However, this would usually be the wrong thing to do because it would leave the errant value in the property. If compelling use cases for it were cited, however, didSet throws could be added.
<GitHub - beccadax/swift-evolution at throwing-properties-draft try on &foo itself, rather than the call using it
As specified, if foo has a throwing accessor and you want to pass it to a function bar with an inout parameter, you have to write this:
try bar(&foo)
In theory, we could instead allow you to mark only the & operator, leaving the rest of the expression uncovered by the try:
bar(try &foo)
This would make the source of the potential error more obvious, but it might make the semantics less clear, because try &foo can throw after the call is finished in addition to before. I judge the latter issue to be more serious.
<GitHub - beccadax/swift-evolution at throwing-properties-draft to convert keyed getter/setter methods to subscripts
Swift could conceivably apply heuristics to discover Objective-C method pairs that can be expressed as subscripts. For instance, the NSURL method pair cited in the Motivation section:
func getResourceValue(_ value: AutoreleasingUnsafeMutablePointer<AnyObject?>, forKey key: String) throws
func setResourceValue(_ value: AnyObject?, forKey key: String) throws
Could be imported like this:
subscript (resourceValueFor key: String) -> AnyObject? {
get throws
set throws
}
There are several reasons not to do this:
There is no established pattern for throwing subscripts in Objective-C, so any we might establish would be mistake-prone.
SE-0044 <https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md> does not currently include subscripts, so there is no proposal pending which would allow the heuristic to be tweaked or the import logic to be invoked manually. (This is arguably an oversight in SE-0044.)
Many such cases would benefit from a human looking at the design. In the NSURL case, for instance, a human looking at the broader type might prefer a design like this:
var resourceValues: ResourceValues { get }
struct ResourceValues {
subscript (key: String) -> AnyObject? {
get throws { ... }
set throws { ... }
}
func get(for keys: [String]) throws -> [String: AnyObject] { ... }
func set(from dict: [String: AnyObject]) throws { ... }
func removeCachedKeys() { ... }
func removeCachedKey(key: String) { ... }
func setTemporaryValue(_ value: AnyObject?, for key: String) { ... }
}
<GitHub - beccadax/swift-evolution at throwing-properties-draft export throwing subscript accessors to Objective-C
Throwing subscript accessors can only be exported by specifying a name using an @objc property. It might be nice to export them by default, but Objective-C doesn't have an established pattern for throwing subscript accessors, so it's not clear how these methods would be named.
<GitHub - beccadax/swift-evolution at throwing-properties-draft a nothrows keyword
Leaving an accessor's throwing behavior unspecified could make it automatically take on the behavior required by the type's superclass or conformed protocols. However, this would require a way to explicitly state that an accessor could notthrow, along the lines of the rarely-used but necessary nonmutating keyword.
I have chosen not to do this because Swift generally does not allow you to infer parts of a member's signature, and because I cannot come up with a way to spell this keyword that isn't ugly as sin.
···
--
Brent Royal-Gordon
Architechies