plx: wouldn't the same overload resolution strategy be appropriate here?
"most specific choice, otherwise diagnostic"
separately:
Are there any subscripts in the standard library that would be
throwing/generic but can't be?
On Wed, Jun 22, 2016 at 9:13 AM, plx via swift-evolution <
swift-evolution@swift.org> wrote:
> Prefacing the below with a “I am well-aware this proposal likely won’t
> make it into Swift 3”:
>
> A feature like this would be nice to use, but before I could get behind
> any proposal along these lines it I’d want to see it include an explicit
> strategy for disambiguation.
>
> EG: in your example, your generic subscript uses `self[key]`, and
> presumably expects that to use the “original” subscript…and not the generic
> subscript being defined.
>
> I think that’s reasonable in that specific case, but it doesn’t seem
> unreasonable to anticipate this proposal introducing ambiguities that would
> need explicit disambiguation…and for which explicit type annotation may not
> always be adequate to resolve (I could be wrong here, though).
>
> This would need addressing (either showing they won’t be an issue, or
> providing a reliable disambiguation mechanism).
>
> Relatedly, in-re: “rethrows”: if the syntax supported it, this kind of
> thing would be another way of tackling the "JSON problem":
>
> subscript<T>(key: Key, transform: (Value) throws -> T) rethrows -> T {
> guard let value = self[key] else { throw JSON.MissingKey(…) }
> return try transform(value)
> }
>
> …so that e.g. you can write typical parsing-code as
>
> let asUserID = UserID.init(untrustedString:) // <- assume this is a
> "throwing constructor"
> let sender = try json[“sender”,asUserID]
> let recipient = try json[“recipient”,asUserID]
>
> …(modulo any syntax errors, etc.), which would benefit from a `rethrows`
> declaration.
>
> That’s my 2c; thankfully (IMHO) there’s clearly a lot of time for this
> proposal to simmer.
>
> On Jun 20, 2016, at 1:10 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Good morning all. Attached is the proposal Harlan Haskins and I will be
> submitting shortly about adding generic and `throw`ing subscript
> declarations to the language.
>
> Cheers,
>
> ~Robert Widmann
>
> Generic and Throwing Subscripts
>
> - Proposal: SE-NNNN
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
> - Author(s): Harlan Haskins <https://github.com/harlanhaskins> and Robert
> Widmann <https://github.com/codafi>
> - Status: Awaiting review
> <https://github.com/typelift/SwiftCheck/pull/168#rationale>
> - Review manager: TBD
>
> Introduction
>
> Currently, subscripts cannot be declared [re]throws and cannot declare
> new generic parameters.
> There isn't a clear reason why they aren't as capable as full-fledged
> functions, so we propose
> adding generic constraints and throwing semantics to subscripts.
> Motivation
>
> On the throwing side, currently there are two ways to express a failing
> subscript:
>
> - Return an Optional, failing with nil.
> - Call fatalError(_:) on failure.
>
> Both of these throw out useful information about the cause of the
> underlying error that using Swift's error handling mechanism can otherwise
> provide.
>
> As for generics, to take an example, it has become a common pattern among
> JSON decoding DSL libraries to express a throwing generic extension on
> Dictionary like so
>
> extension Dictionary {
> public func parse<T>(key: Key) throws -> T {
> guard let value = self[key] else {
> throw JSONError.MissingKey("\(key)")
> }
> guard let ofType = value as? T else {
> throw JSONError.InvalidKey(key: "\(key)", expectedType: T.self,
> foundType: value.dynamicType)
> }
> return ofType
> }
> }
> public enum JSONError: ErrorType, CustomStringConvertible {
> case InvalidKey(key: String, expectedType: Any.Type, foundType: Any.Type)
> case MissingKey(String)
> public var description: String {
> switch self {
> case .InvalidKey(let key, let expected, let found):
> return "Invalid key \"\(key)\". Expected value of type
> \"\(expected)\", found \"\(found)\"."
> case .MissingKey(let key):
> return "Key \(key) not found."
> }
> }
> }
>
> Given this, one can decode JSON with the full support of native type
> inference and exception handling. But when working with the DSL, one would
> expect to be able to express this as a subscript on Dictionary, allowing
> the following:
>
> //...
> extension Dictionary {
> public subscript<T>(key: Key) throws -> T {
> guard let value = self[key] else {
> throw JSONError.MissingKey("\(key)")
> }
> guard let ofType = value as? T else {
> throw JSONError.InvalidKey(key: "\(key)", expectedType: T.self,
> foundType: value.dynamicType)
> }
> return ofType
> }
> }
>
> We believe this is an even more natural way to write these kinds of
> libraries in Swift and that bringing subscript member declarations up to
> par with functions is a useful addition to the language as a whole.
> Proposed solution
>
> Add the ability to introduce new generic parameters and mark throws and
> rethrows on subscript members.
> Detailed design
>
> This change will modify and add the following productions in the Swift
> grammar
>
> GRAMMAR OF A SUBSCRIPT DECLARATION
>
> subscript-declaration → subscript-head subscript-result code-block
> subscript-declaration → subscript-head subscript-result getter-setter-block
> subscript-declaration → subscript-head subscript-result
> getter-setter-keyword-block-subscript-head → attributes(opt)
> declaration-modifiers(opt) subscript parameter-clause+subscript-head →
> attributes(opt) declaration-modifiers(opt) generic-parameter-clause(opt)
> subscript parameter-clause+subscript-result → -> attributes(opt) throws(opt)
> type+subscript-result → -> attributes(opt) rethrows(opt) type
>
> ------------------------------
> Rationale
> On [Date], the core team decided to (TBD) this proposal.
> When the core team makes a decision regarding this proposal,
> their rationale for the decision will be written here.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
