If throwing subscripts made it in the Swift 4 timeframe, then we would
certainly consider it.
On 16 Mar 2017, at 13:19, Matthew Johnson wrote:
> On Mar 16, 2017, at 3:01 PM, Itai Ferber <ifer...@apple.com> wrote:
Subscripts, by the way, would not help here, since they cannot throw.
decode must be able to throw.
SR-238
<https://bugs.swift.org/browse/SR-238?jql=text%20%7E%20%22subscript%20throw%22>;
for Apple folks, 28775436.
They don’t “help” but they do provide a more natural interface.
If the Foundation team feels a more wordy interface is necessary that
is ok.
I specifically mentioned that they can’t throw yet. Throwing
subscripts would make a good companion proposal if they could fit into
the Swift 4 timeframe. If not, then yes we need a method rather than
a subscript. But if we can get throwing subscripts into Swift 4, why
not use Swift’s first class syntactic support for keyed access to
keyed containers?
On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote:
On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
wrote:
On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via
swift-evolution wrote:
I don’t have an example but I don’t see a problem either.
There are two options for specifying the return type manually. We
can use the signature you used above and use `as` to specify the
expected type:
let i = decode(.myKey) as Int
The awkwardness of this syntax is exactly what I'm referring to.
Would a beginner know to use "as Int" or ": Int"? Why would they?
The "prettiness" of the simple case doesn't make up for how
difficult it is to understand and fix its failure cases.
Any official Swift or Foundation API shouldn't, or shouldn't need
to, make use of "tricky" syntax.
I don’t think this is especially tricky. Nevertheless, we can
avoid requiring this syntax by moving the type argument to the end
and providing a default. But I think return type inference is worth
supporting. It has become widely adopted by the community already in
this use case.
If we don’t support this in Foundation we will continue to see
3rd party libraries that do this.
The proposal's been out for less than 24 hours, is it really
productive to already be taking our ball and go home over such a
minor thing?
I don’t think that’s what I’m doing at all. This is a
fantastic proposal. I’m still working through it and writing up my
more detailed thoughts.
That said, as with many (most?) first drafts, there is room for
improvement. I think it’s worth pointing out the syntax that many
of us would like to use for decoding and at least considering
including it in the proposal. If the answer is that it’s trivial
for those who want to use subscripts to write the wrappers for return
type inference and / or subscripts themselves that’s ok. But
it’s a fair topic for discussion and should at least be addressed
as an alternative that was rejected for a specific reason.
Zach Waldowski
z...@waldowski.me <mailto:z...@waldowski.me>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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
<https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
