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~%20%22subscript%20throw%22);
for Apple folks, 28775436.
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
<[email protected]> 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
[email protected] <mailto:[email protected]>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
