[swift-evolution] [Proposal] Generic and `throw`ing subscripts
Matthew Johnson
matthew at anandabits.com
Wed Jun 22 09:29:51 CDT 2016
> On Jun 22, 2016, at 9:11 AM, plx via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>> On Jun 22, 2016, at 8:28 AM, T.J. Usiyan <griotspeak at gmail.com <mailto:griotspeak at gmail.com>> wrote:
>>
>> plx: wouldn't the same overload resolution strategy be appropriate here? "most specific choice, otherwise diagnostic”
>
> I’d assume it’d be good enough for most cases, certainly; I’d love to turn out to be needlessly scaremongering here, too.
>
> But (hopefully unintentionally!) it seems like you could easily wind up with scenarios like this:
>
> // from proposal:
> public subscript<T>(key: Key) throws -> T {
> guard let value = self[key] else { throw ... }
> guard let ofType = value as? T else { throw ... }
> return ofType
> }
>
> // an annoying addition:
> public subscript<T:RawRepresentable>(key: Key) throws -> T {
> guard let v = self[key] else { throw ... }
> guard let rawValue = v as? T.RawValue else { throw ... }
> guard let converted = T(rawValue: rawValue) else { throw ... }
> return converted
> }
>
> // assume `Foo:RawRepresentable`:
> let foo: Foo = json["foo"]
>
> …and similar, where I’d assume the `T:RawRepresentable` would “win”, but I’m not sure *how* you could force use of the *other* subscript in the above.
>
> This isn’t really a new problem, but it seems likelier to be encountered if generic subscripts become allowed, due to all subscripts having the same “name”.
This isn’t exactly true. External argument labels are considered part of the “name” in Swift. Subscripts parameters don’t get external labels automatically like other functions / methods do, but you can still add one if you *want* the ability to disambiguate.
Of course this won’t help if you require the ability to use both subscripts without a label but is worth noting. It is also worth noting that this behavior is no different from that of any other function or method - if the name (including external argument labels) matches the most specific overload will always be selected.
One way to make your example work properly when `T` is `RawRepresentable` and the dictionary actually contains an instance of `T` is to add an extra check for that case:
public subscript<T:RawRepresentable>(key: Key) throws -> T {
guard let v = self[key] else { throw … }
// extra check here in case the value is *already* T and therefore does not require conversion.
if let value = v as? T { return value }
guard let rawValue = v as? T.RawValue else { throw ... }
guard let converted = T(rawValue: rawValue) else { throw ... }
return converted
}
>
> But again I’d like to be wrong about the issue (or at least the severity).
>
>>
>> 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/f34937e1/attachment.html>
More information about the swift-evolution
mailing list