Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-6063] KeyedDecodingContainer unnecessarily verbose #48620

Open
DagAgren mannequin opened this issue Oct 4, 2017 · 3 comments
Open

[SR-6063] KeyedDecodingContainer unnecessarily verbose #48620

DagAgren mannequin opened this issue Oct 4, 2017 · 3 comments

Comments

@DagAgren
Copy link
Mannequin

DagAgren mannequin commented Oct 4, 2017

Previous ID SR-6063
Radar None
Original Reporter @DagAgren
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Improvement
Assignee @itaiferber
Priority Medium

md5: 0fbbda081c8f375951c544eb7669acc1

Issue Description:

The KeyedDecodingContainer.decode() take a type as their argument. This seems redundant, as the return type could easily be used to infer what type is being decoded.

Are there any plans to include versions of decode() that do not need the type to be explicitly specified? It is trivial to write an extension that does this, but it feels like this should be provided by the standard library.

@belkadan
Copy link
Contributor

belkadan commented Oct 5, 2017

It's pretty standard to not rely on return type inference for something where the type isn't constrained in any way, because it's too easy to slip up. (For example, assigning to a property with type Int? would pass Int? as the type, which would fail to decode an Int.) Additionally, it would make decoding into a local binding more confusing, since people conventionally write those without type annotations.

This doesn't mean this change can't happen, but it would need to go through the Swift Evolution Process.

cc @itaiferber

@itaiferber
Copy link
Contributor

itaiferber commented Oct 5, 2017

This was discussed at length on the swift-evolution mailing list a while back. It's something that's possible for us to add in the future via extensions (so I won't close this issue), but there are a variety of cases where explicitly specifying the generic type is necessary (and the canonical way to do this is to pass in a metatype parameter).

Jordan mentions one such case:

// Elsewhere: var myFoo: Int?
// myFoo has to be optional for other reasons, but here we definitely want to decode an Int or fail if we can't.
// If we just decode(.myFoo) and forget to pass in a concrete type, this would silently fail.
self.myFoo = try container.decode(Int.self, forKey: .myFoo)

Another case that comes to mind:

class Foo { ... }
class Bar : Foo { ... }

// Elsewhere: var myFoo: Foo
// The static type of myFoo has to be Foo for other reasons, but here we definitely want to decode a Bar.
self.myFoo = try container.decode(Bar.self, forKey: .myFoo)

As mentioned, it's easy to add extensions to do this if you'd like, e.g.:

extension KeyedDecodingContainer {
    func decode<T : Decodable>(_ key: Key, as type: T.Type = T.self) -> T {
        return self.decode(T.self, forKey: key)
    }
}

so this would have to fall under the same scrutiny that we apply to adding other APIs to the stdlib, i.e.: What is the cost-benefit ratio of adding new API here?

@DagAgren
Copy link
Mannequin Author

DagAgren mannequin commented Oct 5, 2017

These seem like fairly rare cases that, on average, you'd expect people to be aware of anyway, though. It seems a little bit overkill to make the API more verbose and less ergonomic to protect against carelessness in rare cases.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants