Re: [swift-evolution] JSONEncoder: Key strategies

[Alejandro Martinez via swift-evolution]

Yeha the API surface is a good concern. I was wondering if it would make sense 
to be part of String for example instead of tying it to the encoders api. I 
guess add that point it will be a different discussion.
In any case, good proposal ;)

Sent from my iPad

> On 7 Nov 2017, at 00:35, Tony Parker  wrote:
> 
> Hi Alejandro,
> 
>> On Nov 6, 2017, at 3:14 PM, Alejandro Martinez via swift-evolution 
>>  wrote:
>> 
>> I’m in favor of this as it’s really, but specially the custom strategy. And 
>> thinking about that, would there be a way to expose the functionality of 
>> converting a string to camel case or snake case so it could be used in case 
>> of writing a custom strategy. Would be cool to have the original 
>> functionality when writings a custom strategy instead of having to 
>> reimplement it if there is a need.
>> 
>> Sent from my iPad
> 
> We talked about this a bit, and while there are some clever things that are 
> possible, ultimately we felt it made the API too complex. I think we have 
> room to provide the functionality on the enum later if we want (e.g. a 
> function you could call).
> 
> - Tony
> 
>> 
>>> On 6 Nov 2017, at 20:54, Tony Parker via swift-evolution 
>>>  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> While we have no formal process at this time for proposals of changes to 
>>> Foundation-only code, I would still like to post one that we have run 
>>> through our internal process here for additional public comment.
>>> 
>>> Link to PR with proposal content:
>>> 
>>> https://github.com/apple/swift-corelibs-foundation/pull/1301
>>> 
>>> Link to implementation for the overlay:
>>> 
>>> https://github.com/apple/swift/pull/12779
>>> 
>>> Markdown follows.
>>> 
>>> Thanks,
>>> - Tony
>>> 
>>> # Key Strategies for JSONEncoder and JSONDecoder
>>> 
>>> * Proposal: SCLF-0001
>>> * Author(s): Tony Parker 
>>> 
>>> # Related radars or Swift bugs
>>> 
>>> *  Snake case / Camel case conversions for 
>>> JSONEncoder/Decoder
>>> 
>>> # Revision history
>>> 
>>> * **v1** Initial version
>>> 
>>> ## Introduction
>>> 
>>> While early feedback for `JSONEncoder` and `JSONDecoder` has been very 
>>> positive, many developers have told us that they would appreciate a 
>>> convenience for converting between `snake_case_keys` and `camelCaseKeys` 
>>> without having to manually specify the key values for all types.
>>> 
>>> ## Proposed solution
>>> 
>>> `JSONEncoder` and `JSONDecoder` will gain new strategy properties to allow 
>>> for conversion of keys during encoding and decoding.
>>> 
>>> ```swift
>>> class JSONDecoder {
>>> /// The strategy to use for automatically changing the value of keys 
>>> before decoding.
>>> public enum KeyDecodingStrategy {
>>> /// Use the keys specified by each type. This is the default 
>>> strategy.
>>> case useDefaultKeys
>>> 
>>> /// Convert from "snake_case_keys" to "camelCaseKeys" before 
>>> attempting to match a key with the one specified by each type.
>>> /// 
>>> /// The conversion to upper case uses `Locale.system`, also known 
>>> as the ICU "root" locale. This means the result is consistent regardless of 
>>> the current user's locale and language preferences.
>>> ///
>>> /// Converting from snake case to camel case:
>>> /// 1. Capitalizes the word starting after each `_`
>>> /// 2. Removes all `_`
>>> /// 3. Preserves starting and ending `_` (as these are often used 
>>> to indicate private variables or other metadata).
>>> /// For example, `one_two_three` becomes `oneTwoThree`. 
>>> `_one_two_three_` becomes `_oneTwoThree_`.
>>> ///
>>> /// - Note: Using a key decoding strategy has a nominal performance 
>>> cost, as each string key has to be inspected for the `_` character.
>>> case convertFromSnakeCase
>>> 
>>> /// Provide a custom conversion from the key in the encoded JSON to 
>>> the keys specified by the decoded types.
>>> /// The full path to the current decoding position is provided for 
>>> context (in case you need to locate this key within the payload). The 
>>> returned key is used in place of the last component in the coding path 
>>> before decoding.
>>> case custom(([CodingKey]) -> CodingKey)
>>> }
>>> 
>>> /// The strategy to use for decoding keys. Defaults to 
>>> `.useDefaultKeys`.
>>> open var keyDecodingStrategy: KeyDecodingStrategy = .useDefaultKeys
>>> }
>>> 
>>> class JSONEncoder {
>>> /// The strategy to use for automatically changing the value of keys 
>>> before encoding.
>>> public enum KeyEncodingStrategy {
>>> /// Use the keys specified by each type. This is the default 
>>> strategy.
>>> case useDefaultKeys
>>> 
>>> /// Convert from "camelCaseKeys" to "snake_case_keys" before 
>>> writing a key to JSON 

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[T.J. Usiyan via swift-evolution]

I used the existence of the first one in my explanation of explain
optionals. "There is a reasonable default value for an optional type.
'nothing'."

TJ

On Mon, Nov 6, 2017 at 6:52 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Nov 6, 2017, at 4:29 PM, Kelvin Ma  wrote:
>
> hot take: i use the second one a lot but only because i always forget the
> first one exists. So I type the = nil just to “be sure”.
>
>
> Yeah, that’s one of my arguments against having the feature, along with
> the simple fact that if the language did not have it already, nobody would
> be requesting this to be added as a special case for optionals.
>
> However, since I also want to avoid needless source compatibility churn,
> I’m fine with keeping the feature — it’s not a huge burden to maintain
> (unlike, say, AnyObject dispatch :) )
>
> Slava
>
>
> On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi all,
>>
>> Right now, the following two declarations are equivalent:
>>
>> struct S {
>>   var x: Int?
>> }
>>
>> struct S {
>>   var x: Int? = nil
>> }
>>
>> That is, mutable bindings of sugared optional type (but not Optional!)
>> always have a default value of ‘nil’. This feature increases the surface
>> area of the language for no good reason, and I would like to deprecate it
>> in -swift-version 5 with a short proposal. Does anyone feel strongly about
>> giving it up? I suspect most Swift users don’t even know it exists.
>>
>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0132 Rationalizing Sequence end-operation names

[Nicholas Maccharoli via swift-evolution]

+1 here, this irked me for a while as well.

On Mon, Nov 6, 2017 at 10:05 AM, Rudolf Adamkovič via swift-evolution <
swift-evolution@swift.org> wrote:

> Huge +1. Every time I work with collections, I read the type signatures to
> be 100% on whether a method will mutate in place or not. I don’t trust the
> names as they’re not consistent.
>
> R+
>
> Sent from my iPhone
>
> On 3 Nov 2017, at 02:58, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Nov 2, 2017 at 7:26 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> During the Swift 3 cycle, I proposed SE-0132, "Rationalizing Sequence
>> end-operation names". It was rejected because it needed revision and there
>> was no time to do so. Since then, part of the proposal—partial ranges and
>> the `RangeExpression` slicing protocol—has been adopted in SE-0172,
>> "One-sided Ranges". I''d like to reopen discussion of the rest of the
>> proposal.
>>
>> To refresh your memory, SE-0132 proposed systematically renaming a number
>> of `Sequence` and `Collection` methods which operate on the beginning and
>> end of a sequence. Many of these methods have names borrowed directly from
>> functional programming; they use terminology in conflicting ways and don't
>> follow our conventions for non-mutating method names. For example, consider
>> the inconsistent and API Guideline-violating names of a few members which
>> operate on the beginning of a sequence or collection:
>>
>> first   dropFirst()
>>  removeFirst()
>> prefix(_:)  dropFirst(_:)
>>  removeFirst(_:)
>> prefix(while:)  drop(while:)—
>>
>> These members could be renamed to form consistent "families" where a
>> given term always meant the same thing:
>>
>> first   removingFirst() removeFirst()
>> prefix(_:)  removingPrefix(_:)
>> removePrefix(_:)
>> prefix(while:)  removingPrefix(while:)  —
>>
>> The main question in my mind about this plan is source stability. Back
>> during Swift 3, we broke compatibility willy-nilly, but today we're being a
>> little more circumspect. I believe these names meet the criteria of being
>> actively harmful—they are difficult to discover, so developers don't use
>> these members even when they should, and many of them sound like mutating
>> methods or are unclear about their purpose—but that still doesn't tell us
>> how we should treat the old names.
>>
>> Basically, when should we introduce the new names?
>>
>> 1. Swift 4.1 (or whatever pre-Swift 5 version the proposal ends
>> up landing in)
>> 2. Swift 4.n (the version of Swift 5's compatibility mode for
>> Swift 4)
>> 3. Swift 5
>>
>
> (All of the following IMHO:)
>
> Swift 4.1 or whatever is closest. The new names are very clear, and their
> introduction doesn't impair backwards compatibility.
>
>
>> And when should we deprecate the old ones?
>>
>> 1. Swift 4.1
>> 2. Swift 4.n
>> 3. Swift 5
>> 4. Swift 6
>> 5. Never
>>
>
> Deprecation warnings: Swift 5. Code continues to compile, and fix-its and
> a migrator can get rid of the warning.
> Removal of deprecated API: Swift 6; ABI stability may require these
> symbols to continue to exist though.
>
> I'm also open to discussion about whether this should be done at all,
>> whether any additional methods should be included (or included methods
>> should be left alone), whether the now-obsolete `prefix(from:)`
>> `prefix(upTo:)`, and `prefix(through:)` methods should be left alone,
>> deprecated, or removed, and whether this should be done in this proposal or
>> a different one.
>>
>
> Could deprecate in Swift 5--don't feel strongly about this one. Definitely
> a separate proposal.
>
>
>> The original proposal, which lists all affected methods and explains the
>> logic behind them, is available at > t-evolution/blob/master/proposals/0132-sequence-end-ops.md>. Keep in
>> mind that the parts about ranges have already been incorporated into Swift
>> in a revised form, so you can ignore them.
>>
>> I'll get cracking on an implementation once we figure out what I should
>> implement.
>>
>> Thanks!
>>
>
>
> ___
> 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] Pitch: Remove default initialization of optional bindings

[Slava Pestov via swift-evolution]

> On Nov 6, 2017, at 4:29 PM, Kelvin Ma  wrote:
> 
> hot take: i use the second one a lot but only because i always forget the 
> first one exists. So I type the = nil just to “be sure”.

Yeah, that’s one of my arguments against having the feature, along with the 
simple fact that if the language did not have it already, nobody would be 
requesting this to be added as a special case for optionals.

However, since I also want to avoid needless source compatibility churn, I’m 
fine with keeping the feature — it’s not a huge burden to maintain (unlike, 
say, AnyObject dispatch :) )

Slava

> 
> On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution 
> > wrote:
> Hi all,
> 
> Right now, the following two declarations are equivalent:
> 
> struct S {
>   var x: Int?
> }
> 
> struct S {
>   var x: Int? = nil
> }
> 
> That is, mutable bindings of sugared optional type (but not Optional!) 
> always have a default value of ‘nil’. This feature increases the surface area 
> of the language for no good reason, and I would like to deprecate it in 
> -swift-version 5 with a short proposal. Does anyone feel strongly about 
> giving it up? I suspect most Swift users don’t even know it exists.
> 
> 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] JSONEncoder: Key strategies

[Norio Nomura via swift-evolution]

Hi Tony,

Is it better for us to choose on `Codable` side whether `rawValue` of
`CodingKeys` should be generated with snake_case?
It seems to be more consistent with the current method of setting
`rawValue` of `CodingKeys` on `Codable` side.

Thanks,
--
@norio_nomura

2017-11-07 5:54 GMT+09:00 Tony Parker via swift-evolution <
swift-evolution@swift.org>:

> Hi everyone,
>
> While we have no formal process at this time for proposals of changes to
> Foundation-only code, I would still like to post one that we have run
> through our internal process here for additional public comment.
>
> Link to PR with proposal content:
>
> https://github.com/apple/swift-corelibs-foundation/pull/1301
>
> Link to implementation for the overlay:
>
> https://github.com/apple/swift/pull/12779
>
> Markdown follows.
>
> Thanks,
> - Tony
>
> # Key Strategies for JSONEncoder and JSONDecoder
>
> * Proposal: SCLF-0001
> * Author(s): Tony Parker 
>
> # Related radars or Swift bugs
>
> *  Snake case / Camel case conversions for
> JSONEncoder/Decoder
>
> # Revision history
>
> * **v1** Initial version
>
> ## Introduction
>
> While early feedback for `JSONEncoder` and `JSONDecoder` has been very
> positive, many developers have told us that they would appreciate a
> convenience for converting between `snake_case_keys` and `camelCaseKeys`
> without having to manually specify the key values for all types.
>
> ## Proposed solution
>
> `JSONEncoder` and `JSONDecoder` will gain new strategy properties to allow
> for conversion of keys during encoding and decoding.
>
> ```swift
> class JSONDecoder {
> /// The strategy to use for automatically changing the value of keys
> before decoding.
> public enum KeyDecodingStrategy {
> /// Use the keys specified by each type. This is the default
> strategy.
> case useDefaultKeys
>
> /// Convert from "snake_case_keys" to "camelCaseKeys" before
> attempting to match a key with the one specified by each type.
> ///
> /// The conversion to upper case uses `Locale.system`, also known
> as the ICU "root" locale. This means the result is consistent regardless of
> the current user's locale and language preferences.
> ///
> /// Converting from snake case to camel case:
> /// 1. Capitalizes the word starting after each `_`
> /// 2. Removes all `_`
> /// 3. Preserves starting and ending `_` (as these are often used
> to indicate private variables or other metadata).
> /// For example, `one_two_three` becomes `oneTwoThree`.
> `_one_two_three_` becomes `_oneTwoThree_`.
> ///
> /// - Note: Using a key decoding strategy has a nominal
> performance cost, as each string key has to be inspected for the `_`
> character.
> case convertFromSnakeCase
>
> /// Provide a custom conversion from the key in the encoded JSON
> to the keys specified by the decoded types.
> /// The full path to the current decoding position is provided for
> context (in case you need to locate this key within the payload). The
> returned key is used in place of the last component in the coding path
> before decoding.
> case custom(([CodingKey]) -> CodingKey)
> }
>
> /// The strategy to use for decoding keys. Defaults to
> `.useDefaultKeys`.
> open var keyDecodingStrategy: KeyDecodingStrategy = .useDefaultKeys
> }
>
> class JSONEncoder {
> /// The strategy to use for automatically changing the value of keys
> before encoding.
> public enum KeyEncodingStrategy {
> /// Use the keys specified by each type. This is the default
> strategy.
> case useDefaultKeys
>
> /// Convert from "camelCaseKeys" to "snake_case_keys" before
> writing a key to JSON payload.
> ///
> /// Capital characters are determined by testing membership in
> `CharacterSet.uppercaseLetters` and `CharacterSet.lowercaseLetters`
> (Unicode General Categories Lu and Lt).
> /// The conversion to lower case uses `Locale.system`, also known
> as the ICU "root" locale. This means the result is consistent regardless of
> the current user's locale and language preferences.
> ///
> /// Converting from camel case to snake case:
> /// 1. Splits words at the boundary of lower-case to upper-case
> /// 2. Inserts `_` between words
> /// 3. Lowercases the entire string
> /// 4. Preserves starting and ending `_`.
> ///
> /// For example, `oneTwoThree` becomes `one_two_three`.
> `_oneTwoThree_` becomes `_one_two_three_`.
> ///
> /// - Note: Using a key encoding strategy has a nominal
> performance cost, as each string key has to be converted.
> case convertToSnakeCase
>
> /// Provide a custom conversion to the key in the encoded JSON
> from the keys specified by the encoded types.
> /// The full path to the current encoding position is provided for
> context 

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Jacob Williams via swift-evolution]

> On Nov 6, 2017, at 5:29 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> hot take: i use the second one a lot but only because i always forget the 
> first one exists. So I type the = nil just to “be sure”.
> 

Same here! I just changed a bunch of code since I’d forgotten they were the same

> On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution 
> > wrote:
> Hi all,
> 
> Right now, the following two declarations are equivalent:
> 
> struct S {
>   var x: Int?
> }
> 
> struct S {
>   var x: Int? = nil
> }
> 
> That is, mutable bindings of sugared optional type (but not Optional!) 
> always have a default value of ‘nil’. This feature increases the surface area 
> of the language for no good reason, and I would like to deprecate it in 
> -swift-version 5 with a short proposal. Does anyone feel strongly about 
> giving it up? I suspect most Swift users don’t even know it exists.
> 
> 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

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

Re: [swift-evolution] JSONEncoder: Key strategies

[Tony Parker via swift-evolution]

Hi Alejandro,

> On Nov 6, 2017, at 3:14 PM, Alejandro Martinez via swift-evolution 
>  wrote:
> 
> I’m in favor of this as it’s really, but specially the custom strategy. And 
> thinking about that, would there be a way to expose the functionality of 
> converting a string to camel case or snake case so it could be used in case 
> of writing a custom strategy. Would be cool to have the original 
> functionality when writings a custom strategy instead of having to 
> reimplement it if there is a need.
> 
> Sent from my iPad

We talked about this a bit, and while there are some clever things that are 
possible, ultimately we felt it made the API too complex. I think we have room 
to provide the functionality on the enum later if we want (e.g. a function you 
could call).

- Tony

> 
> On 6 Nov 2017, at 20:54, Tony Parker via swift-evolution 
> > wrote:
> 
>> Hi everyone,
>> 
>> While we have no formal process at this time for proposals of changes to 
>> Foundation-only code, I would still like to post one that we have run 
>> through our internal process here for additional public comment.
>> 
>> Link to PR with proposal content:
>> 
>> https://github.com/apple/swift-corelibs-foundation/pull/1301 
>> 
>> 
>> Link to implementation for the overlay:
>> 
>> https://github.com/apple/swift/pull/12779 
>> 
>> 
>> Markdown follows.
>> 
>> Thanks,
>> - Tony
>> 
>> # Key Strategies for JSONEncoder and JSONDecoder
>> 
>> * Proposal: SCLF-0001
>> * Author(s): Tony Parker > >
>> 
>> # Related radars or Swift bugs
>> 
>> * > Snake case / Camel 
>> case conversions for JSONEncoder/Decoder
>> 
>> # Revision history
>> 
>> * **v1** Initial version
>> 
>> ## Introduction
>> 
>> While early feedback for `JSONEncoder` and `JSONDecoder` has been very 
>> positive, many developers have told us that they would appreciate a 
>> convenience for converting between `snake_case_keys` and `camelCaseKeys` 
>> without having to manually specify the key values for all types.
>> 
>> ## Proposed solution
>> 
>> `JSONEncoder` and `JSONDecoder` will gain new strategy properties to allow 
>> for conversion of keys during encoding and decoding.
>> 
>> ```swift
>> class JSONDecoder {
>> /// The strategy to use for automatically changing the value of keys 
>> before decoding.
>> public enum KeyDecodingStrategy {
>> /// Use the keys specified by each type. This is the default 
>> strategy.
>> case useDefaultKeys
>> 
>> /// Convert from "snake_case_keys" to "camelCaseKeys" before 
>> attempting to match a key with the one specified by each type.
>> /// 
>> /// The conversion to upper case uses `Locale.system`, also known as 
>> the ICU "root" locale. This means the result is consistent regardless of the 
>> current user's locale and language preferences.
>> ///
>> /// Converting from snake case to camel case:
>> /// 1. Capitalizes the word starting after each `_`
>> /// 2. Removes all `_`
>> /// 3. Preserves starting and ending `_` (as these are often used to 
>> indicate private variables or other metadata).
>> /// For example, `one_two_three` becomes `oneTwoThree`. 
>> `_one_two_three_` becomes `_oneTwoThree_`.
>> ///
>> /// - Note: Using a key decoding strategy has a nominal performance 
>> cost, as each string key has to be inspected for the `_` character.
>> case convertFromSnakeCase
>> 
>> /// Provide a custom conversion from the key in the encoded JSON to 
>> the keys specified by the decoded types.
>> /// The full path to the current decoding position is provided for 
>> context (in case you need to locate this key within the payload). The 
>> returned key is used in place of the last component in the coding path 
>> before decoding.
>> case custom(([CodingKey]) -> CodingKey)
>> }
>> 
>> /// The strategy to use for decoding keys. Defaults to `.useDefaultKeys`.
>> open var keyDecodingStrategy: KeyDecodingStrategy = .useDefaultKeys
>> }
>> 
>> class JSONEncoder {
>> /// The strategy to use for automatically changing the value of keys 
>> before encoding.
>> public enum KeyEncodingStrategy {
>> /// Use the keys specified by each type. This is the default 
>> strategy.
>> case useDefaultKeys
>> 
>> /// Convert from "camelCaseKeys" to "snake_case_keys" before writing 
>> a key to JSON payload.
>> ///
>> /// Capital characters are determined by testing membership in 
>> `CharacterSet.uppercaseLetters` and `CharacterSet.lowercaseLetters` (Unicode 
>> General Categories Lu and Lt).
>> /// The conversion to lower case uses `Locale.system`, also known as 

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Kelvin Ma via swift-evolution]

hot take: i use the second one a lot but only because i always forget the
first one exists. So I type the = nil just to “be sure”.

On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> Right now, the following two declarations are equivalent:
>
> struct S {
>   var x: Int?
> }
>
> struct S {
>   var x: Int? = nil
> }
>
> That is, mutable bindings of sugared optional type (but not Optional!)
> always have a default value of ‘nil’. This feature increases the surface
> area of the language for no good reason, and I would like to deprecate it
> in -swift-version 5 with a short proposal. Does anyone feel strongly about
> giving it up? I suspect most Swift users don’t even know it exists.
>
> 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] Pitch: Remove default initialization of optional bindings

[Slava Pestov via swift-evolution]

It sounds like several people rely on this behavior and are actually aware that 
it exists, so I won’t pursue the issue further.

Thanks for the feedback!

> On Nov 6, 2017, at 3:07 PM, Alejandro Martinez  wrote:
> 
> I won’t complain a lot if it’s decided to be removed but I would prefer it to 
> stay. I use it constantly.
> 
> Sent from my iPad
> 
>> On 6 Nov 2017, at 22:41, Jon Shier via swift-evolution 
>>  wrote:
>> 
>>   I use this on all of my mutable optional properties, when I have to use 
>> them. It’s just that little extra bit of code I don’t need to write, and it 
>> feels a lot like parameter defaults in use. By surface area, I assume you 
>> mean the fact that it’s an implicit behavior people may need to remember? As 
>> something like that, this seems like a very small one. As for users knowing 
>> about it, I’m guessing it falls into one of those things that people just 
>> never explicitly notice but would likely have a huge impact on anyone with 
>> lots of mutable optionals. Developers from other languages may also assume 
>> this behavior, since it replicates the “nil by default” behavior seen in 
>> other languages. 
>>   Ultimately, while I won’t feel this deeply, since I tend to view mutable 
>> optionals as poor practice in Swift, it’s a nice little convenience that 
>> will likely impact everyone using mutable optionals. If you really want to 
>> find out, perhaps run it agains the compatibility suite?
>> 
>> 
>> Jon
>> 
>>> On Nov 6, 2017, at 5:33 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Right now, the following two declarations are equivalent:
>>> 
>>> struct S {
>>> var x: Int?
>>> }
>>> 
>>> struct S {
>>> var x: Int? = nil
>>> }
>>> 
>>> That is, mutable bindings of sugared optional type (but not Optional!) 
>>> always have a default value of ‘nil’. This feature increases the surface 
>>> area of the language for no good reason, and I would like to deprecate it 
>>> in -swift-version 5 with a short proposal. Does anyone feel strongly about 
>>> giving it up? I suspect most Swift users don’t even know it exists.
>>> 
>>> 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

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

Re: [swift-evolution] JSONEncoder: Key strategies

[Alejandro Martinez via swift-evolution]

I’m in favor of this as it’s really, but specially the custom strategy. And 
thinking about that, would there be a way to expose the functionality of 
converting a string to camel case or snake case so it could be used in case of 
writing a custom strategy. Would be cool to have the original functionality 
when writings a custom strategy instead of having to reimplement it if there is 
a need.

Sent from my iPad

> On 6 Nov 2017, at 20:54, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> While we have no formal process at this time for proposals of changes to 
> Foundation-only code, I would still like to post one that we have run through 
> our internal process here for additional public comment.
> 
> Link to PR with proposal content:
> 
> https://github.com/apple/swift-corelibs-foundation/pull/1301
> 
> Link to implementation for the overlay:
> 
> https://github.com/apple/swift/pull/12779
> 
> Markdown follows.
> 
> Thanks,
> - Tony
> 
> # Key Strategies for JSONEncoder and JSONDecoder
> 
> * Proposal: SCLF-0001
> * Author(s): Tony Parker 
> 
> # Related radars or Swift bugs
> 
> *  Snake case / Camel case conversions for 
> JSONEncoder/Decoder
> 
> # Revision history
> 
> * **v1** Initial version
> 
> ## Introduction
> 
> While early feedback for `JSONEncoder` and `JSONDecoder` has been very 
> positive, many developers have told us that they would appreciate a 
> convenience for converting between `snake_case_keys` and `camelCaseKeys` 
> without having to manually specify the key values for all types.
> 
> ## Proposed solution
> 
> `JSONEncoder` and `JSONDecoder` will gain new strategy properties to allow 
> for conversion of keys during encoding and decoding.
> 
> ```swift
> class JSONDecoder {
> /// The strategy to use for automatically changing the value of keys 
> before decoding.
> public enum KeyDecodingStrategy {
> /// Use the keys specified by each type. This is the default strategy.
> case useDefaultKeys
> 
> /// Convert from "snake_case_keys" to "camelCaseKeys" before 
> attempting to match a key with the one specified by each type.
> /// 
> /// The conversion to upper case uses `Locale.system`, also known as 
> the ICU "root" locale. This means the result is consistent regardless of the 
> current user's locale and language preferences.
> ///
> /// Converting from snake case to camel case:
> /// 1. Capitalizes the word starting after each `_`
> /// 2. Removes all `_`
> /// 3. Preserves starting and ending `_` (as these are often used to 
> indicate private variables or other metadata).
> /// For example, `one_two_three` becomes `oneTwoThree`. 
> `_one_two_three_` becomes `_oneTwoThree_`.
> ///
> /// - Note: Using a key decoding strategy has a nominal performance 
> cost, as each string key has to be inspected for the `_` character.
> case convertFromSnakeCase
> 
> /// Provide a custom conversion from the key in the encoded JSON to 
> the keys specified by the decoded types.
> /// The full path to the current decoding position is provided for 
> context (in case you need to locate this key within the payload). The 
> returned key is used in place of the last component in the coding path before 
> decoding.
> case custom(([CodingKey]) -> CodingKey)
> }
> 
> /// The strategy to use for decoding keys. Defaults to `.useDefaultKeys`.
> open var keyDecodingStrategy: KeyDecodingStrategy = .useDefaultKeys
> }
> 
> class JSONEncoder {
> /// The strategy to use for automatically changing the value of keys 
> before encoding.
> public enum KeyEncodingStrategy {
> /// Use the keys specified by each type. This is the default strategy.
> case useDefaultKeys
> 
> /// Convert from "camelCaseKeys" to "snake_case_keys" before writing 
> a key to JSON payload.
> ///
> /// Capital characters are determined by testing membership in 
> `CharacterSet.uppercaseLetters` and `CharacterSet.lowercaseLetters` (Unicode 
> General Categories Lu and Lt).
> /// The conversion to lower case uses `Locale.system`, also known as 
> the ICU "root" locale. This means the result is consistent regardless of the 
> current user's locale and language preferences.
> ///
> /// Converting from camel case to snake case:
> /// 1. Splits words at the boundary of lower-case to upper-case
> /// 2. Inserts `_` between words
> /// 3. Lowercases the entire string
> /// 4. Preserves starting and ending `_`.
> ///
> /// For example, `oneTwoThree` becomes `one_two_three`. 
> `_oneTwoThree_` becomes `_one_two_three_`.
> ///
> /// - Note: Using a key encoding strategy has a nominal performance 
> cost, as each string key has to be converted.
> case 

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Alejandro Martinez via swift-evolution]

I won’t complain a lot if it’s decided to be removed but I would prefer it to 
stay. I use it constantly.

Sent from my iPad

> On 6 Nov 2017, at 22:41, Jon Shier via swift-evolution 
>  wrote:
> 
>I use this on all of my mutable optional properties, when I have to use 
> them. It’s just that little extra bit of code I don’t need to write, and it 
> feels a lot like parameter defaults in use. By surface area, I assume you 
> mean the fact that it’s an implicit behavior people may need to remember? As 
> something like that, this seems like a very small one. As for users knowing 
> about it, I’m guessing it falls into one of those things that people just 
> never explicitly notice but would likely have a huge impact on anyone with 
> lots of mutable optionals. Developers from other languages may also assume 
> this behavior, since it replicates the “nil by default” behavior seen in 
> other languages. 
>Ultimately, while I won’t feel this deeply, since I tend to view mutable 
> optionals as poor practice in Swift, it’s a nice little convenience that will 
> likely impact everyone using mutable optionals. If you really want to find 
> out, perhaps run it agains the compatibility suite?
> 
> 
> Jon
> 
>> On Nov 6, 2017, at 5:33 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Right now, the following two declarations are equivalent:
>> 
>> struct S {
>> var x: Int?
>> }
>> 
>> struct S {
>> var x: Int? = nil
>> }
>> 
>> That is, mutable bindings of sugared optional type (but not Optional!) 
>> always have a default value of ‘nil’. This feature increases the surface 
>> area of the language for no good reason, and I would like to deprecate it in 
>> -swift-version 5 with a short proposal. Does anyone feel strongly about 
>> giving it up? I suspect most Swift users don’t even know it exists.
>> 
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Jon Shier via swift-evolution]

I use this on all of my mutable optional properties, when I have to use 
them. It’s just that little extra bit of code I don’t need to write, and it 
feels a lot like parameter defaults in use. By surface area, I assume you mean 
the fact that it’s an implicit behavior people may need to remember? As 
something like that, this seems like a very small one. As for users knowing 
about it, I’m guessing it falls into one of those things that people just never 
explicitly notice but would likely have a huge impact on anyone with lots of 
mutable optionals. Developers from other languages may also assume this 
behavior, since it replicates the “nil by default” behavior seen in other 
languages. 
Ultimately, while I won’t feel this deeply, since I tend to view 
mutable optionals as poor practice in Swift, it’s a nice little convenience 
that will likely impact everyone using mutable optionals. If you really want to 
find out, perhaps run it agains the compatibility suite?


Jon

> On Nov 6, 2017, at 5:33 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Right now, the following two declarations are equivalent:
> 
> struct S {
>  var x: Int?
> }
> 
> struct S {
>  var x: Int? = nil
> }
> 
> That is, mutable bindings of sugared optional type (but not Optional!) 
> always have a default value of ‘nil’. This feature increases the surface area 
> of the language for no good reason, and I would like to deprecate it in 
> -swift-version 5 with a short proposal. Does anyone feel strongly about 
> giving it up? I suspect most Swift users don’t even know it exists.
> 
> 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] Pitch: Remove default initialization of optional bindings

[Matthew Johnson via swift-evolution]

> On Nov 6, 2017, at 4:33 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Right now, the following two declarations are equivalent:
> 
> struct S {
>  var x: Int?
> }
> 
> struct S {
>  var x: Int? = nil
> }
> 
> That is, mutable bindings of sugared optional type (but not Optional!) 
> always have a default value of ‘nil’. This feature increases the surface area 
> of the language for no good reason, and I would like to deprecate it in 
> -swift-version 5 with a short proposal. Does anyone feel strongly about 
> giving it up? I suspect most Swift users don’t even know it exists.

I don’t have too strong an opinion on this, leaning towards being supportive.  
That said, I think you underestimate the source breakage it will cause.  I have 
seen a lot  of code this change will break (albeit in a trivial way that’s easy 
to migrate).

> 
> 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] Pitch: Remove default initialization of optional bindings

[Adrian Zubarev via swift-evolution]

Just a quick question for clarification. What will happen to these? Do we have 
to provide the default value ourselves?

class ViewController : UIViewController {

    @IBOutlet weak var view1: UIView?

    @IBOutlet weak var view2: UIView!
}


Am 6. November 2017 um 23:33:51, Slava Pestov via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi all,

Right now, the following two declarations are equivalent:

struct S {
var x: Int?
}

struct S {
var x: Int? = nil
}

That is, mutable bindings of sugared optional type (but not Optional!) 
always have a default value of ‘nil’. This feature increases the surface area 
of the language for no good reason, and I would like to deprecate it in 
-swift-version 5 with a short proposal. Does anyone feel strongly about giving 
it up? I suspect most Swift users don’t even know it exists.

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

[swift-evolution] Pitch: Remove default initialization of optional bindings

[Slava Pestov via swift-evolution]

Hi all,

Right now, the following two declarations are equivalent:

struct S {
  var x: Int?
}

struct S {
  var x: Int? = nil
}

That is, mutable bindings of sugared optional type (but not Optional!) 
always have a default value of ‘nil’. This feature increases the surface area 
of the language for no good reason, and I would like to deprecate it in 
-swift-version 5 with a short proposal. Does anyone feel strongly about giving 
it up? I suspect most Swift users don’t even know it exists.

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

[swift-evolution] JSONEncoder: Key strategies

[Tony Parker via swift-evolution]

Hi everyone,

While we have no formal process at this time for proposals of changes to 
Foundation-only code, I would still like to post one that we have run through 
our internal process here for additional public comment.

Link to PR with proposal content:

https://github.com/apple/swift-corelibs-foundation/pull/1301

Link to implementation for the overlay:

https://github.com/apple/swift/pull/12779 


Markdown follows.

Thanks,
- Tony

# Key Strategies for JSONEncoder and JSONDecoder

* Proposal: SCLF-0001
* Author(s): Tony Parker 

# Related radars or Swift bugs

*  Snake case / Camel case conversions for 
JSONEncoder/Decoder

# Revision history

* **v1** Initial version

## Introduction

While early feedback for `JSONEncoder` and `JSONDecoder` has been very 
positive, many developers have told us that they would appreciate a convenience 
for converting between `snake_case_keys` and `camelCaseKeys` without having to 
manually specify the key values for all types.

## Proposed solution

`JSONEncoder` and `JSONDecoder` will gain new strategy properties to allow for 
conversion of keys during encoding and decoding.

```swift
class JSONDecoder {
/// The strategy to use for automatically changing the value of keys before 
decoding.
public enum KeyDecodingStrategy {
/// Use the keys specified by each type. This is the default strategy.
case useDefaultKeys

/// Convert from "snake_case_keys" to "camelCaseKeys" before attempting 
to match a key with the one specified by each type.
/// 
/// The conversion to upper case uses `Locale.system`, also known as 
the ICU "root" locale. This means the result is consistent regardless of the 
current user's locale and language preferences.
///
/// Converting from snake case to camel case:
/// 1. Capitalizes the word starting after each `_`
/// 2. Removes all `_`
/// 3. Preserves starting and ending `_` (as these are often used to 
indicate private variables or other metadata).
/// For example, `one_two_three` becomes `oneTwoThree`. 
`_one_two_three_` becomes `_oneTwoThree_`.
///
/// - Note: Using a key decoding strategy has a nominal performance 
cost, as each string key has to be inspected for the `_` character.
case convertFromSnakeCase

/// Provide a custom conversion from the key in the encoded JSON to the 
keys specified by the decoded types.
/// The full path to the current decoding position is provided for 
context (in case you need to locate this key within the payload). The returned 
key is used in place of the last component in the coding path before decoding.
case custom(([CodingKey]) -> CodingKey)
}

/// The strategy to use for decoding keys. Defaults to `.useDefaultKeys`.
open var keyDecodingStrategy: KeyDecodingStrategy = .useDefaultKeys
}

class JSONEncoder {
/// The strategy to use for automatically changing the value of keys before 
encoding.
public enum KeyEncodingStrategy {
/// Use the keys specified by each type. This is the default strategy.
case useDefaultKeys

/// Convert from "camelCaseKeys" to "snake_case_keys" before writing a 
key to JSON payload.
///
/// Capital characters are determined by testing membership in 
`CharacterSet.uppercaseLetters` and `CharacterSet.lowercaseLetters` (Unicode 
General Categories Lu and Lt).
/// The conversion to lower case uses `Locale.system`, also known as 
the ICU "root" locale. This means the result is consistent regardless of the 
current user's locale and language preferences.
///
/// Converting from camel case to snake case:
/// 1. Splits words at the boundary of lower-case to upper-case
/// 2. Inserts `_` between words
/// 3. Lowercases the entire string
/// 4. Preserves starting and ending `_`.
///
/// For example, `oneTwoThree` becomes `one_two_three`. `_oneTwoThree_` 
becomes `_one_two_three_`.
///
/// - Note: Using a key encoding strategy has a nominal performance 
cost, as each string key has to be converted.
case convertToSnakeCase

/// Provide a custom conversion to the key in the encoded JSON from the 
keys specified by the encoded types.
/// The full path to the current encoding position is provided for 
context (in case you need to locate this key within the payload). The returned 
key is used in place of the last component in the coding path before encoding.
case custom(([CodingKey]) -> CodingKey)
}


/// The strategy to use for encoding keys. Defaults to `.useDefaultKeys`.
open var keyEncodingStrategy: KeyEncodingStrategy = .useDefaultKeys
}
```

## Detailed design

The strategy enum allows developers to pick from common actions of converting 
to 

Re: [swift-evolution] [SPM] Roadmap?

[Kelvin Ma via swift-evolution]

On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi,
>
> Is there any news about features that are willling to be integrated into
> SPM 5?
> Those I see the most relevant:
> - iOS support
> - Some kind of configuration/settings support (debug, release, ...)
>
> I'd like to hear about it from maintainers, especially if there's a
> priority order we should follow.
>
>
> Hi all,
>
> (CC-ing swift-build-dev, which is the SwiftPM-specific list and is the
> best way to get the SwiftPM core team's attention)
>
> The SwiftPM core team has been discussing our plans for SwiftPM 5, and
> expect to publish a roadmap of the features we're most likely to pursue
> this year. As always, we welcome proposals and contributions for features
> the community would most like to see.
>
> Regarding the specific features that have been mentioned in this thread:
>
> – *iOS support*
>
> I think that this will be best provided by native IDE integration.
> However, in the meantime, I'd welcome contributions to help improve Xcode's
> project generation support.
>
> – *Xcode integration*
>
> I think this will be very important for widespread SwiftPM adoption by the
> Apple-platform developer community.  My previous comments on 2017/6/5 to
> this list are still the latest word on this:
>
> Xcode 9 lays the groundwork for first-class, native support in Xcode for
> Swift packages with the preview version of its new build system. This build
> system provides the flexibility and extensibility needed to allow Xcode to
> support new build models, such as Swift packages. Additionally,
> considerable work has gone into the SwiftPM library vended by the SwiftPM
> project, which will support integrating Swift packages into tools like
> Xcode.
>
>
> I'll note that as Xcode's new build system is still a "preview", further
> work will be needed there before it replaces the old build system. As Xcode
> is not part of the open source project, forward-looking schedules aren't
> something I can discuss.
>
> – *Build settings and configuration support*
>
> The SwiftPM core team has done some work on a proposal for this, and we're
> looking forward to getting this into a publishable state and discussing it
> with the community.
>
> – *Submodules*
>
> Can you elaborate on exactly what you'd like to see here? Offhand I don't
> recall seeing any feature requests in this area.
>

I think submodules means slightly different things to different people but
to me i imagine something like “modules that get compiled together as a
unit”, i.e., there are no ABI boundaries between submodules.


>
> – *Better support for including and linking C libraries*
>
> I'd also like to see this, and welcome proposals / contributions.
>

It’d be great to be able to stick an #include path and a linker flag string
into Package.swift instead of creating empty c modules that just include
system headers. right now this means you have to use a makefile (or
up-arrow in the terminal to get the linker flags back) to compile Swift
projects that depend on system libraries.


>
> – *A swift test command that can execute arbitrary testing code*
>
> As I recall, where the core team had left off on this was a discussion of
> what testability model were going to propose for SwiftPM (specifically,
> handling Swift's -enable-testing flag when needed, but minimizing
> unnecessary rebuilds from using that flag vs. having it off for release
> builds). IIRC, we were considering explicitly modeling "white box" (which
> needs -enable-testing) vs "black box" tests. It's been a little while since
> we last discussed this topic, so if anyone wants this urgently, feel free
> to start a public conversation about this. Any discussion of this should
> also involve the XCTest developers (via swift-corelibs-dev).
>

> – *Help us manage symbol versioning and availability*
>
> Can you elaborate on what you'd like to see here?
>

I only bring this up because there’s been a lot of talk about library
evolution, and it is still easy for you to accidentally break your ABI in
an unintended manner as nothing in the compiler really checks this. It’d be
nice if the SPM took on a bigger role in checking ABI compatibility.

Something else I think will become important to have in the SPM is a better
name conflict resolution system. Right now if you depend on two modules
(even indirectly) that have the same name there’s really nothing you can
do. The SPM should have something like an “import as” system where we can
rebind a conflicting module to a new local name.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Abstract methods

[Mike Kluev via swift-evolution]

On 6 November 2017 at 19:44, Tino Heth <2...@gmx.de> wrote:

> to me protocol extensions are both cool and evil. cool as you can add
> code. evil because it's more natural to add another declarations in those
> extensions rather than implementation:
>
> protocol Foo {
> func foo()
> }
>
> extension Foo {
>func bar()//*** natural assumption is that i can do this. but i
> can't
> }
>
> After a moment of reflection, I think I understand your reasoning — but
> why should you want to do this?
> Imho splitting types with extensions is already overused quite often, but
> splitting a protocol makes no sense for me at all.
>

the use case would be splitting my own big protocols into different parts
for code organizing purposes (so it's within the module boundaries).

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

Re: [swift-evolution] Abstract methods

[Tino Heth via swift-evolution]

> to me protocol extensions are both cool and evil. cool as you can add code. 
> evil because it's more natural to add another declarations in those 
> extensions rather than implementation:
> 
> protocol Foo {
> func foo()
> }
> 
> extension Foo {
>func bar()//*** natural assumption is that i can do this. but i can't
> }
After a moment of reflection, I think I understand your reasoning — but why 
should you want to do this?
Imho splitting types with extensions is already overused quite often, but 
splitting a protocol makes no sense for me at all.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Abstract methods

[Trevör Anne Denise via swift-evolution]

> to me protocol extensions are both cool and evil. cool as you can add code.
> evil because it's more natural to add another declarations in those
> extensions rather than implementation:
> 
> protocol Foo {
>func foo()
> }
> 
> extension Foo {
>   func bar()//*** natural assumption is that i can do this. but i can't
> }

While this can indeed be a common mistake, it feels much less natural to do 
that once you think about what protocol conformances mean and what it would 
take to make it possible IMO.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

[Tony Parker via swift-evolution]

Hi Florent,

We definitely thought about this while designing the set of types with the 
Codable proposals.

One serious concern was just how much API surface area there already is with 
Codable. If we open up the internal classes as well, we risk confusing the 
majority of people who are just adopting Codable with APIs that are intended 
only for the minority of people who are trying to create their own custom 
encoders and decoders.

Any thoughts on how to mitigate this?

- Tony

> On Nov 3, 2017, at 9:58 AM, Florent Vilmart via swift-evolution 
>  wrote:
> 
> At Swift Summit, we discussed with Joe and Jordan about opening up the 
> Encoder/Decoder classes in order to make the work of an encoder designer 
> easier.
> 
> As I was working on an API project, I found myself into the situation of 
> needing to tweak so slightly the encoding strategy this required a full 
> copy/paste of the JSONEncoder.swift file and playing with the internals. I 
> also wanted to implement a simple QueryStringEncoder/Decoder that would 
> properly encode / decode a query string.
> 
> The internally defined classes are proven a very powerful tool of reflection 
> as well, being able to collect / untransform a series of containers safely 
> into a strongly typed swift object.
> 
> The pitch:
> 
> - Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data
> - Make _JSONEncoder / _JSONDecoder open classes
> - Mark public all container implementations of UnkeyedEncodingContainers 
> etc... 
> - Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't 
> conflict with JSONEncoder / JSONDecoder but also denotes they conform to 
> Encoder. 
> 
> Opening those API's isn't for the general Codable implementation, the 
> JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the 
> amount of boiler plate one would need to implement in order to provide 
> different serialization mechanism / strategy.
>  
> 
> ___
> 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] [SPM] Roadmap?

[Rick Ballard via swift-evolution]

> On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution 
>  wrote:
> 
> Hi,
> 
> Is there any news about features that are willling to be integrated into SPM 
> 5?
> Those I see the most relevant:
> - iOS support
> - Some kind of configuration/settings support (debug, release, ...)
> 
> I'd like to hear about it from maintainers, especially if there's a priority 
> order we should follow.


Hi all,

(CC-ing swift-build-dev, which is the SwiftPM-specific list and is the best way 
to get the SwiftPM core team's attention)

The SwiftPM core team has been discussing our plans for SwiftPM 5, and expect 
to publish a roadmap of the features we're most likely to pursue this year. As 
always, we welcome proposals and contributions for features the community would 
most like to see.

Regarding the specific features that have been mentioned in this thread:

– iOS support

I think that this will be best provided by native IDE integration. However, in 
the meantime, I'd welcome contributions to help improve Xcode's project 
generation support.

– Xcode integration

I think this will be very important for widespread SwiftPM adoption by the 
Apple-platform developer community.  My previous comments on 2017/6/5 to this 
list are still the latest word on this:

> Xcode 9 lays the groundwork for first-class, native support in Xcode for 
> Swift packages with the preview version of its new build system. This build 
> system provides the flexibility and extensibility needed to allow Xcode to 
> support new build models, such as Swift packages. Additionally, considerable 
> work has gone into the SwiftPM library vended by the SwiftPM project, which 
> will support integrating Swift packages into tools like Xcode.

I'll note that as Xcode's new build system is still a "preview", further work 
will be needed there before it replaces the old build system. As Xcode is not 
part of the open source project, forward-looking schedules aren't something I 
can discuss.

– Build settings and configuration support

The SwiftPM core team has done some work on a proposal for this, and we're 
looking forward to getting this into a publishable state and discussing it with 
the community.

– Submodules

Can you elaborate on exactly what you'd like to see here? Offhand I don't 
recall seeing any feature requests in this area.

– Better support for including and linking C libraries

I'd also like to see this, and welcome proposals / contributions.

– A swift test command that can execute arbitrary testing code

As I recall, where the core team had left off on this was a discussion of what 
testability model were going to propose for SwiftPM (specifically, handling 
Swift's -enable-testing flag when needed, but minimizing unnecessary rebuilds 
from using that flag vs. having it off for release builds). IIRC, we were 
considering explicitly modeling "white box" (which needs -enable-testing) vs 
"black box" tests. It's been a little while since we last discussed this topic, 
so if anyone wants this urgently, feel free to start a public conversation 
about this. Any discussion of this should also involve the XCTest developers 
(via swift-corelibs-dev).

– Help us manage symbol versioning and availability

Can you elaborate on what you'd like to see here?

– Resources / assets

I think this will be especially important for the iOS developer story, but of 
course it's useful elsewhere as well. This is definitely on the core team's 
todo list to write a proposal for at some point.

– Cross-platform modules

Can you elaborate on what you'd like to see here?

– A better C/C++ integration story

The most immediate thing I'm aware of that we're likely to need to do here is 
to provide some build settings to support C++-specific needs. That said, I'd 
welcome discussion of other immediate needs here as well.

– Better error reporting (SPM’s error messages are often cryptic)

This is something we made substantial improvements to in SwiftPM 4, so if you 
haven't upgraded to that release, I'd strongly encourage you to. For other 
cryptic error messages you encounter, please file reports at bugs.swift.org 
 – I'd like to see these clarified.

Thanks, all.

- Rick

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

Re: [swift-evolution] Abstract methods

[Mike Kluev via swift-evolution]

on Sun, 5 Nov 2017 09:27:09 + Goffredo Marocchi 
wrote:

>
> I would say that you kind of already entered a slippery slope when the
> extension to a protocol can add code / not just declare a behavioural
> contract ...


to me protocol extensions are both cool and evil. cool as you can add code.
evil because it's more natural to add another declarations in those
extensions rather than implementation:

protocol Foo {
func foo()
}

extension Foo {
   func bar()//*** natural assumption is that i can do this. but i can't
}

i'd say, abusing "extension protocol" syntax to add code looks like a
(cool) hack and my +1 would be for some other more explicit syntactic
construct for the purposes of adding code, for example:

implementation Foo {
func foo() {
...
}
}

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

Re: [swift-evolution] Re-pitch: Deriving collections of enum cases

[Tony Allevato via swift-evolution]

On Sun, Nov 5, 2017 at 11:54 PM Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> Over a year ago, we discussed adding a magic "allValues"/"allCases" static
> property on enums with a compiler-derived implementation. The original 
> proposal
> PR  has been reopened
> for Swift 5 after languishing for a while, and I'd like to revisit it and
> make some changes before it goes up for formal review.
>

Thanks for bringing this one back up!


>
> Prior discussion:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015098.html
> (good luck finding the rest of the thread if you weren't on the list at the
> time...)
>
> [cc'd swift-dev for importer/availability-related topics below.]
>
> ***Naming***
>
> Given the complexity gap between a simple enumeration of cases and full
> support for non-enum types and associated values (which we don't intend to
> support with this proposal), I think it might be a good idea to adopt the
> names *CaseEnumerable/allCases* instead of ValueEnumerable/allValues.
>

Naming the protocol CaseEnumerable/allCases seems like an unnecessary
restriction. There may be a complexity gap today in synthesizing the
requirement for types other than basic enums, but that doesn't mean that it
will always exist. What's the value of locking ourselves into the more
restrictive name? Protocols act as contracts that can be used for generic
programming and should thus be as generalized as possible. Any type could
implement ValueEnumerable and implement allValues by hand if they wanted.
If you don't intend to forbid this, then the name CaseEnumerable/allCases
is not an improvement over ValueEnumerable/allValues.



>
> The original proposal didn't expose allValues as a requirement, for fear
> of unduly restricting its type. However, if the protocol's scope is more
> limited, *static var allCases* can be exposed as a requirement since the
> implementations are not likely to be complex. Furthermore...
>

>
> ***Generics***
>
> Since SE-0142
> 
> was implemented in Swift 4, we now have more expressive options for the
> protocol requirements:
>
>   // 1 - array only
>   protocol CaseEnumerable {
> static var allCases: [Self] { get }
>   }
>
>   // 2 - any sequence
>   protocol CaseEnumerable {
> associatedtype *CaseSequence*: Sequence where CaseSequence.Element ==
> Self
> static var *allCases*: CaseSequence { get }
>   }
>
>   // 3 - any collection
>   protocol CaseEnumerable {
> associatedtype *CaseCollection*: Collection where
> CaseCollection.Element == Self
> static var *allCases*: CaseCollection { get }
>   }
>
> This restricts the CaseEnumerable protocol to be used as a generic
> constraint, but that'd be true even with a plain array because of the Self
> type.
>
> Personally I like the flexibility provided by the associatedtype, but I
> also recognize it won't be incredibly useful for enums — more so if we
> wanted to provide e.g. UInt8.allValues, whose ideal implementation might be
> "return 0...UInt8.max". So I could see allowing allValues to be any
> sequence or collection, but flexibility for allCases might be less
> important. Others should weigh in here.
>

This goes back to the point above about generality in protocol design and
future-proofing—Sequence would be the most forward thinking way to specify
the allValues requirement, even if the synthesized version uses something
more refined, like Collection.

I would strongly prefer if the synthesized allValues for simple enums was
*not* an array, but rather a special Int-indexable RandomAccessCollection
(which could be wrapped in an AnyRandomAccessCollection to prevent leaking
implementation details in the API). The rationale for this is that the
information about the cases of an enum is already part of the static
metadata of a type, so we shouldn't force callers of allValues to incur a
heap allocation that is both (1) relatively slow and (2) moves information
we already have into a new copy in heap memory.

The idea that popped into my head for synthesizing the implementation is
something like this, where we map ordinals to cases. The optimizer will
compress this very nicely, I believe, so iterating the cases of an enum
would be extremely fast:

enum MyEnum: ValueEnumerable {
  case zero, one, two, three

  static var allValues: AnyRandomAccessCollection {
return AnyRandomAccessCollection((0..<4).lazy.map {
  switch $0 {
  case 0: return zero
  case 1: return one
  case 2: return two
  case 3: return three
  default: fatalError("unreachable")
  }
})
  }
}

Some might argue that the cases where this performance difference is a
concern are rare, but IMO an implementation synthesized by the compiler
should attempt to be as optimal as possible and not admit obvious
performance penalties if we