[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
iferber at apple.com
Thu Mar 16 15:01:11 CDT 2017
Subscripts, by the way, would not help here, since they cannot throw.
`decode` must be able to throw.
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
> <swift-evolution at 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
>>> 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
>> zach at waldowski.me <mailto:zach at waldowski.me>
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution