subject:"Re\: \[swift\-evolution\] \[Proposal\] Foundation Swift Archival \& Serialization"




On 17 Mar 2017, at 12:18, Michael Gottesman wrote:

On Mar 16, 2017, at 10:23 AM, Joe Groff via swift-evolution 
 wrote:




On Mar 16, 2017, at 10:21 AM, Itai Ferber  wrote:

On 15 Mar 2017, at 19:12, Joe Groff wrote:


On Mar 15, 2017, at 6:46 PM, Itai Ferber  wrote:

Thanks Joe, and thanks for passing this along!

To those who are curious, we use abstract base classes for a 
cascading list of reasons:


• We need to be able to represent keyed encoding and decoding 
containers as abstract types which are generic on a key type
• There are two ways to support abstraction in this way: protocol 
& type constraints, and generic types
• Since Swift protocols are not generic, we unfortunately cannot 
write protocol KeyedEncodingContainer { ... }, 
which is the "ideal" version of what we're trying to represent

• Let's try this with a protocol first (simplified here):

protocol Container {
associatedtype Key : CodingKey
}

func container(_ type: Key.Type) 
-> Cont where Cont.Key == Key {

// return something
}

This looks promising so far — let's try to make it concrete:

struct ConcreteContainer : Container {
typealias Key = K
}

func container(_ type: Key.Type) 
-> Cont where Cont.Key == Key {
return ConcreteContainer() // error: Cannot convert return 
expression of type 'ConcreteContainer' to return type 'Cont'

}

Joe or anyone from the Swift team can describe this better, but this 
is my poor-man's explanation of why this happens. Swift's type 
constraints are "directional" in a sense. You can constrain a type 
going into a function, but not out of a function. There is no type I 
could return from inside of container() which would satisfy this 
constraint, because the constraint can only be satisfied by turning 
Cont into a concrete type from the outside.


Okay, well let's try this:

func container... {
return ConcreteContainer() as! Cont
}

This compiles fine! Hmm, let's try to use it:

container(Int.self) // error: Generic parameter 'Cont' could not be 
inferred


The type constraint can only be fulfilled from the outside, not the 
inside. The function call itself has no context for the concrete 
type that this would return, so this is a no-go.


• If we can't do it with type constraints in this way, is it 
possible with generic types? Yep! Generic types satisfy this without 
a problem. However, since we don't have generic protocols, we have 
to use a generic abstract base class to represent the same concept 
— an abstract container generic on the type of key which 
dynamically dispatches to the "real" subclassed type


Hopes that gives some simplified insight into the nature of this 
decision.


I see. Protocols with associated types serve the same purpose as 
generic interfaces in other languages, but we don't have the 
first-class support for protocol types with associated type 
constraints (a value of type `Container where Key == K`). That's 
something we'd like to eventually support. In other places in the 
standard library, we wrtie the type-erased container by hand, which 
is why we have `AnySequence`, `AnyCollection`, and `AnyHashable`. 
You could probably do something similar here; that would be a bit 
awkward for implementers, but might be easier to migrate forward to 
where we eventually want to be with the language.


-Joe

Yep, that’s a good way to describe it.
We could potentially do that as well, but adding another type like 
AnyHashable or AnyCollection felt like a much more sweeping change, 
considering that those require some special compiler magic 
themselves (and we’d like to do as little of that as we can).


AnyCollection doesn't have any special compiler magic. AnyHashable's 
only magic is that it has implicit conversions, but that would become 
normal behavior once it can be replaced by a plain Hashable 
existential type.


Hey Itai. I am not sure if I missed this. But did you follow up with 
why you didn't want to use AnyCollection/AnyHashable? The thread got 
really long pretty fast.
I responded to this in a different part of the thread very recently. Can 
you elaborate on how a type like `AnyCollection`/`AnyHashable` would 
help here? More important than the type erasure is the type being 
generic on the key type, and this must be specified. How would this be 
possible?



Michael



-Joe
___
swift-evolution mailing list
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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization


Do you mean versions of the format, or versions of your type?

If the latter, this can be done on a case-by-case basis, as needed. You 
can always do something like


```swift
struct Foo : Codable {
// Name this as appropriate
private let jsonVersion = 1.1
}
```

and have it encode as well.

On 17 Mar 2017, at 11:51, T.J. Usiyan wrote:


Is there any sense of encoding versions (as in, changes to the JSON
representation, for instance?) I don't know that it is necessarily a 
good

idea overall but now is the time to consider it.

On Fri, Mar 17, 2017 at 2:27 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:



On Mar 17, 2017, at 1:15 PM, Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:

On 15 Mar 2017, at 22:58, Zach Waldowski wrote:

Another issue of scale - I had to switch to a native mail client as
replying inline severely broke my webmail client. ;-)

Again, lots of love here. Responses inline.

On Mar 15, 2017, at 6:40 PM, Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:
Proposed solution
We will be introducing the following new types:

protocol Codable: Adopted by types to opt into archival. Conformance 
may
be automatically derived in cases where all properties are also 
Codable.


FWIW I think this is acceptable compromise. If the happy path is 
derived
conformances, only-decodable or only-encodable types feel like a lazy 
way

out on the part of a user of the API, and builds a barrier to proper
testing.

[snip]

Structured types (i.e. types which encode as a collection of 
properties)

encode and decode their properties in a keyed manner. Keys may be
String-convertible or Int-convertible (or both), and user types which 
have

properties should declare semantic key enums which map keys to their
properties. Keys must conform to the CodingKey protocol:
public protocol CodingKey { <##snip##> }

A few things here:

The protocol leaves open the possibility of having both a String or 
Int
representation, or neither. What should a coder do in either case? 
Are the
representations intended to be mutually exclusive, or not? The 
protocol
design doesn’t seem particularly matching with the flavor of Swift; 
I’d

expect something along the lines of a CodingKey enum and the protocol
CodingKeyRepresentable. It’s also possible that the concerns of the 
two are

orthogonal enough that they deserve separate container(keyedBy:)
requirements.

The general answer to "what should a coder do" is "what is 
appropriate for
its format". For a format that uses exclusively string keys (like 
JSON),
the string representation (if present on a key) will always be used. 
If the
key has no string representation but does have an integer 
representation,
the encoder may choose to stringify the integer. If the key has 
neither, it

is appropriate for the Encoder to fail in some way.

On the flip side, for totally flat formats, an Encoder may choose to
ignore keys altogether, in which case it doesn’t really matter. The 
choice

is up to the Encoder and its format.

The string and integer representations are not meant to be mutually
exclusive at all, and in fact, where relevant, we encourage providing 
both

types of representations for flexibility.

As for the possibility of having neither representation, this 
question
comes up often. I’d like to summarize the thought process here by 
quoting
some earlier review (apologies for the poor formatting from my mail 
client):


If there are two options, each of which is itself optional, we have 4
possible combinations. But! At the same time we prohibit one 
combination by
what? Runtime error? Why not use a 3-case enum for it? Even further 
down
the rabbit whole there might be a CodingKey<> specialized for a 
concrete
combination, like CodingKey or just 
CodingKey,
but I’m not sure whether our type system will make it useful or 
possible…


public enum CodingKeyValue {
case integer(value: Int)
case string(value: String)
case both(intValue: Int, stringValue: String)
}
public protocol CodingKey {
init?(value: CodingKeyValue)
var value: CodingKeyValue { get }
}

I agree that this certainly feels suboptimal. We’ve certainly 
explored
other possibilities before sticking to this one, so let me try to 
summarize

here:

* Having a concrete 3-case CodingKey enum would preclude the 
possibility
of having neither a stringValue nor an intValue. However, there is a 
lot of

value in having the key types belong to the type being encoded (more
safety, impossible to accidentally mix key types, private keys, 
etc.); if
the CodingKey type itself is an enum (which cannot be inherited 
from), then

this prevents differing key types.
* Your solution as presented is better: CodingKey itself is still a
protocol, and the value itself is the 3-case enum. However, since
CodingKeyValue is not literal-representable, user keys cannot be 
enums
RawRepresentable by CodingKeyValue. That means that the values must 
either
be dynamically returned, or

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

On 16 Mar 2017, at 14:29, Matthew Johnson wrote:

This is a fantastic proposal! I am very much looking forward to
robust Swift-native encoding and decoding in Foundation. The compiler
synthesized conformances is especially great!I want to thank
everyone who worked on it. It is clear that a lot of work went into
the proposal.

The proposal covers a lot of ground so I’m breaking my comments up
by topic in the order the occur in the proposal.

Thanks for the feedback, Matthew! Responses inline.

Encode / Decode only types:

Brent raised the question of decode only types. Encode only types are
also not uncommon when an API accepts an argument payload that gets
serialized into the body of a request. The compiler synthesis feature
in the proposal makes providing both encoding and decoding easy in
common cases but this won’t always work as needed.

The obvious alternative is to have Decodable and Encodable protocols
which Codable refines. This would allow us to omit a conformance we
don’t need when it can’t be synthesized.
If conformances are still synthesized individually (i.e. for just
`Decodable` or just `Encodable`), it would be way too easy to
accidentally conform to one or the other and not realize that you’re
not conforming to `Codable`, since the synthesis is invisible. You’d
just be missing half of the protocol.

If the way out of this is to only synthesize conformance to `Codable`,
then it’s much harder to justify the inclusion of `Encodable` or
`Decodable` since those would require a manual implementation and would
much more rarely be used.

Your reply to Brent mentions using `fatalError` to avoid implementing
the direction that isn't needed. I think it would be better if the
conformance can reflect what is actually supported by the type.
Requiring us to write `fatalError` as a stub for functionality we
don’t need is a design problem IMO. I don’t think the extra
protocols are really that big a burden. They don’t add any new
functionality and are very easy to understand, especially considering
the symmetry they would have with the other types you are introducing.

Coding Keys:

As others have mentioned, the design of this protocol does not require
a value of a conforming type to actually be a valid key (it can return
nil for both `intValue` and `stringValue`). This seems problematic to
me.

In the reply to Brent again you mention throwing and
`preconditionFailure` as a way to handle incompatible keys. This also
seems problematic to me and feels like a design problem. If we really
need to support more than one underlying key type and some encoders
will reject some key types this information should be captured in the
type system. An encoder would only vend a keyed container for keys it
actually supports. Ideally the conformance of a type’s CodingKeys
could be leveraged to produce a compiler error if an attempt was made
to encode this type into an encoder that can’t support its keys. In
general, the idea is to produce static errors as close to the origin
of the programming mistake as possible.

I would very much prefer that we don’t defer to runtime assertions
or thrown errors, etc for conditions that could be caught statically
at compile time given the right design. Other comments have indicated
that static guarantees are important to the design (encoders *must*
guarantee support of primitives specified by the protocols, etc). Why
is a static guarantee of compatible coding keys considered less
important?
I agree that it would be nice to support this in a static way, but while
not impossible to represent in the type system, it absolutely explodes
the API into a ton of different types and protocols which are not
dissimilar. We’ve considered this in the past (see approach #4 in the
[Alternatives
Considered](https://github.com/itaiferber/swift-evolution/blob/637532e2abcbdb9861e424359bb6dac99dc6b638/proposals/-swift-archival-serialization.md#alternatives-considered)
section) and moved away from it for a reason.

To summarize:

* To statically represent the difference between an encoder which
supports string keys and one which supports integer keys, we would have
to introduce two different protocol types (say, `StringKeyEncoder` and
`IntKeyEncoder`)
* Now that there are two different encoder types, the `Codable` protocol
also needs to be split up into two — one version which encodes using a
`StringKeyEncoder` and one version which encodes using an
`IntKeyEncoder`. If you want to support encoding to an encoder which
supports both types of keys, we’d need a _third_ Codable protocol
which takes something that’s `StringKeyEncoder & IntKeyEncoder`
(because you cannot just conform to both `StringCodable` and
`IntCodable` — it’s ambiguous when given something that’s
`StringKeyEncoder & IntKeyEncoder`)
* On encoders which support both string and integer keys, you need
overloads for `encode(…)`, `encodeIntCodable>(…)`, and

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread Joe Groff via swift-evolution

> On Mar 16, 2017, at 12:33 PM, Itai Ferber via swift-evolution 
>  wrote:
> 
> This design struck me as remarkably similar to the reflection system and its 
> `Mirror` type, which is also a separate type describing an original instance. 
> My question was: Did you look at the reflection system when you were building 
> this design? Do you think there might be anything that can be usefully shared 
> between them?
> 
> We did, quite a bit, and spent a lot of time considering reflection and its 
> place in our design. Ultimately, the reflection system does not currently 
> have the features we would need, and although the Swift team has expressed 
> desire to improve the system considerably, it’s not currently a top priority, 
> AFAIK.
> 
> 

Although it isn't sufficient in its current form, I think the key paths 
proposal that recently went out will eventually be able to help a bit here:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html

If keypaths eventually had the ability to be looked up by name or index, like 
your coding keys are, we could potentially use them as the default coding key 
type instead of synthesizing a new type. That would cut down the number of 
compiler-known things. (I think it's reasonable for coding to do its own thing 
in the meantime, to be clear.)

-Joe___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread T.J. Usiyan via swift-evolution

Is there any sense of encoding versions (as in, changes to the JSON
representation, for instance?) I don't know that it is necessarily a good
idea overall but now is the time to consider it.

On Fri, Mar 17, 2017 at 2:27 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 17, 2017, at 1:15 PM, Itai Ferber via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 15 Mar 2017, at 22:58, Zach Waldowski wrote:
>
> Another issue of scale - I had to switch to a native mail client as
> replying inline severely broke my webmail client. ;-)
>
> Again, lots of love here. Responses inline.
>
> On Mar 15, 2017, at 6:40 PM, Itai Ferber via swift-evolution <
> swift-evolution@swift.org> wrote:
> Proposed solution
> We will be introducing the following new types:
>
> protocol Codable: Adopted by types to opt into archival. Conformance may
> be automatically derived in cases where all properties are also Codable.
>
> FWIW I think this is acceptable compromise. If the happy path is derived
> conformances, only-decodable or only-encodable types feel like a lazy way
> out on the part of a user of the API, and builds a barrier to proper
> testing.
>
> [snip]
>
> Structured types (i.e. types which encode as a collection of properties)
> encode and decode their properties in a keyed manner. Keys may be
> String-convertible or Int-convertible (or both), and user types which have
> properties should declare semantic key enums which map keys to their
> properties. Keys must conform to the CodingKey protocol:
> public protocol CodingKey { <##snip##> }
>
> A few things here:
>
> The protocol leaves open the possibility of having both a String or Int
> representation, or neither. What should a coder do in either case? Are the
> representations intended to be mutually exclusive, or not? The protocol
> design doesn’t seem particularly matching with the flavor of Swift; I’d
> expect something along the lines of a CodingKey enum and the protocol
> CodingKeyRepresentable. It’s also possible that the concerns of the two are
> orthogonal enough that they deserve separate container(keyedBy:)
> requirements.
>
> The general answer to "what should a coder do" is "what is appropriate for
> its format". For a format that uses exclusively string keys (like JSON),
> the string representation (if present on a key) will always be used. If the
> key has no string representation but does have an integer representation,
> the encoder may choose to stringify the integer. If the key has neither, it
> is appropriate for the Encoder to fail in some way.
>
> On the flip side, for totally flat formats, an Encoder may choose to
> ignore keys altogether, in which case it doesn’t really matter. The choice
> is up to the Encoder and its format.
>
> The string and integer representations are not meant to be mutually
> exclusive at all, and in fact, where relevant, we encourage providing both
> types of representations for flexibility.
>
> As for the possibility of having neither representation, this question
> comes up often. I’d like to summarize the thought process here by quoting
> some earlier review (apologies for the poor formatting from my mail client):
>
> If there are two options, each of which is itself optional, we have 4
> possible combinations. But! At the same time we prohibit one combination by
> what? Runtime error? Why not use a 3-case enum for it? Even further down
> the rabbit whole there might be a CodingKey<> specialized for a concrete
> combination, like CodingKey or just CodingKey,
> but I’m not sure whether our type system will make it useful or possible…
>
> public enum CodingKeyValue {
> case integer(value: Int)
> case string(value: String)
> case both(intValue: Int, stringValue: String)
> }
> public protocol CodingKey {
> init?(value: CodingKeyValue)
> var value: CodingKeyValue { get }
> }
>
> I agree that this certainly feels suboptimal. We’ve certainly explored
> other possibilities before sticking to this one, so let me try to summarize
> here:
>
> * Having a concrete 3-case CodingKey enum would preclude the possibility
> of having neither a stringValue nor an intValue. However, there is a lot of
> value in having the key types belong to the type being encoded (more
> safety, impossible to accidentally mix key types, private keys, etc.); if
> the CodingKey type itself is an enum (which cannot be inherited from), then
> this prevents differing key types.
> * Your solution as presented is better: CodingKey itself is still a
> protocol, and the value itself is the 3-case enum. However, since
> CodingKeyValue is not literal-representable, user keys cannot be enums
> RawRepresentable by CodingKeyValue. That means that the values must either
> be dynamically returned, or (for attaining the benefits that we want to
> give users — easy representation, autocompletion, etc.) the type has to be
> a struct with static lets on it giving the CodingKeyValues. This certainly
> works, but is likely not what

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread Matthew Johnson via swift-evolution


> On Mar 17, 2017, at 1:15 PM, Itai Ferber via swift-evolution 
>  wrote:
> 
> On 15 Mar 2017, at 22:58, Zach Waldowski wrote:
> 
> 
> Another issue of scale - I had to switch to a native mail client as replying 
> inline severely broke my webmail client. ;-)
> 
> Again, lots of love here. Responses inline.
> On Mar 15, 2017, at 6:40 PM, Itai Ferber via swift-evolution 
>  wrote:
> Proposed solution
> We will be introducing the following new types:
> 
> protocol Codable: Adopted by types to opt into archival. Conformance may be 
> automatically derived in cases where all properties are also Codable.
> 
> FWIW I think this is acceptable compromise. If the happy path is derived 
> conformances, only-decodable or only-encodable types feel like a lazy way out 
> on the part of a user of the API, and builds a barrier to proper testing.
> 
> [snip]
> 
> Structured types (i.e. types which encode as a collection of properties) 
> encode and decode their properties in a keyed manner. Keys may be 
> String-convertible or Int-convertible (or both), and user types which have 
> properties should declare semantic key enums which map keys to their 
> properties. Keys must conform to the CodingKey protocol:
> public protocol CodingKey { <##snip##> }
> 
> A few things here:
> 
> The protocol leaves open the possibility of having both a String or Int 
> representation, or neither. What should a coder do in either case? Are the 
> representations intended to be mutually exclusive, or not? The protocol 
> design doesn’t seem particularly matching with the flavor of Swift; I’d 
> expect something along the lines of a CodingKey enum and the protocol 
> CodingKeyRepresentable. It’s also possible that the concerns of the two are 
> orthogonal enough that they deserve separate container(keyedBy:) requirements.
> 
> The general answer to "what should a coder do" is "what is appropriate for 
> its format". For a format that uses exclusively string keys (like JSON), the 
> string representation (if present on a key) will always be used. If the key 
> has no string representation but does have an integer representation, the 
> encoder may choose to stringify the integer. If the key has neither, it is 
> appropriate for the Encoder to fail in some way.
> 
> On the flip side, for totally flat formats, an Encoder may choose to ignore 
> keys altogether, in which case it doesn’t really matter. The choice is up to 
> the Encoder and its format.
> 
> The string and integer representations are not meant to be mutually exclusive 
> at all, and in fact, where relevant, we encourage providing both types of 
> representations for flexibility.
> 
> As for the possibility of having neither representation, this question comes 
> up often. I’d like to summarize the thought process here by quoting some 
> earlier review (apologies for the poor formatting from my mail client):
> 
> 
> If there are two options, each of which is itself optional, we have 4 
> possible combinations. But! At the same time we prohibit one combination by 
> what? Runtime error? Why not use a 3-case enum for it? Even further down the 
> rabbit whole there might be a CodingKey<> specialized for a concrete 
> combination, like CodingKey or just CodingKey, 
> but I’m not sure whether our type system will make it useful or possible…
> 
> public enum CodingKeyValue {
> case integer(value: Int)
> case string(value: String)
> case both(intValue: Int, stringValue: String)
> }
> public protocol CodingKey {
> init?(value: CodingKeyValue)
> var value: CodingKeyValue { get }
> }
> 
> I agree that this certainly feels suboptimal. We’ve certainly explored other 
> possibilities before sticking to this one, so let me try to summarize here:
> 
> * Having a concrete 3-case CodingKey enum would preclude the possibility of 
> having neither a stringValue nor an intValue. However, there is a lot of 
> value in having the key types belong to the type being encoded (more safety, 
> impossible to accidentally mix key types, private keys, etc.); if the 
> CodingKey type itself is an enum (which cannot be inherited from), then this 
> prevents differing key types.
> * Your solution as presented is better: CodingKey itself is still a protocol, 
> and the value itself is the 3-case enum. However, since CodingKeyValue is not 
> literal-representable, user keys cannot be enums RawRepresentable by 
> CodingKeyValue. That means that the values must either be dynamically 
> returned, or (for attaining the benefits that we want to give users — easy 
> representation, autocompletion, etc.) the type has to be a struct with static 
> lets on it giving the CodingKeyValues. This certainly works, but is likely 
> not what a developer would have in mind when working with the API; the power 
> of enums in Swift makes them very easy to reach for, and I’m thinking most 
> users would expect their keys to be enums. We’d like to leverage that where 
> we can,

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization




On 15 Mar 2017, at 22:58, Zach Waldowski wrote:

Another issue of scale - I had to switch to a native mail client as 
replying inline severely broke my webmail client. ;-)


Again, lots of love here. Responses inline.

On Mar 15, 2017, at 6:40 PM, Itai Ferber via swift-evolution 
 wrote:

Proposed solution
We will be introducing the following new types:

protocol Codable: Adopted by types to opt into archival. Conformance 
may be automatically derived in cases where all properties are also 
Codable.
FWIW I think this is acceptable compromise. If the happy path is 
derived conformances, only-decodable or only-encodable types feel like 
a lazy way out on the part of a user of the API, and builds a barrier 
to proper testing.

[snip]

Structured types (i.e. types which encode as a collection of 
properties) encode and decode their properties in a keyed manner. 
Keys may be String-convertible or Int-convertible (or both), and user 
types which have properties should declare semantic key enums which 
map keys to their properties. Keys must conform to the CodingKey 
protocol:

public protocol CodingKey { <##snip##> }


A few things here:

The protocol leaves open the possibility of having both a String or 
Int representation, or neither. What should a coder do in either case? 
Are the representations intended to be mutually exclusive, or not? The 
protocol design doesn’t seem particularly matching with the flavor 
of Swift; I’d expect something along the lines of a CodingKey enum 
and the protocol CodingKeyRepresentable. It’s also possible that the 
concerns of the two are orthogonal enough that they deserve separate 
container(keyedBy:) requirements.
The general answer to "what should a coder do" is "what is appropriate 
for its format". For a format that uses exclusively string keys (like 
JSON), the string representation (if present on a key) will always be 
used. If the key has no string representation but does have an integer 
representation, the encoder may choose to stringify the integer. If the 
key has neither, it is appropriate for the `Encoder` to fail in some 
way.


On the flip side, for totally flat formats, an `Encoder` may choose to 
ignore keys altogether, in which case it doesn’t really matter. The 
choice is up to the `Encoder` and its format.


The string and integer representations are not meant to be mutually 
exclusive at all, and in fact, where relevant, we encourage providing 
both types of representations for flexibility.


As for the possibility of having neither representation, this question 
comes up often. I’d like to summarize the thought process here by 
quoting some earlier review (apologies for the poor formatting from my 
mail client):


If there are two options, each of which is itself optional, we have 4 
possible combinations. But! At the same time we prohibit one 
combination by what? Runtime error? Why not use a 3-case enum for it? 
Even further down the rabbit whole there might be a CodingKey<> 
specialized for a concrete combination, like 
CodingKey or just CodingKey, but I’m 
not sure whether our type system will make it useful or possible…


public enum CodingKeyValue {
  case integer(value: Int)
  case string(value: String)
  case both(intValue: Int, stringValue: String)
}
public protocol CodingKey {
  init?(value: CodingKeyValue)
  var value: CodingKeyValue { get }
}
I agree that this certainly feels suboptimal. We’ve certainly 
explored other possibilities before sticking to this one, so let me 
try to summarize here:


* Having a concrete 3-case CodingKey enum would preclude the 
possibility of having neither a stringValue nor an intValue. However, 
there is a lot of value in having the key types belong to the type 
being encoded (more safety, impossible to accidentally mix key types, 
private keys, etc.); if the CodingKey type itself is an enum (which 
cannot be inherited from), then this prevents differing key types.
* Your solution as presented is better: CodingKey itself is still a 
protocol, and the value itself is the 3-case enum. However, since 
CodingKeyValue is not literal-representable, user keys cannot be enums 
RawRepresentable by CodingKeyValue. That means that the values must 
either be dynamically returned, or (for attaining the benefits that we 
want to give users — easy representation, autocompletion, etc.) the 
type has to be a struct with static lets on it giving the 
CodingKeyValues. This certainly works, but is likely not what a 
developer would have in mind when working with the API; the power of 
enums in Swift makes them very easy to reach for, and I’m thinking 
most users would expect their keys to be enums. We’d like to 
leverage that where we can, especially since RawRepresentable enums 
are appropriate in the vast majority of use cases.
* Three separate CodingKey protocols (one for Strings, one for Ints, 
and one for both). You could argue that this is the most correct 
version, since it most clearly

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread Tony Parker via swift-evolution

Hi Matt,

> On Mar 17, 2017, at 6:39 AM, Matt Diephouse via swift-evolution 
>  wrote:
> 
> I have two related questions:
> 
>   1. Why was Swift 4 chosen as the target release for adding archival and 
> serialization?
> 
>   2. Given Swift compatibility requirements going forward, how much will the 
> design of these APIs be able to change?

I responded to this partially elsewhere in this thread, but the summary is: 
Swift developers are working with archiving and serialization right now and 
they deserve a better API that they can use as soon as possible. The language 
will always continue to evolve and improve.

> 
> The overall impression I get from the APIs is that they’ve been shaped by the 
> current limitations of Swift (a familiar constraint). There are a number of 
> likely future improvements that would likely significantly benefit this 
> proposal:
> 
>   1. Throwing subscripts, as mentioned here
> 
>   2. Improved generics, such that protocols could be used instead of abstract 
> base classes
> 
>   3. Improved type inference, as mentioned previously in the thread about 
> inferring return types
> 
>   4. Dynamism/reflection in whatever form Swift adds would be very closely 
> related, but more general, potentially influencing this design
> 
> Some of these could lead to improved, non-additive APIs. Will the archival 
> and serialization APIs be able to be updated in response to improvements like 
> these?

Yes, that is the plan. Our job during every release is to take a look at our 
APIs and implementations and make them better. Often times that means adjusting 
to new language features and other library features as they are released.

Another thing to remember is that library features can help drive language 
features. By releasing API like this, we are providing great motivation to pick 
what language features are most important going forward.

- Tony

> 
>> On Mar 16, 2017, at 5:12 PM, Itai Ferber via swift-evolution 
>> > wrote:
>> 
>> 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 >> > wrote:
>>> 
>>> Subscripts, by the way, would not help here, since they cannot throw. 
>>> decode must be able to throw.
>>> SR-238 
>>> ;
>>>  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 
 > 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread Tony Parker via swift-evolution

Hi Karl,

> On Mar 17, 2017, at 12:20 AM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 16 Mar 2017, at 21:48, Slava Pestov via swift-evolution 
>> > wrote:
>> 
>> Hi Itai,
>> 
>> I’m wondering what the motivation is for keeping this as part of Foundation 
>> and not the standard library. It seems like you’re landing an implementation 
>> of this in the Foundation overlay on master, and another copy of all the 
>> code will have to go into swift-corelibs-foundation. This seems suboptimal. 
>> Or are there future plans to unify the Foundation overlay with 
>> corelibs-foundation somehow?
>> 
>> Also the implementation uses some Foundation-isms (NSMutableArray, NSNumber) 
>> and it would be nice to stick with idiomatic Swift as much as possible 
>> instead.
>> 
>> Finally you should take a look at the integer protocol work 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>  
>> )
>>  to replace the repetitive code surrounding primitive types, however I don’t 
>> know if this has landed in master yet.
>> 
>> Slava
> 
> I agree that the protocols should be part of the standard library rather than 
> Foundation. As far as I can make out, the only part of this proposal that 
> actually requires Foundation is the use of the “Data” type (which itself is a 
> strange and often frustrating omission from the standard library). The actual 
> concrete encoders can live in Foundation.
> 
> Generally my opinion is that the proposed feature is nice. Everybody hates 
> NSCoder and having to write those required initialisers on your UIViews and 
> whatnot. At its core, it’s not really very different from any other Swift 
> archiving library which exists today, except that it’s backed with layer upon 
> layer of compiler-generated magic to make it less verbose. The things I don’t 
> like:
> 
> 1) While making things less verbose is commendable, automatically generating 
> the encoding functions could be an anti-feature. “Codable” is for properties 
> with persistable values only, which is a level of semantics which goes above 
> the type-system. We don’t generate Equatable conformance for structs whose 
> elements are all Equatable; it’s a big leap to go from “this data type is 
> persistable” to “the value of this variable should be persisted” - for one 
> thing, the value may not have meaning to others (e.g. a file-handle as an 
> Int32) or it may contain sensitive user-data in a String. The encoding 
> function isn’t just boilerplate - you *should* think about it; otherwise who 
> knows what kind of data you’re leaking?
> 
> => One possible solution would be to have “Codable" as a regular protocol, 
> and refine it with “AutoCodable" which contains the magic. Just so there is a 
> little extra step where you think “do I want this to be generated?”.

The number one complaint we have about NSCoding (and this complaint predates 
Swift by a long shot) is that too much boilerplate is required for really 
simple data structures. Resolving this issue is one of our primary goals for 
this API.

There are a lot of benefits to keeping one protocol in place instead of making 
another one for “auto” codable: API which accepts Codable things does not need 
to have two entry points; there is one concept of Codable instead of two; you 
can “buy in” to more complex behavior by implementing parts of Codable (e.g., 
just the keys if you simply want to change the names of the JSON keys).

> 
> 2) More generally, though, I don’t support the idea of the Foundation module 
> introducing extensions to the Swift language that no other developer of any 
> other module has the chance to do, with an aside that some reflection API 
> which doesn’t exist yet might possibly make it less magic in the future. My 
> jaw hit the floor when I saw this was part of the proposal, and that it 
> wasn’t for the standard library. Could you imagine, if somebody proposed 
> their own magic protocols for AlamoFire or Kitura or any other Swift library? 
> It would be a non-starter. It *should* be a non-starter.
> 
> => Do we have a policy about module-specific compiler magic such as this?
> => Can we move any of the magic (e.g. CodableKeys generation) to the standard 
> library?
> 
> I develop a lot for platforms, or for scenarios, where Foundation is not 
> supported nor desirable. Considering that people are taught to prefer library 
> code to rolling their own, and that humans are generally quite receptive to 
> shortcuts at the expense of correctness, if this machinery exists at all we 
> can expect it to spread. It would totally kill libraries such as SwiftJSON or 
> whatever else you currently use. The fact that such a fundamental and 
> widespread feature would now live in a monolithic module I can’t access would 
> significantly

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread Matt Diephouse via swift-evolution

I have two related questions:

  1. Why was Swift 4 chosen as the target release for adding archival and 
serialization?

  2. Given Swift compatibility requirements going forward, how much will the 
design of these APIs be able to change?

The overall impression I get from the APIs is that they’ve been shaped by the 
current limitations of Swift (a familiar constraint). There are a number of 
likely future improvements that would likely significantly benefit this 
proposal:

  1. Throwing subscripts, as mentioned here

  2. Improved generics, such that protocols could be used instead of abstract 
base classes

  3. Improved type inference, as mentioned previously in the thread about 
inferring return types

  4. Dynamism/reflection in whatever form Swift adds would be very closely 
related, but more general, potentially influencing this design

Some of these could lead to improved, non-additive APIs. Will the archival and 
serialization APIs be able to be updated in response to improvements like these?

> On Mar 16, 2017, at 5:12 PM, Itai Ferber via swift-evolution 
>  wrote:
> 
> 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 > > wrote:
>> 
>> Subscripts, by the way, would not help here, since they cannot throw. decode 
>> must be able to throw.
>> SR-238 
>> ;
>>  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 
>>> > 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 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> 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 
>>

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread David Hart via swift-evolution



> On 16 Mar 2017, at 22:36, Itai Ferber  wrote:
> 
> On 16 Mar 2017, at 13:27, David Hart wrote:
> 
> > On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution 
> >  wrote:
> 
> I’m going to reply to this thread as a whole — apologies if there’s someone’s 
> comment that I’ve missed.
> 
> This is something that has come up in internal review, and we’ve certainly 
> given it thought. As Zach has already mentioned, the primary concern with 
> overloading based on return type is ambiguity.
> There are many cases in which Swift’s type system currently does not handle 
> ambiguity in the way that you would expect, and it can be very surprising. 
> For instance,
> 
> func foo() -> Int { return 42 }
> func foo() -> Double { return .pi }
> func consumesInt(_ x : Int) { print(x) }
> 
> let x = foo() // Ambiguous use of foo()
> consumesInt(x) // Even though x is going to be used as an Int
> let y: Int = x // Same here
> let x = foo() as Int works now, but it actually didn’t always — until a 
> somewhat recent version of Swift AFAICT, the only way to resolve the 
> ambiguity was through let x: Int = foo(). This has since been fixed, but it 
> was very confusing to try to figure out the unambiguous way to call it.
> 
> Keep in mind that this isn’t an unreasonable thing to want to do:
> 
> struct Foo {
> var x: Int
> init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> 
> // Want to process an element before it’s assigned.
> let x = container.decode(forKey: .x) // Ambiguous call
> 
> // Or whatever.
> if x < 0 {
> self.x = x + 100
> else {
> self.x = x * 200
> }
> }
> }
> You can write let x: Int = container.decode(…) or let x = container.decode(…) 
> as Int, but this isn’t always intuitive.
> That’s where I disagree. Let me try to prove my point:
> 
> You bring up the example of having to store the decoded value in a variable 
> before setting it to a typed property. But its also not unreasonable to want 
> to do the same thing when encoding the value, possibly storing it into a 
> different type. If we follow that argument, its also not very intuitive to 
> have to do
> 
> container.encode(x as Double, forKey: .x).
> 
> Wouldn’t that be an argument to have an API like this:
> 
> func encode(_ value: Data?, forKey key: Key, as type: T.Type) throws
> 
> I don’t agree that these are equivalent cases.
> 
> Here, for an as cast to be valid, the type of x must be an existential (I’m 
> guessing Any).
> The original container.encode(x, forKey: .x) call is not ambiguous because x 
> has no type, but rather because the type of x does not match any of the 
> overloads. You would get the same error as if you wrote
> 
> struct NonCodableFoo {}
> let x = NonCodableFoo()
> container.encode(x, forKey: .x)
> You have to convert the type to something that fits one of the overloads.
> 
Yes, sorry, I wasn't thinking straight.
> On encode, there cannot be any true ambiguity because it’s not possible to 
> satisfy more than one of these concrete overloads. You cannot have a thing 
> with a type which would satisfy both, say, Int and Double.
> 
> I would argue that type inference is a core feature in Swift and that we 
> should embrace it. I believe that in most cases the return value of encode 
> will be stored into a typed property and type inference will do the right 
> thing. In the few cases where the type has to be enforced, the patterns you 
> mention above are not weird syntax; they are used and useful all over Swift:
> 
> Sure, but I think these cases are not equivalent.
> 
> let cgFloat: CGFloat = 42
> 
> 42 has a default value of Int, but since CGFloat is ExpressibleByIntLiteral, 
> this becomes the equivalent of writing let cfFloat = CGFloat(42), which would 
> not be ambiguous without the CGFloat(); you would just get an Int.
> 
> With let x = container.decode(forKey: .x), has has no type unless otherwise 
> specified.
> 
> let pi = 3.14159265359 as Float
> 
> Same here, but with Double instead of Int, and Float instead of CGFloat…
> 
> let person = factory.get() // potential feature in Generics Manifesto
> 
> This isn’t type inference. This is type specification, which is exactly what 
> we are trying to do. At the moment, explicit type specification has a 
> different syntax: passing a metatype as an argument.
> 
> If this feature were available, this is what we would use.
> 
> The way I think about it is that the type argument is already there as a 
> generic parameter. Adding an extra argument that needs to be explicitly given 
> on every single call feels like unneeded verbosity to me.
> 
> For consideration: why does let person = factory.get() seem 
> reasonable, but let person = factory.get(Person.self) does not?
> 
I'm sorry, I was just very bad at expressing myself.  Let me try again:

I'm not against type specialization: I think I'm just against the meta type 
argument variant (which is all we currently have

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-17 Thread Karl Wagner via swift-evolution

> On 16 Mar 2017, at 21:48, Slava Pestov via swift-evolution 
>  wrote:
> 
> Hi Itai,
> 
> I’m wondering what the motivation is for keeping this as part of Foundation 
> and not the standard library. It seems like you’re landing an implementation 
> of this in the Foundation overlay on master, and another copy of all the code 
> will have to go into swift-corelibs-foundation. This seems suboptimal. Or are 
> there future plans to unify the Foundation overlay with corelibs-foundation 
> somehow?
> 
> Also the implementation uses some Foundation-isms (NSMutableArray, NSNumber) 
> and it would be nice to stick with idiomatic Swift as much as possible 
> instead.
> 
> Finally you should take a look at the integer protocol work 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>  
> )
>  to replace the repetitive code surrounding primitive types, however I don’t 
> know if this has landed in master yet.
> 
> Slava

I agree that the protocols should be part of the standard library rather than 
Foundation. As far as I can make out, the only part of this proposal that 
actually requires Foundation is the use of the “Data” type (which itself is a 
strange and often frustrating omission from the standard library). The actual 
concrete encoders can live in Foundation.

Generally my opinion is that the proposed feature is nice. Everybody hates 
NSCoder and having to write those required initialisers on your UIViews and 
whatnot. At its core, it’s not really very different from any other Swift 
archiving library which exists today, except that it’s backed with layer upon 
layer of compiler-generated magic to make it less verbose. The things I don’t 
like:

1) While making things less verbose is commendable, automatically generating 
the encoding functions could be an anti-feature. “Codable” is for properties 
with persistable values only, which is a level of semantics which goes above 
the type-system. We don’t generate Equatable conformance for structs whose 
elements are all Equatable; it’s a big leap to go from “this data type is 
persistable” to “the value of this variable should be persisted” - for one 
thing, the value may not have meaning to others (e.g. a file-handle as an 
Int32) or it may contain sensitive user-data in a String. The encoding function 
isn’t just boilerplate - you *should* think about it; otherwise who knows what 
kind of data you’re leaking?

=> One possible solution would be to have “Codable" as a regular protocol, and 
refine it with “AutoCodable" which contains the magic. Just so there is a 
little extra step where you think “do I want this to be generated?”.

2) More generally, though, I don’t support the idea of the Foundation module 
introducing extensions to the Swift language that no other developer of any 
other module has the chance to do, with an aside that some reflection API which 
doesn’t exist yet might possibly make it less magic in the future. My jaw hit 
the floor when I saw this was part of the proposal, and that it wasn’t for the 
standard library. Could you imagine, if somebody proposed their own magic 
protocols for AlamoFire or Kitura or any other Swift library? It would be a 
non-starter. It *should* be a non-starter.

=> Do we have a policy about module-specific compiler magic such as this?
=> Can we move any of the magic (e.g. CodableKeys generation) to the standard 
library?

I develop a lot for platforms, or for scenarios, where Foundation is not 
supported nor desirable. Considering that people are taught to prefer library 
code to rolling their own, and that humans are generally quite receptive to 
shortcuts at the expense of correctness, if this machinery exists at all we can 
expect it to spread. It would totally kill libraries such as SwiftJSON or 
whatever else you currently use. The fact that such a fundamental and 
widespread feature would now live in a monolithic module I can’t access would 
significantly spoil the language for me.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Slava Pestov via swift-evolution

> On Mar 16, 2017, at 4:00 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Mar 16, 2017, at 5:54 PM, Ben Rimmington  wrote:
>> 
>> 
 On 16 Mar 2017, at 21:14, Matthew Johnson wrote:

 On Mar 16, 2017, at 4:12 PM, Itai Ferber  wrote:

 If throwing subscripts made it in the Swift 4 timeframe, then we would 
 certainly consider it.
>>> 
>>> Cool.  Any comment from the core team on whether this is a possibility?  If 
>>> it is and nobody else wants to write a proposal I would be willing to do it.
>> 
>> "Throwing Properties and Subscripts" proposal by Brent Royal-Gordon (12 
>> months ago):
>> 
>> 
> 
> Oh, great!  I had forgotten about this.  It would be awesome if we could 
> revive this for Swift 4 especially so it can be considered as part of the 
> interface of this API.  Even if Foundation doesn't adopt the, they would be a 
> great complement for those of us who would prefer the lighter syntax and are 
> willing to use our own wrapper.

I think the limiting factor here is not reviewing the proposal, but 
implementing it. If someone comes up with a prototype implementation it would 
increase the odds of the proposal being accepted.

A big part of this would just be untangling a pile of code in SILGen for 
emitting function call arguments and applying them. Right now there’s too much 
duplication between method calls and property access and subscripts. I need to 
do some work in this area to implement default arguments for subscripts; I 
think this can be accomplished through some refactoring and deleting of code. I 
haven’t thought about throwing properties and subscripts but I imagine it would 
be similar.

Slava

> 
>> 
>> -- Ben
>> 
> 
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution

Sent from my iPad

> On Mar 16, 2017, at 5:54 PM, Ben Rimmington  wrote:
> 
> 
>>> On 16 Mar 2017, at 21:14, Matthew Johnson wrote:
>>> 
>>> On Mar 16, 2017, at 4:12 PM, Itai Ferber  wrote:
>>> 
>>> If throwing subscripts made it in the Swift 4 timeframe, then we would 
>>> certainly consider it.
>> 
>> Cool.  Any comment from the core team on whether this is a possibility?  If 
>> it is and nobody else wants to write a proposal I would be willing to do it.
> 
> "Throwing Properties and Subscripts" proposal by Brent Royal-Gordon (12 
> months ago):
> 
> 

Oh, great!  I had forgotten about this.  It would be awesome if we could revive 
this for Swift 4 especially so it can be considered as part of the interface of 
this API.  Even if Foundation doesn't adopt the, they would be a great 
complement for those of us who would prefer the lighter syntax and are willing 
to use our own wrapper.

> 
> -- Ben
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Ben Rimmington via swift-evolution


> On 16 Mar 2017, at 21:14, Matthew Johnson wrote:
> 
>> On Mar 16, 2017, at 4:12 PM, Itai Ferber  wrote:
>> 
>> If throwing subscripts made it in the Swift 4 timeframe, then we would 
>> certainly consider it.
> 
> Cool.  Any comment from the core team on whether this is a possibility?  If 
> it is and nobody else wants to write a proposal I would be willing to do it.

"Throwing Properties and Subscripts" proposal by Brent Royal-Gordon (12 months 
ago):



-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization




On 16 Mar 2017, at 13:27, David Hart wrote:

> On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution 
 wrote:


I’m going to reply to this thread as a whole — apologies if 
there’s someone’s comment that I’ve missed.


This is something that has come up in internal review, and we’ve 
certainly given it thought. As Zach has already mentioned, the 
primary concern with overloading based on return type is ambiguity.
There are many cases in which Swift’s type system currently does 
not handle ambiguity in the way that you would expect, and it can be 
very surprising. For instance,


func foo() -> Int { return 42 }
func foo() -> Double { return .pi }
func consumesInt(_ x : Int) { print(x) }

let x = foo() // Ambiguous use of foo()
consumesInt(x) // Even though x is going to be used as an Int
let y: Int = x // Same here
let x = foo() as Int works now, but it actually didn’t always — 
until a somewhat recent version of Swift AFAICT, the only way to 
resolve the ambiguity was through let x: Int = foo(). This has since 
been fixed, but it was very confusing to try to figure out the 
unambiguous way to call it.


Keep in mind that this isn’t an unreasonable thing to want to do:

struct Foo {
var x: Int
init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: 
CodingKeys.self)


// Want to process an element before it’s assigned.
let x = container.decode(forKey: .x) // Ambiguous call

// Or whatever.
if x < 0 {
self.x = x + 100
else {
self.x = x * 200
}
}
}
You can write let x: Int = container.decode(…) or let x = 
container.decode(…) as Int, but this isn’t always intuitive.



That’s where I disagree. Let me try to prove my point:

You bring up the example of having to store the decoded value in a 
variable before setting it to a typed property. But its also not 
unreasonable to want to do the same thing when encoding the value, 
possibly storing it into a different type. If we follow that argument, 
its also not very intuitive to have to do


container.encode(x as Double, forKey: .x).

Wouldn’t that be an argument to have an API like this:

func encode(_ value: Data?, forKey key: Key, as type: T.Type) 
throws

I don’t agree that these are equivalent cases.

Here, for an `as` cast to be valid, the type of `x` must be an 
existential (I’m guessing `Any`).
The original `container.encode(x, forKey: .x)` call is not ambiguous 
because `x` has no type, but rather because the type of `x` does not 
match any of the overloads. You would get the same error as if you wrote


```swift
struct NonCodableFoo {}
let x = NonCodableFoo()
container.encode(x, forKey: .x)
```

You have to convert the type to something that fits one of the 
overloads.


On encode, there cannot be any true ambiguity because it’s not 
possible to satisfy more than one of these concrete overloads. You 
cannot have a thing with a type which would satisfy both, say, `Int` and 
`Double`.


I would argue that type inference is a core feature in Swift and that 
we should embrace it. I believe that in most cases the return value of 
encode will be stored into a typed property and type inference will do 
the right thing. In the few cases where the type has to be enforced, 
the patterns you mention above are not weird syntax; they are used and 
useful all over Swift:

Sure, but I think these cases are not equivalent.


let cgFloat: CGFloat = 42
42 has a default value of `Int`, but since `CGFloat` is 
`ExpressibleByIntLiteral`, this becomes the equivalent of writing `let 
cfFloat = CGFloat(42)`, which would not be ambiguous without the 
`CGFloat()`; you would just get an `Int`.


With `let x = container.decode(forKey: .x)`, has _has no type_ unless 
otherwise specified.



let pi = 3.14159265359 as Float
Same here, but with `Double` instead of `Int`, and `Float` instead of 
`CGFloat`…


let person = factory.get() // potential feature in Generics 
Manifesto
This isn’t type inference. This is type specification, which is 
exactly what we are trying to do. At the moment, explicit type 
specification has a different syntax: passing a metatype as an argument.


If this feature were available, this is what we would use.

The way I think about it is that the type argument is already there as 
a generic parameter. Adding an extra argument that needs to be 
explicitly given on every single call feels like unneeded verbosity to 
me.
For consideration: why does `let person = factory.get()` seem 
reasonable, but `let person = factory.get(Person.self)` does not?


Consider also that the metatype would also be necessary for 
decode(_ type: Value.Type, forKey: Key) -> Value 
because the return value of that certainly could be ambiguous in many 
cases.


Finally, the metatype arg allows you to express the following 
succinctly: let v: SuperClass = container.decode(SubClass.self, 
forKey: .v).


In the general case (decode) we

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution

This is a fantastic proposal!  I am very much looking forward to robust 
Swift-native encoding and decoding in Foundation.  The compiler synthesized 
conformances is especially great!I want to thank everyone who worked on it. 
 It is clear that a lot of work went into the proposal.

The proposal covers a lot of ground so I’m breaking my comments up by topic in 
the order the occur in the proposal.

Encode / Decode only types:

Brent raised the question of decode only types.  Encode only types are also not 
uncommon when an API accepts an argument payload that gets serialized into the 
body of a request. The compiler synthesis feature in the proposal makes 
providing both encoding and decoding easy in common cases but this won’t always 
work as needed.

The obvious alternative is to have Decodable and Encodable protocols which 
Codable refines.  This would allow us to omit a conformance we don’t need when 
it can’t be synthesized.  

Your reply to Brent mentions using `fatalError` to avoid implementing the 
direction that isn't needed.  I think it would be better if the conformance can 
reflect what is actually supported by the type.  Requiring us to write 
`fatalError` as a stub for functionality we don’t need is a design problem IMO. 
 I don’t think the extra protocols are really that big a burden.  They don’t 
add any new functionality and are very easy to understand, especially 
considering the symmetry they would have with the other types you are 
introducing.

Coding Keys:

As others have mentioned, the design of this protocol does not require a value 
of a conforming type to actually be a valid key (it can return nil for both 
`intValue` and `stringValue`).  This seems problematic to me.

In the reply to Brent again you mention throwing and `preconditionFailure` as a 
way to handle incompatible keys.  This also seems problematic to me and feels 
like a design problem. If we really need to support more than one underlying 
key type and some encoders will reject some key types this information should 
be captured in the type system.  An encoder would only vend a keyed container 
for keys it actually supports.  Ideally the conformance of a type’s CodingKeys 
could be leveraged to produce a compiler error if an attempt was made to encode 
this type into an encoder that can’t support its keys.  In general, the idea is 
to produce static errors as close to the origin of the programming mistake as 
possible.  

I would very much prefer that we don’t defer to runtime assertions or thrown 
errors, etc for conditions that could be caught statically at compile time 
given the right design.  Other comments have indicated that static guarantees 
are important to the design (encoders *must* guarantee support of primitives 
specified by the protocols, etc).  Why is a static guarantee of compatible 
coding keys considered less important?

Keyed Containers:

Joe posted raised the topic of the alternative of using manual type erasure for 
the keyed containers rather than abstract classes.  Did you explore this 
direction at all?  It feels like a more natural approach for Swift and as Joe 
noted, it can be designed in such a way that eases migration to existentials in 
the future if that is the “ideal” design (which you mentioned in your response).

Decoding Containers:

returns: A value of the requested type, if present for the given key and 
convertible to the requested type.

Can you elaborate on the details of “convertible to the requested type” means?  
It think this is an important detail for the proposal.  

For example, I would expect numeric values to attempt conversion using the 
SE-0080 failable numeric conversion initializers (decoding JSON was a primary 
motivating use case for that proposal).  If the requested type conforms to 
RawRepresentable and the encoded value can be converted to RawValue (perhaps 
using a failable numeric initializer) I would expect the raw value initializer 
to be used to attempt conversion.  If Swift ever gained a standard mechanism 
for generalized value conversion I would also expect that to be used if a 
conversion is available from the encoded type to the requested type.

If either of those conversions fail I would expect something like an “invalid 
value” error or a “conversion failure” error rather than a “type mismatch” 
error.  The types don’t exactly mismatch, we just have a failable conversion 
process that did not succeed.

Context:

I’m glad Brent raised the topic of supporting multiple formats.  In his example 
the difference was remote and local formats.  I’ve also seen cases where the 
same API requires the same model to be encoded differently in different 
endpoints.  This is awful, but it also happens sometimes in the wild.  
Supporting an application specified encoding context would be very useful for 
handling these situations (the `codingKeyContex` would not always be sufficient 
and would usually not be a good way to determine the required encoding or

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution

> On Mar 16, 2017, at 4:18 PM, Philippe Hausler  wrote:
> 
> One point of concern with making the implementations rely on that: it would 
> require any adopter of Codable to be built in swift 4 mode no? it might be 
> valuable to keep the protocol not requiring Swift 4 to aide in incremental 
> migration.

Yes, probably so.  I would be disappointed if we allowed the design of Swift 4 
features to be influenced by Swift 3.1 compatibility.

> 
>> On Mar 16, 2017, at 2:14 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 16, 2017, at 4:12 PM, Itai Ferber >> > wrote:
>>> 
>>> If throwing subscripts made it in the Swift 4 timeframe, then we would 
>>> certainly consider it.
>>> 
>> Cool.  Any comment from the core team on whether this is a possibility?  If 
>> it is and nobody else wants to write a proposal I would be willing to do it.
>>> On 16 Mar 2017, at 13:19, Matthew Johnson wrote:
>>> 
>>> 
 On Mar 16, 2017, at 3:01 PM, Itai Ferber > wrote:

 Subscripts, by the way, would not help here, since they cannot throw. 
 decode must be able to throw.
 SR-238 
 ;
  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 
> > 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 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> 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 

>>> 
>> 
>>

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Philippe Hausler via swift-evolution

One point of concern with making the implementations rely on that: it would 
require any adopter of Codable to be built in swift 4 mode no? it might be 
valuable to keep the protocol not requiring Swift 4 to aide in incremental 
migration.

> On Mar 16, 2017, at 2:14 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Mar 16, 2017, at 4:12 PM, Itai Ferber > > wrote:
>> 
>> If throwing subscripts made it in the Swift 4 timeframe, then we would 
>> certainly consider it.
>> 
> Cool.  Any comment from the core team on whether this is a possibility?  If 
> it is and nobody else wants to write a proposal I would be willing to do it.
>> On 16 Mar 2017, at 13:19, Matthew Johnson wrote:
>> 
>> 
>>> On Mar 16, 2017, at 3:01 PM, Itai Ferber >> > wrote:
>>> 
>>> Subscripts, by the way, would not help here, since they cannot throw. 
>>> decode must be able to throw.
>>> SR-238 
>>> ;
>>>  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 
 > 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 
 
 
 
 
 ___
 swift-evolution mailing list
 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 
>>> 
>> 
> 
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution


> On Mar 16, 2017, at 4:12 PM, Itai Ferber  wrote:
> 
> If throwing subscripts made it in the Swift 4 timeframe, then we would 
> certainly consider it.
> 
Cool.  Any comment from the core team on whether this is a possibility?  If it 
is and nobody else wants to write a proposal I would be willing to do it.
> On 16 Mar 2017, at 13:19, Matthew Johnson wrote:
> 
> 
>> On Mar 16, 2017, at 3:01 PM, Itai Ferber > > wrote:
>> 
>> Subscripts, by the way, would not help here, since they cannot throw. decode 
>> must be able to throw.
>> SR-238 
>> ;
>>  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 
>>> > 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 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> 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 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

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  wrote:

Subscripts, by the way, would not help here, since they cannot throw. 
decode must be able to throw.
SR-238 
; 
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 
> 
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 

___
swift-evolution mailing list
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 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization


Hi Slava,

Thanks for your comments!

On 16 Mar 2017, at 13:50, Slava Pestov wrote:


Hi Itai,

I’m wondering what the motivation is for keeping this as part of 
Foundation and not the standard library. It seems like you’re 
landing an implementation of this in the Foundation overlay on master, 
and another copy of all the code will have to go into 
swift-corelibs-foundation. This seems suboptimal. Or are there future 
plans to unify the Foundation overlay with corelibs-foundation 
somehow?
This has to be part of Foundation because `Data`, a Foundation type, is 
one of the primitive types of serialization. This will be doubly true if 
we decide to add `Date` as another primitive type.


I agree that this is suboptimal at the moment, but we will work to find 
a way to keep the work in sync in a reasonable manner.


Also the implementation uses some Foundation-isms (NSMutableArray, 
NSNumber) and it would be nice to stick with idiomatic Swift as much 
as possible instead.

Using the Foundation framework is just as idiomatic in Swift… ;)
In this specific case, we need collections with reference semantics 
(`NSMutableArray` and `NSMutableDictionary`) and a concrete type-erased 
number box (`NSNumber`); theres’s no reason to reinvent the wheel if 
we already have exactly the tools we need.


The reference implementation at the moment goes through 
`JSONSerialization`, which affects the specifics of its implementation. 
This may change in the future.


Finally you should take a look at the integer protocol work 
(https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md 
) 
to replace the repetitive code surrounding primitive types, however I 
don’t know if this has landed in master yet.
As mentioned in other emails, the list of primitive types was carefully 
chosen because we need to have a concrete list of types which consumers 
can rely on being supported, and that `Encoder`s and `Decoder`s know 
they _must_ support.


Specifically:

1. For binary formats, the difference between an `Int16` and an `Int64` 
is significant. The `Encoder` would need to know that it’s received 
one type or another, not just a `FixedWidthInteger`; this would involve 
a runtime check of the concrete type of the argument
2. Any type can conform to these protocols — nothing is preventing me 
from writing an `Int37` type conforming to `FixedWidthInteger` and 
passing it in. Most encoders would really not know what to do with this 
type (especially ones with binary formats), but the failure would be a 
runtime one instead of a static one
  * A concrete example of this is the `FloatingPoint` protocol. 
`Float80` conforms to the protocol, but no common binary format I’ve 
seen supports 80-bit floating-point values. We’d prefer to prevent 
that statically by accepting only `Float` and `Double`
3. Consumers of the API then have no guarantees that a specific 
`Encoder` supports the type that they need. Did the encoder remember to 
support `UInt64` values? Similarly, `Encoder`s and `Decoder`s don’t 
know what types they need to be considering. Am I supposed to handle 
`UInt8` differently from `Int16`? With a list of concrete types, this 
becomes immediately clear — both consumers and writers of `Encoder`s 
have a clear contract.




Slava



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Tony Parker via swift-evolution

Hi Slava,

> On Mar 16, 2017, at 1:50 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Hi Itai,
> 
> I’m wondering what the motivation is for keeping this as part of Foundation 
> and not the standard library. It seems like you’re landing an implementation 
> of this in the Foundation overlay on master, and another copy of all the code 
> will have to go into swift-corelibs-foundation. This seems suboptimal. Or are 
> there future plans to unify the Foundation overlay with corelibs-foundation 
> somehow?

I would like some unification in the future, but they are currently two 
separate implementations for a bunch of reasons (lack of bridging on Linux 
being a huge one, along with the inability of the standard library and runtime 
to distinguish between presence of Objective-C and the presence of Foundation).

> 
> Also the implementation uses some Foundation-isms (NSMutableArray, NSNumber) 
> and it would be nice to stick with idiomatic Swift as much as possible 
> instead.
> 

The implementation you’re looking at is for JSONArchiver, which is based on 
NSJSONSerialization, which is part of Foundation and not the standard library. 
That’s a primary reason to use Foundation. NSJSONSerialization also deals with 
types like ‘Date’ which are in Foundation. Finally, the primitive Coding API 
uses Data, which is a Foundation type.

So in summary, I’m fine with this API being part of Foundation. Foundation is 
available the same places the standard library is, so it is more than 
acceptable to use Foundation API and types here.

- Tony

> Finally you should take a look at the integer protocol work 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>  
> )
>  to replace the repetitive code surrounding primitive types, however I don’t 
> know if this has landed in master yet.
> 
> Slava
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution


> On Mar 16, 2017, at 3:27 PM, David Hart  wrote:
> 
> 
>> On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution 
>> > wrote:
>> 
>> I’m going to reply to this thread as a whole — apologies if there’s 
>> someone’s comment that I’ve missed.
>> 
>> This is something that has come up in internal review, and we’ve certainly 
>> given it thought. As Zach has already mentioned, the primary concern with 
>> overloading based on return type is ambiguity.
>> There are many cases in which Swift’s type system currently does not handle 
>> ambiguity in the way that you would expect, and it can be very surprising. 
>> For instance,
>> 
>> func foo() -> Int { return 42 }
>> func foo() -> Double { return .pi }
>> func consumesInt(_ x : Int) { print(x) }
>> 
>> let x = foo() // Ambiguous use of foo()
>> consumesInt(x) // Even though x is going to be used as an Int
>> let y: Int = x // Same here
>> let x = foo() as Int works now, but it actually didn’t always — until a 
>> somewhat recent version of Swift AFAICT, the only way to resolve the 
>> ambiguity was through let x: Int = foo(). This has since been fixed, but it 
>> was very confusing to try to figure out the unambiguous way to call it.
>> 
>> Keep in mind that this isn’t an unreasonable thing to want to do:
>> 
>> struct Foo {
>> var x: Int
>> init(from decoder: Decoder) throws {
>> let container = try decoder.container(keyedBy: CodingKeys.self)
>> 
>> // Want to process an element before it’s assigned.
>> let x = container.decode(forKey: .x) // Ambiguous call
>> 
>> // Or whatever.
>> if x < 0 {
>> self.x = x + 100
>> else {
>> self.x = x * 200
>> }
>> }
>> }
>> You can write let x: Int = container.decode(…) or let x = 
>> container.decode(…) as Int, but this isn’t always intuitive.
>> 
> That’s where I disagree. Let me try to prove my point:
> 
> You bring up the example of having to store the decoded value in a variable 
> before setting it to a typed property. But its also not unreasonable to want 
> to do the same thing when encoding the value, possibly storing it into a 
> different type. If we follow that argument, its also not very intuitive to 
> have to do
> 
> container.encode(x as Double, forKey: .x).
> 
> Wouldn’t that be an argument to have an API like this:
> 
> func encode(_ value: Data?, forKey key: Key, as type: T.Type) throws
> 
> I would argue that type inference is a core feature in Swift and that we 
> should embrace it. I believe that in most cases the return value of encode 
> will be stored into a typed property and type inference will do the right 
> thing. In the few cases where the type has to be enforced, the patterns you 
> mention above are not weird syntax; they are used and useful all over Swift:
> 
> let cgFloat: CGFloat = 42
> let pi = 3.14159265359 as Float
> let person = factory.get() // potential feature in Generics Manifesto
> 
> The way I think about it is that the type argument is already there as a 
> generic parameter. Adding an extra argument that needs to be explicitly given 
> on every single call feels like unneeded verbosity to me.

I agree with everything David says here.

>> Consider also that the metatype would also be necessary for decode> Codable>(_ type: Value.Type, forKey: Key) -> Value because the return value 
>> of that certainly could be ambiguous in many cases.
>> 
>> Finally, the metatype arg allows you to express the following succinctly: 
>> let v: SuperClass = container.decode(SubClass.self, forKey: .v).
>> 
>> In the general case (decode) we would need the metatype to 
>> avoid ambiguity. It’s not strictly necessary for primitive types, but helps 
>> in the case of ambiguity, and solves the conceptual overhead of "Why do I 
>> specify the type sometimes but not others? Why are some of these types 
>> special? Should I always provide the type? Why wouldn’t I?"
>> 
>> Matthew offered func decode(_ key: Key, as type: T.Type = T.self) throws 
>> -> T which looks appealing, but:
>> 
>> Doesn’t help resolve the ambiguity either
>> Allows for 3 ways of expressing the same thing (let x: Int = decode(key), 
>> let x = decode(key) as Int, and let x = decode(key, as: Int.self))
>> The cognitive overhead of figuring out all of the ambiguity goes away when 
>> we’re consistent everywhere.
>> FWIW, too, I am not convinced that Foundation should add API just because 
>> 3rd parties will add it.
>> 
> Agreed. Foundation should not add API just because 3rd parties do it. But 3rd 
> parties should not be dismissed entirely nonetheless. They are a good 
> breeding ground for ideas to spawn and shape Swift in interesting ways.

+1.  The point is not that we should do everything 3rd parties do.  But we 
should also not leave a gap in Foundation where the community has identified a 
lighter syntactic approach that has been used successfully in

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Slava Pestov via swift-evolution

Hi Itai,

I’m wondering what the motivation is for keeping this as part of Foundation and 
not the standard library. It seems like you’re landing an implementation of 
this in the Foundation overlay on master, and another copy of all the code will 
have to go into swift-corelibs-foundation. This seems suboptimal. Or are there 
future plans to unify the Foundation overlay with corelibs-foundation somehow?

Also the implementation uses some Foundation-isms (NSMutableArray, NSNumber) 
and it would be nice to stick with idiomatic Swift as much as possible instead.

Finally you should take a look at the integer protocol work 
(https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
 
)
 to replace the repetitive code surrounding primitive types, however I don’t 
know if this has landed in master yet.

Slava___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution


> On Mar 16, 2017, at 3:27 PM, Tony Parker  wrote:
> 
> 
>> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution 
 > 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.
>>> 
>>> Two arguments:
>>> 
>>> 1) Most of the time, you will be setting the return value of decode into a 
>>> typed property and will not need ‘as’.
>>> 2) Even when you do need it, its not tricky syntax: it’s the official way 
>>> to direct the type inference engine in Swift.
>> 
>> +1 to both of David’s points.  Needing to explicitly resolve ambiguity 
>> during decoding is pretty rare.  When necessary the syntax is perfectly 
>> reasonable.  Swift users who don’t understand single statement inference 
>> works and how to guide the inference engine should learn about these topics 
>> sooner or later.  It won’t be a hard topic to search if a user runs into 
>> trouble either.  
>> 
>> Nevertheless, if the Foundation team is strongly opposed to this many of us 
>> will just write our own wrappers.  This isn’t hard but it makes Swift code 
>> less consistent throughout the community.  Supporting consistent usage 
>> throughout the community seems like a reasonable goal to me.  IMO that means 
>> not leaving obvious expressivity gaps that are easy to fill.  In this case, 
>> there is a very good reason why we prefer subscripts and return type 
>> inference.  It makes our code much more clear by omitting a bunch of 
>> needless and noisy words (which is one of the principles of the API Design 
>> Guidelines).
>> 
> 
> Hi Matthew,
> 
> While fully acknowledging that the proposed API adds some “wordiness", I 
> would also like to point out that the Swift API guidelines also explicitly 
> state a goal to avoid overloading on return type:
> 
> "Lastly, avoid “overloading on return type” because it causes ambiguities in 
> the presence of type inference.”

Fair enough.  I think that’s *usually* a great guideline.  However, in this 
specific use case I strongly support return type inference as a design that 
increases clarity while ambiguity is very rare in practice.  In any case, it 
sounds like the Foundation team has a pretty firm opinion on this topic.  I’ve 
offered my two cents and will let it drop now. :)

> 
> - Tony
> 
>>> David.
>>> 
> 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?
 
 Zach Waldowski
 z...@waldowski.me 
 
 
 
 
 ___
 swift-evolution mailing list
 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 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization


> On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution 
>  wrote:
> 
> I’m going to reply to this thread as a whole — apologies if there’s someone’s 
> comment that I’ve missed.
> 
> This is something that has come up in internal review, and we’ve certainly 
> given it thought. As Zach has already mentioned, the primary concern with 
> overloading based on return type is ambiguity.
> There are many cases in which Swift’s type system currently does not handle 
> ambiguity in the way that you would expect, and it can be very surprising. 
> For instance,
> 
> func foo() -> Int { return 42 }
> func foo() -> Double { return .pi }
> func consumesInt(_ x : Int) { print(x) }
> 
> let x = foo() // Ambiguous use of foo()
> consumesInt(x) // Even though x is going to be used as an Int
> let y: Int = x // Same here
> let x = foo() as Int works now, but it actually didn’t always — until a 
> somewhat recent version of Swift AFAICT, the only way to resolve the 
> ambiguity was through let x: Int = foo(). This has since been fixed, but it 
> was very confusing to try to figure out the unambiguous way to call it.
> 
> Keep in mind that this isn’t an unreasonable thing to want to do:
> 
> struct Foo {
> var x: Int
> init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> 
> // Want to process an element before it’s assigned.
> let x = container.decode(forKey: .x) // Ambiguous call
> 
> // Or whatever.
> if x < 0 {
> self.x = x + 100
> else {
> self.x = x * 200
> }
> }
> }
> You can write let x: Int = container.decode(…) or let x = container.decode(…) 
> as Int, but this isn’t always intuitive.
> 
That’s where I disagree. Let me try to prove my point:

You bring up the example of having to store the decoded value in a variable 
before setting it to a typed property. But its also not unreasonable to want to 
do the same thing when encoding the value, possibly storing it into a different 
type. If we follow that argument, its also not very intuitive to have to do

container.encode(x as Double, forKey: .x).

Wouldn’t that be an argument to have an API like this:

func encode(_ value: Data?, forKey key: Key, as type: T.Type) throws

I would argue that type inference is a core feature in Swift and that we should 
embrace it. I believe that in most cases the return value of encode will be 
stored into a typed property and type inference will do the right thing. In the 
few cases where the type has to be enforced, the patterns you mention above are 
not weird syntax; they are used and useful all over Swift:

let cgFloat: CGFloat = 42
let pi = 3.14159265359 as Float
let person = factory.get() // potential feature in Generics Manifesto

The way I think about it is that the type argument is already there as a 
generic parameter. Adding an extra argument that needs to be explicitly given 
on every single call feels like unneeded verbosity to me.
> Consider also that the metatype would also be necessary for decode Codable>(_ type: Value.Type, forKey: Key) -> Value because the return value 
> of that certainly could be ambiguous in many cases.
> 
> Finally, the metatype arg allows you to express the following succinctly: let 
> v: SuperClass = container.decode(SubClass.self, forKey: .v).
> 
> In the general case (decode) we would need the metatype to 
> avoid ambiguity. It’s not strictly necessary for primitive types, but helps 
> in the case of ambiguity, and solves the conceptual overhead of "Why do I 
> specify the type sometimes but not others? Why are some of these types 
> special? Should I always provide the type? Why wouldn’t I?"
> 
> Matthew offered func decode(_ key: Key, as type: T.Type = T.self) throws 
> -> T which looks appealing, but:
> 
> Doesn’t help resolve the ambiguity either
> Allows for 3 ways of expressing the same thing (let x: Int = decode(key), let 
> x = decode(key) as Int, and let x = decode(key, as: Int.self))
> The cognitive overhead of figuring out all of the ambiguity goes away when 
> we’re consistent everywhere.
> FWIW, too, I am not convinced that Foundation should add API just because 3rd 
> parties will add it.
> 
Agreed. Foundation should not add API just because 3rd parties do it. But 3rd 
parties should not be dismissed entirely nonetheless. They are a good breeding 
ground for ideas to spawn and shape Swift in interesting ways.
> The ambiguity in the general case cannot be solved by wrappers, and I would 
> prefer to provide one simple, consistent solution; if 3rd parties would like 
> to add wrappers for their own sake, then I certainly encourage that.
> 
> 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 
>> > wrote:
>> 
>> On Thu, Mar 16, 2017, at 02:23 PM, Matthew

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Tony Parker via swift-evolution


> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution 
>>> > 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.
>> 
>> Two arguments:
>> 
>> 1) Most of the time, you will be setting the return value of decode into a 
>> typed property and will not need ‘as’.
>> 2) Even when you do need it, its not tricky syntax: it’s the official way to 
>> direct the type inference engine in Swift.
> 
> +1 to both of David’s points.  Needing to explicitly resolve ambiguity during 
> decoding is pretty rare.  When necessary the syntax is perfectly reasonable.  
> Swift users who don’t understand single statement inference works and how to 
> guide the inference engine should learn about these topics sooner or later.  
> It won’t be a hard topic to search if a user runs into trouble either.  
> 
> Nevertheless, if the Foundation team is strongly opposed to this many of us 
> will just write our own wrappers.  This isn’t hard but it makes Swift code 
> less consistent throughout the community.  Supporting consistent usage 
> throughout the community seems like a reasonable goal to me.  IMO that means 
> not leaving obvious expressivity gaps that are easy to fill.  In this case, 
> there is a very good reason why we prefer subscripts and return type 
> inference.  It makes our code much more clear by omitting a bunch of needless 
> and noisy words (which is one of the principles of the API Design Guidelines).
> 

Hi Matthew,

While fully acknowledging that the proposed API adds some “wordiness", I would 
also like to point out that the Swift API guidelines also explicitly state a 
goal to avoid overloading on return type:

"Lastly, avoid “overloading on return type” because it causes ambiguities in 
the presence of type inference.”

- Tony

>> David.
>> 
 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?
>>> 
>>> Zach Waldowski
>>> z...@waldowski.me 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> 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
> 
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution


> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution 
>> > 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.
> 
> Two arguments:
> 
> 1) Most of the time, you will be setting the return value of decode into a 
> typed property and will not need ‘as’.
> 2) Even when you do need it, its not tricky syntax: it’s the official way to 
> direct the type inference engine in Swift.

+1 to both of David’s points.  Needing to explicitly resolve ambiguity during 
decoding is pretty rare.  When necessary the syntax is perfectly reasonable.  
Swift users who don’t understand single statement inference works and how to 
guide the inference engine should learn about these topics sooner or later.  It 
won’t be a hard topic to search if a user runs into trouble either.  

Nevertheless, if the Foundation team is strongly opposed to this many of us 
will just write our own wrappers.  This isn’t hard but it makes Swift code less 
consistent throughout the community.  Supporting consistent usage throughout 
the community seems like a reasonable goal to me.  IMO that means not leaving 
obvious expressivity gaps that are easy to fill.  In this case, there is a very 
good reason why we prefer subscripts and return type inference.  It makes our 
code much more clear by omitting a bunch of needless and noisy words (which is 
one of the principles of the API Design Guidelines).

> 
> David.
> 
>>> 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?
>> 
>> Zach Waldowski
>> z...@waldowski.me 
>> 
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution


> On Mar 16, 2017, at 3:01 PM, Itai Ferber  wrote:
> 
> Subscripts, by the way, would not help here, since they cannot throw. decode 
> must be able to throw.
> SR-238 
> ;
>  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 
>> > 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 
>> 
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> 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 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization


Thanks for the comments, David.
I responded to #2 in a separate email, but wanted to get back to 
responding to #1.


In implementing this, I have had the same thoughts. Ideally, one day, we 
would be able to migrate the implementation of this away from the 
compiler to public API (through reflection, property behaviors, or 
similar). If the compiler offers external features that would allow us 
to do everything that we want, I would be more than happy to move the 
implementation from inside the compiler to outside of it.


On 16 Mar 2017, at 0:09, David Hart wrote:


First of all, great proposal :D

Brent, earlier in the thread makes a lot of good points. But I’d 
still like to discuss two subjects:


1) What makes the proposal really stand on its feet compared to 
third-party libraries is the compiler generation magic. I feel divided 
about it. On one hand, this is the only solution today to have this 
level of type and key safety. But on another hand, I have the 
impression that future versions of Swift (with more reflection, 
property behaviours, lenses, etc…) would dramatically affect how 
this subject is treated and implemented. Are you worried that we are 
asking the compiler to do work which might be un-necessary in the 
future? That this topic would be better expressed with more powerful 
language features? Any plans to migrate for this API to smoothly 
migrate to those features in the future?


2) Libraries like Marshal (https://github.com/utahiosmac/Marshal 
) and Unbox 
(https://github.com/JohnSundell/Unbox 
) don’t require the decoding 
functions to provide the type: those functions are generic on the 
return turn and it’s automatically inferred:


func decode(key: Key) -> T

self.stringProperty = decode(key: .stringProperty) // correct 
specialisation of the generic function chosen by the compiler


Is there a reason the proposal did not choose this solution? Its quite 
sweet.



Swift Archival & Serialization
Proposal: SE- 
Author(s): Itai Ferber , Michael LeHew 
, Tony Parker 

Review Manager: TBD
Status: Awaiting review
Associated PRs:
#8124 
#8125 



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

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 
 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 




___
swift-evolution mailing list
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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization


> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution 
>  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.

Two arguments:

1) Most of the time, you will be setting the return value of decode into a 
typed property and will not need ‘as’.
2) Even when you do need it, its not tricky syntax: it’s the official way to 
direct the type inference engine in Swift.

David.

>> 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?
> 
> Zach Waldowski
> z...@waldowski.me 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

I’m going to reply to this thread as a whole — apologies if 
there’s someone’s comment that I’ve missed.


This is something that has come up in internal review, and we’ve 
certainly given it thought. As Zach has already mentioned, the primary 
concern with overloading based on return type is ambiguity.
There are many cases in which Swift’s type system currently does not 
handle ambiguity in the way that you would expect, and it can be very 
surprising. For instance,


```swift
func foo() -> Int { return 42 }
func foo() -> Double { return .pi }
func consumesInt(_ x : Int) { print(x) }

let x = foo() // Ambiguous use of foo()
consumesInt(x) // Even though x is going to be used as an Int
let y: Int = x // Same here
```

`let x = foo() as Int` works now, but it actually didn’t always — 
until a somewhat recent version of Swift AFAICT, the only way to resolve 
the ambiguity was through `let x: Int = foo()`. This has since been 
fixed, but it was very confusing to try to figure out the unambiguous 
way to call it.


Keep in mind that this isn’t an unreasonable thing to want to do:

```swift
struct Foo {
var x: Int
init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)

// Want to process an element before it’s assigned.
let x = container.decode(forKey: .x) // Ambiguous call

// Or whatever.
if x < 0 {
self.x = x + 100
else {
self.x = x * 200
}
}
}
```

You can write `let x: Int = container.decode(…)` or `let x = 
container.decode(…) as Int`, but this isn’t always intuitive.
Consider also that the metatype would also be necessary for 
`decode(_ type: Value.Type, forKey: Key) -> Value` 
because the return value of that certainly could be ambiguous in many 
cases.


Finally, the metatype arg allows you to express the following 
succinctly: `let v: SuperClass = container.decode(SubClass.self, forKey: 
.v)`.


In the general case (`decode`) we would need the 
metatype to avoid ambiguity. It’s not strictly necessary for primitive 
types, but helps in the case of ambiguity, and solves the conceptual 
overhead of "Why do I specify the type sometimes but not others? Why are 
some of these types special? Should I always provide the type? Why 
wouldn’t I?"


Matthew offered `func decode(_ key: Key, as type: T.Type = T.self) 
throws -> T` which looks appealing, but:


1. Doesn’t help resolve the ambiguity either
2. Allows for 3 ways of expressing the same thing (`let x: Int = 
decode(key)`, `let x = decode(key) as Int`, and `let x = decode(key, as: 
Int.self)`)


The cognitive overhead of figuring out all of the ambiguity goes away 
when we’re consistent everywhere.
FWIW, too, I am not convinced that Foundation should add API just 
because 3rd parties will add it. The ambiguity in the general case 
cannot be solved by wrappers, and I would prefer to provide one simple, 
consistent solution; if 3rd parties would like to add wrappers for their 
own sake, then I certainly encourage that.


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 
 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization


Thanks for the thorough and detailed review, Brent! Responses inline.

On 15 Mar 2017, at 21:19, Brent Royal-Gordon wrote:

On Mar 15, 2017, at 3:40 PM, Itai Ferber via swift-evolution 
 wrote:


Hi everyone,

The following introduces a new Swift-focused archival and 
serialization API as part of the Foundation framework. We’re 
interested in improving the experience and safety of performing 
archival and serialization, and are happy to receive community 
feedback on this work.


Thanks to all of the people who've worked on this. It's a great 
proposal.



Specifically:

	• It aims to provide a solution for the archival of Swift struct 
and enum types


I see a lot of discussion here of structs and classes, and an example 
of an enum without associated values, but I don't see any discussion 
of enums with associated values. Can you sketch how you see people 
encoding such types?


For example, I assume that `Optional` is going to get some special 
treatment, but if it doesn't, how would you write its `encode(to:)` 
method?
`Optional` values are accepted and vended directly through the API. The 
`encode(_:forKey:)` methods take optional values directly, and 
`decodeIfPresent(_:forKey:)` vend optional values.


`Optional` is special in this way — it’s a primitive part of the 
system. It’s actually not possible to write an `encode(to:)` method 
for `Optional`, since the representation of null values is up to the 
encoder and the format it’s working in; `JSONEncoder`, for instance, 
decides on the representation of `nil` (JSON `null`). It wouldn’t be 
possible to ask `nil` to encode itself in a reasonable way.


What about a more complex enum, like the standard library's 
`UnicodeDecodingResult`:


enum UnicodeDecodingResult {
case emptyInput
case error
case scalarValue(UnicodeScalar)
}

Or, say, an `Error`-conforming type from one of my projects:

public enum SQLError: Error {
case connectionFailed(underlying: Error)
case executionFailed(underlying: Error, statement: SQLStatement)
case noRecordsFound(statement: SQLStatement)
case extraRecordsFound(statement: SQLStatement)
	case columnInvalid(underlying: Error, key: ColumnSpecifier, 
statement: SQLStatement)
	case valueInvalid(underlying: Error, key: AnySQLColumnKey, 
statement: SQLStatement)

}

(You can assume that all the types in the associated values are 
`Codable`.)
Sure — these cases specifically do not derive `Codable` conformance 
because the specific representation to choose is up to you. Two possible 
ways to write this, though there are many others (I’m simplifying 
these cases here a bit, but you can extrapolate this):


```swift
// Approach 1
// This produces either {"type": 0} for `.noValue`, or {"type": 1, 
"value": …} for `.associated`.

public enum EnumWithAssociatedValue : Codable {
case noValue
case associated(Int)

private enum CodingKeys : CodingKey {
case type
case value
}

public init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
let type = try container.decode(Int.self, forKey: .type)
switch type {
case 0:
self = .noValue
case 1:
let value = try container.decode(Int.self, forKey: .value)
self = .associated(value)
default:
throw …
}
}

public func encode(to encoder: Encoder) throws {
let container = encoder.container(keyedBy: codingKeys.self)
switch self {
case .noValue:
try container.encode(0, forKey: .type)
case .associated(let value):
try container.encode(1, forKey: .type)
try container.encode(value, forKey: .value)
}
}
}

// Approach 2
// Produces `0`, `1`, or `2` for `.noValue1`, `.noValue2`, and 
`.noValue3` respectively.
// Produces {"type": 3, "value": …} and {"type": 4, "value": …} for 
`.associated1` and `.associated2`.

public enum EnumWithAssociatedValue : Codable {
case noValue1
case noValue2
case noValue3
case associated1(Int)
case associated2(String)

private enum CodingKeys : CodingKey {
case type
case value
}

public init(from decoder: Decoder) throws {
if let container = try? decoder.singleValueContainer() {}
let type = container.decode(Int.self)
switch type {
case 0: self = .noValue1
case 1: self = .noValue2
case 2: self = .noValue3
default: throw …
}
} else {
let container = try decoder.container(keyedBy: 
CodingKeys.self)

let type = container.decode(Int.self, forKey: .type)
switch type {
case 3:
let value = container.decode(Int.self, forKey: .value)
self =

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution

> On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution 
>  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 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Zach Waldowski via swift-evolution

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.

> 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?

Zach Waldowski

z...@waldowski.me

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Matthew Johnson via swift-evolution

> On Mar 16, 2017, at 1:06 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> On 16 Mar 2017, at 16:53, Zach Waldowski  > wrote:
> 
>>> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal 
>>> ) and Unbox 
>>> (https://github.com/JohnSundell/Unbox 
>>> ) don’t require the decoding 
>>> functions to provide the type: those functions are generic on the return 
>>> turn and it’s automatically inferred:
>>> 
>>> func decode(key: Key) -> T
>>> 
>>> self.stringProperty = decode(key: .stringProperty) // correct 
>>> specialisation of the generic function chosen by the compiler
>>> 
>>> Is there a reason the proposal did not choose this solution? Its quite 
>>> sweet.
>> 
>> IMHO those are only “sweet” until you need to decode a value out to 
>> something other than a typed value, then it’s ambiguity city.
> 
> Other than a typed value? Can you give an example?

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

We can also use the type argument but provide a default value:

func decode(_ key: Key, as type: T.Type = T.self) throws -> T

let i = decode(key: .myKey, as: Int.self)

I think the Foundation team should strongly consider one of these signatures 
and allow us to rely on return type inference when desired.  If this isn’t 
provided by Foundation we’ll see a bunch of wrappers that do this.  Why not 
include it in the standard interface?  

The same argument can be made for providing a subscript instead of or in 
addition to `decode`.  Of course exposing a proper subscript interface isn’t 
possible until we have throwing subscripts.  Decoding is one of the major 
motivating use cases for throwing subscripts.  With Foundation tackling this 
topic in Swift 4 maybe it would be good to consider bringing throwing 
subscripts in scope and using them in the interface to KeyedDecodingContainer.  

Subscript with return type inference is the natural interface for a keyed 
decoder (obviously IMO).  If we don’t support this in Foundation we will 
continue to see 3rd party libraries that do this.  I think it would be better 
to provide the same interface and implementation to everyone directly in 
Foundation itself.

> 
>> There are many ways to solve that, but none of them are conducive to 
>> beginners. Using the metatype to seed the generic resolution is the only 
>> thing I’d get behind, personally.
>> 
>> Zach Waldowski
>> z...@waldowski.me 
>> 
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization


> On 16 Mar 2017, at 16:53, Zach Waldowski  wrote:
> 
>> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal) and Unbox 
>> (https://github.com/JohnSundell/Unbox) don’t require the decoding functions 
>> to provide the type: those functions are generic on the return turn and it’s 
>> automatically inferred:
>> 
>> func decode(key: Key) -> T
>> 
>> self.stringProperty = decode(key: .stringProperty) // correct specialisation 
>> of the generic function chosen by the compiler
>> 
>> Is there a reason the proposal did not choose this solution? Its quite sweet.
> 
> IMHO those are only “sweet” until you need to decode a value out to something 
> other than a typed value, then it’s ambiguity city.

Other than a typed value? Can you give an example?

> There are many ways to solve that, but none of them are conducive to 
> beginners. Using the metatype to seed the generic resolution is the only 
> thing I’d get behind, personally.
> 
> Zach Waldowski
> z...@waldowski.me
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Joe Groff via swift-evolution


> On Mar 16, 2017, at 10:21 AM, Itai Ferber  wrote:
> 
> On 15 Mar 2017, at 19:12, Joe Groff wrote:
> 
> 
> On Mar 15, 2017, at 6:46 PM, Itai Ferber  wrote:
> 
> Thanks Joe, and thanks for passing this along!
> 
> To those who are curious, we use abstract base classes for a cascading list 
> of reasons:
> 
> • We need to be able to represent keyed encoding and decoding containers as 
> abstract types which are generic on a key type
> • There are two ways to support abstraction in this way: protocol & type 
> constraints, and generic types
> • Since Swift protocols are not generic, we unfortunately cannot write 
> protocol KeyedEncodingContainer { ... }, which is the 
> "ideal" version of what we're trying to represent
> • Let's try this with a protocol first (simplified here):
> 
> protocol Container {
> associatedtype Key : CodingKey
> }
> 
> func container(_ type: Key.Type) -> Cont 
> where Cont.Key == Key {
> // return something
> }
> 
> This looks promising so far — let's try to make it concrete:
> 
> struct ConcreteContainer : Container {
> typealias Key = K
> }
> 
> func container(_ type: Key.Type) -> Cont 
> where Cont.Key == Key {
> return ConcreteContainer() // error: Cannot convert return expression of 
> type 'ConcreteContainer' to return type 'Cont'
> }
> 
> Joe or anyone from the Swift team can describe this better, but this is my 
> poor-man's explanation of why this happens. Swift's type constraints are 
> "directional" in a sense. You can constrain a type going into a function, but 
> not out of a function. There is no type I could return from inside of 
> container() which would satisfy this constraint, because the constraint can 
> only be satisfied by turning Cont into a concrete type from the outside.
> 
> Okay, well let's try this:
> 
> func container... {
> return ConcreteContainer() as! Cont
> }
> 
> This compiles fine! Hmm, let's try to use it:
> 
> container(Int.self) // error: Generic parameter 'Cont' could not be inferred
> 
> The type constraint can only be fulfilled from the outside, not the inside. 
> The function call itself has no context for the concrete type that this would 
> return, so this is a no-go.
> 
> • If we can't do it with type constraints in this way, is it possible with 
> generic types? Yep! Generic types satisfy this without a problem. However, 
> since we don't have generic protocols, we have to use a generic abstract base 
> class to represent the same concept — an abstract container generic on the 
> type of key which dynamically dispatches to the "real" subclassed type
> 
> Hopes that gives some simplified insight into the nature of this decision.
> 
> I see. Protocols with associated types serve the same purpose as generic 
> interfaces in other languages, but we don't have the first-class support for 
> protocol types with associated type constraints (a value of type `Container 
> where Key == K`). That's something we'd like to eventually support. In other 
> places in the standard library, we wrtie the type-erased container by hand, 
> which is why we have `AnySequence`, `AnyCollection`, and `AnyHashable`. You 
> could probably do something similar here; that would be a bit awkward for 
> implementers, but might be easier to migrate forward to where we eventually 
> want to be with the language.
> 
> -Joe
> 
> Yep, that’s a good way to describe it.
> We could potentially do that as well, but adding another type like 
> AnyHashable or AnyCollection felt like a much more sweeping change, 
> considering that those require some special compiler magic themselves (and 
> we’d like to do as little of that as we can).

AnyCollection doesn't have any special compiler magic. AnyHashable's only magic 
is that it has implicit conversions, but that would become normal behavior once 
it can be replaced by a plain Hashable existential type.

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization




On 15 Mar 2017, at 19:12, Joe Groff wrote:


On Mar 15, 2017, at 6:46 PM, Itai Ferber  wrote:

Thanks Joe, and thanks for passing this along!

To those who are curious, we use abstract base classes for a 
cascading list of reasons:


	• We need to be able to represent keyed encoding and decoding 
containers as abstract types which are generic on a key type
	• There are two ways to support abstraction in this way: protocol 
& type constraints, and generic types
		• Since Swift protocols are not generic, we unfortunately cannot 
write protocol KeyedEncodingContainer { ... }, which 
is the "ideal" version of what we're trying to represent

• Let's try this with a protocol first (simplified here):

protocol Container {
associatedtype Key : CodingKey
}

func container(_ type: Key.Type) 
-> Cont where Cont.Key == Key {

// return something
}

This looks promising so far — let's try to make it concrete:

struct ConcreteContainer : Container {
typealias Key = K
}

func container(_ type: Key.Type) 
-> Cont where Cont.Key == Key {
return ConcreteContainer() // error: Cannot convert return 
expression of type 'ConcreteContainer' to return type 'Cont'

}

Joe or anyone from the Swift team can describe this better, but this 
is my poor-man's explanation of why this happens. Swift's type 
constraints are "directional" in a sense. You can constrain a type 
going into a function, but not out of a function. There is no type I 
could return from inside of container() which would satisfy this 
constraint, because the constraint can only be satisfied by turning 
Cont into a concrete type from the outside.


Okay, well let's try this:

func container... {
return ConcreteContainer() as! Cont
}

This compiles fine! Hmm, let's try to use it:

container(Int.self) // error: Generic parameter 'Cont' could not be 
inferred


The type constraint can only be fulfilled from the outside, not the 
inside. The function call itself has no context for the concrete type 
that this would return, so this is a no-go.


	• If we can't do it with type constraints in this way, is it 
possible with generic types? Yep! Generic types satisfy this without 
a problem. However, since we don't have generic protocols, we have to 
use a generic abstract base class to represent the same concept — 
an abstract container generic on the type of key which dynamically 
dispatches to the "real" subclassed type


Hopes that gives some simplified insight into the nature of this 
decision.


I see. Protocols with associated types serve the same purpose as 
generic interfaces in other languages, but we don't have the 
first-class support for protocol types with associated type 
constraints (a value of type `Container where Key == K`). That's 
something we'd like to eventually support. In other places in the 
standard library, we wrtie the type-erased container by hand, which is 
why we have `AnySequence`, `AnyCollection`, and `AnyHashable`. You 
could probably do something similar here; that would be a bit awkward 
for implementers, but might be easier to migrate forward to where we 
eventually want to be with the language.


-Joe

Yep, that’s a good way to describe it.
We could potentially do that as well, but adding another type like 
`AnyHashable` or `AnyCollection` felt like a much more sweeping change, 
considering that those require some special compiler magic themselves 
(and we’d like to do as little of that as we can).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Zach Waldowski via swift-evolution

> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution 
>  wrote:
> 
> 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal 
> ) and Unbox 
> (https://github.com/JohnSundell/Unbox ) 
> don’t require the decoding functions to provide the type: those functions are 
> generic on the return turn and it’s automatically inferred:
> 
> func decode(key: Key) -> T
> 
> self.stringProperty = decode(key: .stringProperty) // correct specialisation 
> of the generic function chosen by the compiler
> 
> Is there a reason the proposal did not choose this solution? Its quite sweet.

IMHO those are only “sweet” until you need to decode a value out to something 
other than a typed value, then it’s ambiguity city. There are many ways to 
solve that, but none of them are conducive to beginners. Using the metatype to 
seed the generic resolution is the only thing I’d get behind, personally.

Zach Waldowski
z...@waldowski.me

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

2017-03-16 Thread Vincent Esche via swift-evolution

On Thu, Mar 16, 2017 at 1:45 AM, Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> Holy cow. There's much to digest here (so much so that my initial
> response, which quoted its content, was denied by the mailing list). After
> an initial reading, I don't just want this now, I want it yesterday. I'm
> already imaging the encoder/decoders I want to build. Very exciting.
>

+1 on this (having skimmed through it briefly)!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization