I've incorporated the feedback from the previous thread, "[Draft] Throwing Properties and Subscripts", into my proposal on permitting getters and setters to throw.
Draft 2 formatted <https://github.com/brentdax/swift-evolution/blob/throwing-properties-draft-2/proposals/0000-throwing-properties.md>, diffs from draft 1 <https://github.com/brentdax/swift-evolution/compare/throwing-properties-draft-1...throwing-properties-draft-2>, head of the branch formatted <https://github.com/brentdax/swift-evolution/blob/throwing-properties-draft/proposals/0000-throwing-properties.md>.
I've pasted the Drafting Notes section below, which summarize both the changes I've made so far, and which parts of the proposal as it stands I would most like feedback on. (I'm also including the Introduction for those who missed the first thread.)
Thanks to everyone who critiqued the first 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 threads: Proposal: Allow Getters and Setters to Throw <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001165.html>, [Draft] Throwing Properties and Subscripts <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012602.html>
This proposal is still being drafted.
Added discussion of several pieces of feedback to "Alternatives considered" and "Future directions", including:
Commas in the protocol requirement keyword list.
A shorthand syntax for cases where both accessors throw.
The possibility of omitting throwing getters. This includes an extensive example in "Future directions" of a language feature which might be enabled by supporting throwing getters.
Specified grammar changes and vastly expanded discussion of compiler-internal accessors.
Clarified inout semantics slightly.
Various minor wording changes.
The Implementation section could probably use detail on other implementation issues, and could certainly use a look from someone who knows the compiler's guts a lot better than I do. (I'm not even sure it should be there at all.)
Several parts of this proposal are, at least in principle, severable; I would appreciate feedback on which of these, if any, should be left for future proposals. Candidates include (roughly in order from things I'd be happiest removing to things I'd be least happy removing):
Throwing setters on stored properties with willSet throws
Shorthand syntax (e.g. subscript(i: Int) throws -> Element) has already been subsetted out, mainly because I don't have a satisfying design for it on properties.