Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Tony Parker via swift-evolution]

I was going to write up a detailed response to this as well, but Chris did it 
for me.

In general, I agree that we need the feature.

However, I believe that the name “ABI” is too specific and does not accomplish 
the primary purpose of naming this thing — which is to allow people to 
understand what it means by reading it.

I agree that scoping these attributes inside the availability declaration is 
the best option. As a framework author, the notion of availability is of 
primary importance, and having things which affect how my clients see my code 
be part of that general concept makes the most sense. My second choice would be 
to scope it inside the “public” declaration, as in:

public
public(inlinable)
public(external) // *where we define external to be what abiPublic is now — 
more bike shedding welcome

- Tony

> On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Dec 20, 2017, at 4:19 PM, Ted Kremenek > > wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>>  
>> 
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
> I am hugely supportive of the features that these attributes enable, but I 
> think that the spelling of this is absolutely wrong, and I’m disappointed 
> that the extensive discussion we’ve had for months about this didn’t make it 
> into (at least) the alternatives considered section.  Here are my concerns:
> 
> Availability Ranges
> 
> Both of these attributes will (perhaps not for Swift 5 given the fact that 
> these will be new then, but certainly in 5.1 or 6) need to be qualified by 
> deployment modifiers.  We’ll need the ability to specify not just that a 
> declaration is inlinable or abipublic, but in *which versions* of the binary 
> package (that they are defined in) have this property.  
> 
> For example, while perhaps it will be common for a decl to be “born 
> inlinable” and just need the form of attribute as specified here, it is just 
> as clear that this is not the *only* model we need.  It is entirely 
> reasonable (and will be important in the future) to say that something 
> “became ABI public in iOS14, became abiPublic in iOS 15, and became inlinable 
> in iOS16”.  The use of this will be relatively rare, but it is important for 
> the model to support this in time.
> 
> Because of this, if we accept the spelling as proposed in this proposal, 
> these attributes will need to be generalized to have an availability range, 
> e.g.:
> 
>   @abipublic(iOS 15, *)
> 
> The concern is that this proposal opens the door to have a family of 
> attributes each of which have availability information on them, and this 
> “family” of attributes will have nothing tying them together into a unified 
> framework.
> 
> 
> Pollution of the Attribute Namespace
> 
> Furthermore, these two attributes are the tip of the iceberg, and the core 
> team has spent a lot of time recently discussing the fact there are 
> potentially going to be about a dozen attributes similar to these 
> (fixed_contents,  global_var_is_directly_addressible, …)  that will only be 
> required for binary frameworks.  It is possible that @inlinable will be 
> prominent enough to be a global attribute (I personally am not sure if it 
> will be commonly used or not, it depends a lot on how widely used binary 
> frameworks are).  That said, it is clear @abiPublic will not be commonly 
> used, and many attributes that follow these will be even more obscure.
> 
> This is bad for three reasons: 
> 
> 1) we’re polluting the general attribute namespace with obscure things.  
> Pollution of the attribute namespace may have a marginal impact today, but 
> will start to matter if/when we ever get user defined attributes.  
> 
> 2) The other reason is that this provides no general framework to tie 
> together these things that affect binary frameworks into a unified framework. 
>  
> 
> 3) Furthermore, I don’t like attributes being a dumping ground for weird 
> performance hacks required by binary frameworks.  It is a practical necessity 
> that we support these because they are extremely important for narrow cases, 
> but we don’t need to put them into a syntactically prominent spot in the 
> grammar.
> 
> The name “ABI”
> 
> A minor point, but the specific name “abiPublic” is not great in my opinion, 
> because “ABI” is a term of art for compiler hackers.  Most users have no idea 
> what ABI means, and those who think they do often don’t.  Very few people 
> really understand what “stable ABI” means for 

Re: [swift-evolution] Add transformers to Codable

[Tony Parker via swift-evolution]

Hi Arsen,

What’s the difference between providing a method that takes a transformable 
object on the keyed container protocol and just transforming it yourself before 
you encode it?

- Tony

> On Dec 18, 2017, at 8:51 AM, Arsen Gasparyan via swift-evolution 
>  wrote:
> 
> Hello everyone,
> 
> I’m suggesting to add a new way to encode/decode JSON properties for 
> relevantly complex data formats such as regular expressions, well-known text, 
> hex colours, custom date formats.
> 
> The problem:
> 
> Image you have a struct called House
> 
> struct House {
> let color: UIColor
> }
> 
> and it has a properly called color and the color represented in JSON as hex 
> value (#ff). Currently to make it working you have to extract the 
> underline value (string with a hex value) and then try to make a UIColor from 
> it. It works but it makes you to copy/past a lot of code and it leads to 
> problems. Also it shifts focus from what to decode to how to decode.
> 
> The suggested solution:
> 
> I suggest that we have to introduce protocols for classes that will 
> encapsulate transformation from a source data type to a destination data 
> type. The source data types are all existing data that support of decoding. 
> 
> We will provide only protocols (one for decoding and one for encoding) and 
> users will be able to create transformers for their own data types.
> 
> The implementation:
> 
> The implementation is fairly easy. We only need introduce two protocols 
> (encoding/decoding) and add a method to KeyedEncodingContainerProtocol that 
> will accept a key and a transformer. In the method we will extract source 
> data from JSON and then will ask the transformer to try to convert it to the 
> desire data type.
> 
> Example of the decoding protocol:
> 
> protocol DecodingTransformer {
> associatedtype Input: Decodable
> associatedtype Output
> func transform(_ decoded: Input) throws -> Output
> }
> 
> 
> Inspired by: https://github.com/Hearst-DD/ObjectMapper#custom-transforms 
> 
> 
> Cheers,
> Arsen
> ___
> 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 
> <swift-evolution@swift.org> 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 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 
>> <https://github.com/apple/swift-corelibs-foundation/pull/1301>
>> 
>> Link to implementation for the overlay:
>> 
>> https://github.com/apple/swift/pull/12779 
>> <https://github.com/apple/swift/pull/12779>
>> 
>> Markdown follows.
>> 
>> Thanks,
>> - Tony
>> 
>> # Key Strategies for JSONEncoder and JSONDecoder
>> 
>> * Proposal: SCLF-0001
>> * Author(s): Tony Parker <anthony.par...@apple.com 
>> <mailto:anthony.par...@apple.com>>
>> 
>> # 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 JSONEn

[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] 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] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

[Tony Parker via swift-evolution]

Hi Morten,

I’ve actually been working on this same idea already and will have something to 
propose soon.

- Tony

> On Oct 19, 2017, at 2:03 AM, Morten Bek Ditlevsen via swift-evolution 
>  wrote:
> 
> Hi all,
> At work we have just added Codable support for a whole bunch of model objects 
> in our code base.
> Many places we have added CodingKeys enumeration in order to convert the 
> camel cased property names to snake case for our JSON keys.
> As an experiment I have tried adding a KeyCodingStrategy option to a copy of 
> the JSONEncoder and JSONDecoder implementations.
> This is currently an enumeration with the following values
> .original
> .snakeCase
> .custom((String) -> String)
> 
> I just extended CodingKey as follows:
> extension CodingKey {
> func stringValue(with encodingStrategy: 
> StructuralEncoder.KeyEncodingStrategy) -> String {
> switch encodingStrategy {
> case .original:
> return stringValue
> case .snakeCase:
> let pattern = "([a-z0-9])([A-Z])"
> let regex = try! NSRegularExpression(pattern: pattern, options: 
> [])
> let range = NSRange(location: 0, length: 
> stringValue.characters.count)
> return regex.stringByReplacingMatches(in: stringValue, options: 
> [], range: range, withTemplate: "$1_$2").lowercased()
> case .custom(let t):
> return t(stringValue)
> }
> }
> }
> 
> and then I replaced all references to key.stringValue with 
> key.stringValue(with: self.encoder.options.keyCodingStrategy)
> 
> This seems to work very nicely.
> 
> So my question is: Do anyone else see the benefit of such an addition to the 
> JSONEncoder and JSONDecoder?
> 
> The downside as I see it, is that the current CodingKeys are guaranteed to be 
> unique by the compiler, and it would be possible to create collisions by 
> using key name transforms.
> Is this downside bigger than the gains?
> 
> One advantage is that one could argue that one CodingKey strategy may not fit 
> all serialization mechanisms. For instance one might wish to have upper camel 
> cased keys in Plists (just an example) and snake case in JSON. This method 
> could easily support this, while the current CodingKeys strategy cannot...
> 
> Looking forward to hearing feedback.
> 
> Sincerely,
> /morten
> 
> ___
> 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] [Update] Updates to SE-0166 and SE-0167

[Tony Parker via swift-evolution]

Hi Pitiphong,

> On Jul 13, 2017, at 12:37 AM, Pitiphong Phongpattranont via swift-evolution 
>  wrote:
> 
> Hi swift-evolution,
> 
> I have a few feedbacks on SE-0166 and SE-0167. I’m a library maintainer of a 
> Swift library for my company. We’re a payment gateway service and have a wide 
> range of support library in many programming languages (including Swift).
> 
> Here’re my feedbacks
> 
> 1. The auto synthesized code from the Swift compiler is a great feature but 
> I’m not sure if this is a bug. If I have a property of type 
> Dictionary, the auto synthesize doesn’t work and I need to 
> implement the init(from decoder:) method manually (with code like `metadata = 
> try container.decodeIfPresent([String: Any].self, forKey: .metadata)`) I will 
> report this as a bug on bugs.swift.org 
> 2. In JSONEncoder/Decoder, you can specify the date parsing behavior since 
> there’re many ways to represent this. My thought is that that should apply to 
> `DateComponents` too since there are also many ways to represent 
> `DateComponent` e.g. the ISO8601 also has a spec for parsing the date or time 
> which should map to `DateComponents` type in Swift. And since the 
> DateComponents already conforms to the Decodable protocol so I cannot (and 
> should not) override the system behavior so I need to do the decoding 
> manually on every types that have a property of DateComponents type

Would you be willing to share an example of what your JSON looks like and what 
your resulting DateComponents struct looks like here?

> 3. Since Swift has an associated value enum while many others doesn’t have 
> (including JavaScript which is the mother of JSON), I design our library to 
> use the power of associated value enum as much as possible. This means that 
> there are some types/properties those are built from a multiple properties of 
> a JSON object.

Yah, it’s certainly reasonable to adopt Decodable on an enum with an associated 
value, but I’m not sure if we should try to expand the automatic synthesis to 
handle this case or just ask these kinds of types to implement Decodable 
manually. We’re hoping that the synthesis covers a lot of cases, but it was a 
non-goal to attempt to cover 100% of the possible scenarios this way. We 
focused a lot on making the API usable on its own too.

- Tony

> For example: The status property of Charge is an enum which has a associated 
> value case for `failure` status. So in my library it is built from the 
> `status` and `failureMessage` properties in JSON. For now there is no simple 
> or automatic way (auto synthesized code from Swift Compiler) to do this in 
> Decodable. I need to implement it manually on every types those have this 
> similar properties. And TBH I still don’t have any ideas on how to design the 
> Decodable to support this feature.
> 
> Those are my feedbacks on SE-0166 and SE-0167 for now. I hope my feedbacks 
> would help the Swift and Swift community
> 
> Best regards,
> Pitiphong Phongpattranont
> 
> > Hi swift-evolution,
> > 
> > Over the course of the past few weeks, we’ve been gathering feedback
> > about the outcome of
> > [SE-0166](https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
> >  
> > )
> > and
> > [SE-0167](https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
> >  
> > )
> > (both internally and externally), and we gathered a collection of
> > updates that we’re going to introduce to the proposals and to the
> > implementation.
> > 
> > Attached is rendered HTML (I don’t want to make your mail clients
> > unusable like last time!) that lays out what we’d like to do. We’re
> > not looking to do a full review of these changes, but if you have
> > feedback or questions, we’re happy to get responses here.
> > 
> > Please note that some of these features have already been implemented
> > (the new error types, some of the optionality changes, collection
> > conformances, etc.), but we are receptive to comments on all of it. The
> > existing proposals will also be updated to incorporate these updates.
> > 
> > Thanks for all of your feedback!
> > 
> > — Itai
> > 
> > 
> > 
> ___
> 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 Encoders

[Tony Parker via swift-evolution]

> On Jun 12, 2017, at 8:32 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> The new `JSONSerialization.WritingOptions.sortedKeys` option was mentioned at 
> WWDC.
> 
> "What's New in Cocoa" [33:03 ... 33:33]
> 
> 
> 
> 
> When the `sortedKeys` option is available, can it be used **by default** in 
> the `JSONEncoder`?
> 
> Otherwise, can the `JSONEncoder.OutputFormatting` enum have extra cases?
> 

We intend to make this option available to JSONEncoder as well, but since the 
underlying feature was tied to the OS release we couldn’t pre-announce it.

One nit pick: I don’t think default is the right answer, because sorting has a 
performance cost and we think it’s better to opt-in to the more expensive 
operations.

- Tony

> case compact
> case compactWithSortedKeys
> case prettyPrinted
> case prettyPrintedWithSortedKeys
> 
> 
> 
> -- Ben
> 
>> On 16 Mar 2017, at 22:47, Itai Ferber  wrote:
>> 
>> The sorted order of keys is an implementation detail of 
>> PropertyListSerialization which JSONSerialization does not share.
>> This would require a change in JSONSerialization, which is possible, but out 
>> of scope for this work specifically. It would have to go through review.
>> 
>> [FWIW, the key ordering isn’t changing at random; JSONSerialization writes 
>> keys in the order that it receives them (sorted in the order that 
>> NSDictionary stores them, based on hash). If you want this to not interfere 
>> with your Git repo (on a more immediate timescale), you can probably do 
>> something like adding a pre-commit Git hook to lint the file as needed. But 
>> I digress, this is totally off-topic.]
>> 
>>> On 16 Mar 2017, at 14:57, Ben Rimmington wrote:
>>> 
>>> Sorry, I actually meant that keys would be ordered **alphabetically** (as 
>>> they are with PropertyListSerialization).
>>> 
>>> I'm storing output from JSONSerialization in a git repository, and when I 
>>> add/remove a single key-value the entire file changes, due to keys being 
>>> reordered (seemingly at random).
>>> 
>>> -- Ben
>>> 
 Itai Ferber wrote:
 
 By stable ordering, you mean dictionaries with keys being output in the 
 order that they were encoded?
 Potentially, but this would require additional work as neither Swift 
 dictionaries nor NSMutableDictionary support this (reasonable seeing as 
 dictionaries are by definition not sorted), and the current implementation 
 uses JSONSerialization as the concrete serializer. Certainly not 
 impossible, though.
 
> On 16 Mar 2017, at 8:49, Ben Rimmington wrote:
> 
> 
> 
> Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the 
> **stable ordering** of keys?
> 
> -- 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] Introduction of OrderedSet

[Tony Parker via swift-evolution]

This is still something I want to do, but I suspect it will require some 
coordination work with the NSOrderedSet ref type in Foundation.

Also, as Doug says, there is a larger question too of how we make source 
breaking changes like this in Swift 5 (I think we’re probably out of runway for 
Swift 4 at this point).

We would want to bridge this in from the SDK, but if it follows the pattern of 
our value types, we need to make API changes from the ref type to make it fit 
in correctly with Swift-only concepts like the Collection protocols.

- Tony

> On Jun 9, 2017, at 4:28 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> Let me try to redirect this conversation, if I may.
>> 
>> As far as I can tell, SE-0069 states plainly that the plan of record is to 
>> offer a value type called OrderedSet in Foundation, but resources to design 
>> and implement were not then available.
>> 
>> So, little point in having a vote as to whether one is in favor of 
>> OrderedSet or not. In my view, the questions to be answered are:
>> 
>> For the core team–
>> 
>> * Is it still the plan to offer value types postponed from SE-0069 as a 
>> future addition to Foundation?
> 
> *I* think it’s still a good idea, and I suspect that others on the core team 
> will agree.
> 
>> * If so, is that a priority in the Swift 5 timeframe, and how can the 
>> community help to bring about this addition?
> 
> I wouldn’t consider it a “priority”, in the sense that I can’t imagine 
> anything in Swift 5 that would absolutely require us to introduce this 
> functionality in that time frame. It’s a bit of a nice-to-have-at-any-point, 
> noting of course that bridging NSOrderedSet in existing APIs is a nontrivial 
> source-breaking change.
> 
> Having a proposed API and implementation on hand makes it easier to add this 
> functionality, of course.
> 
>> If not, for the whole community–
>> 
>> * Is it wise to implement such a type in the standard library? Should we 
>> simply bring over the native implementation from Swift Package Manager? What 
>> are the implications for bridging?
> 
> Obviously, we’d want an efficient copy-on-write, native implementation; the 
> Swift Package Manager implementation is a bit more bare-bones than we’d want: 
> absolute performance matters, so having a separate Set + Array in the struct 
> probably isn’t good enough. Bridging performance matters, so we’d probably 
> want the one-pointer representation like array uses where the pointer can be 
> vended directly to Objective-C.
> 
>   - Doug
> 
>> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution 
>> > wrote:
>> +1 for ordered set and dictionary, and please add ordered dictionary in ObjC 
>> as well.
>> 
>> Envoyé de mon iPhone
>> 
>> Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution 
>> > a écrit :
>> 
>>> +1, and would also like to see OrderedDictionary as well.
>>> 
>>> On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution 
>>> > wrote:
>>> 
 I would be in favor of it; there have been a few times (including Core 
 Data, as you mentioned) where I would have used it had it been available.
 
 
 Jeff Kelley
 
 slauncha...@gmail.com  | @SlaunchaMan 
  | jeffkelley.org 
> On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
> > wrote:
> 
> Hello,
> 
> in the past there have been a few requests for an OrderedSet 
> implementation in Swift. In the proposal 
> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>  
> 
>  was mentioned that the OrderedSet will be considered for the feature.
> 
> However, since then there were a few discussions on OrderedSet but it 
> doesn’t get much attention and there wasn’t any comment about it from the 
> swift team.
> 
> I want to bring up some points, why an OrderedSet is needed in the base 
> library.
> 
> 1. CoreData is probably the most obvious place where people would use an 
> ordered set. Especially when working with large amounts of data, 
> presorting can save a lot of time and battery life. If a bridgeable 
> ordered set was part of the standard library we could use a ordered set 
> in swift without having to use the NSOrderedSet from objective c. Which 
> would be pretty nice in my opinion. Even 

Re: [swift-evolution] Revisiting SE-0110

[Tony Parker via swift-evolution]

> On May 31, 2017, at 3:53 PM, John McCall  wrote:
> 
>> On May 31, 2017, at 3:42 PM, Tony Parker > > wrote:
>>> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
 On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution 
 > wrote:
 On Mon, May 29, 2017 at 10:47 PM, Robert Bennett > wrote:
 I think the goal of SE 0110 and to a lesser extent 0066 was to disallow 
 this level of intelligence in the compiler.
 
 Interesting.
 
 I happen to think that the goal of SE–110 
 
  was to make Swift's type system “properly distinguish between functions 
 that take one tuple argument, and functions that take multiple arguments.” 
 Nowhere does that proposal discuss tuple destructuring, and nowhere does 
 it discuss optional parentheses around closure parameter lists.
 
 I might go so far as to say that any commits which *do* affect those 
 things, cannot possibly be correct implementations of the accepted 
 proposal SE–110, because SE–110 did not describe any changes there.
 
 With SE–66 
 
  the case is even more clearcut: that proposal explicitly addresses the 
 question, “Should we require parentheses in closure expression parameter 
 lists?“ and answers it in the negative. The core team’s notes 
 
  on accepting also specify, “The core team did not feel that this proposal 
 needed to include required parentheses within closures, which have their 
 own fairly specific grammar.”
 
 
 While technically feasible, it's not desirable to overload parentheses in 
 this manner.
 
 I strongly disagree. Language features are desirable exactly to the extent 
 that they make life better for developers.
 
 Moreover, parentheses are *already* optional in closure parameter lists. 
 Making them mandatory would be source-breaking for no benefit to 
 programmers. Plus having to write double-parentheses in “dict.map{ ((key, 
 value)) in … }” would be needlessly annoying.
>>> 
>>> This is basically my perspective.  There are language features where we've 
>>> made an intentional decision to require the user to write things in a 
>>> specific way.  Closure parameter lists are not one of them; we've already 
>>> committed to using a very permissive and flexible grammar.  Perhaps that 
>>> was a mistake, but it's a mistake we've made and cannot reasonably undo, 
>>> notwithstanding the proposals that are basically "we should ban 
>>> such-and-such style that, coincidentally, I happen not to use."  In the 
>>> long term, I feel confident that we can deliver an implementation that 
>>> resolves the multiple-parameter vs. tuple-decomposition ambiguity without 
>>> making any significant compromises, but I'm not sure whether we can 
>>> reasonably achieve that in 4.0.
>>> 
>>> John.
>> 
>> As far as I can tell, right now is the earliest possible opportunity for us 
>> to get real feedback on the impact of this proposal.
>> 
>> Therefore, it seems unfortunate that the apparent response is that it is 
>> already too late to fix the problem. Or, perhaps I am misunderstanding?
> 
> I am not trying to say that it is too late to fix the problem.  Some 
> solutions might be off the table, but we need to investigate what we can do.
> 
> John.

Ok, great, I’m glad to hear that.

Thanks,
- Tony

> 
>> 
>> - Tony
>> 
>>> 
 
 In my view there have been far too many calls for making Swift 
 “consistent” in ways that actually make it less enjoyable to use. That is 
 the opposite of “Swifty”, and we should instead prioritize convenience for 
 users above rigid consistency of implementation.
 
 In the case at hand, with Dictionary.map, the vast majority of the time 
 the user doesn’t actually care whether the closure takes two arguments or 
 a single 2-tuple argument. They just know that it takes a key and a value, 
 and they want to be able to write “dict.map{ (key, value) in … }”.
 
 Sure, the closure *does* take a 2-tuple, and it does not take two 
 arguments, but the programmer *using* it shouldn’t have to bother about 
 that distinction most of the time. They just want to assign the key to one 
 identifier and the value to another. If they try to write “key, value” 
 without any parentheses the compiler will complain and they’ll add the 
 

Re: [swift-evolution] Revisiting SE-0110

[Tony Parker via swift-evolution]

> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution 
>> > wrote:
>> On Mon, May 29, 2017 at 10:47 PM, Robert Bennett > > wrote:
>> I think the goal of SE 0110 and to a lesser extent 0066 was to disallow this 
>> level of intelligence in the compiler.
>> 
>> Interesting.
>> 
>> I happen to think that the goal of SE–110 
>> 
>>  was to make Swift's type system “properly distinguish between functions 
>> that take one tuple argument, and functions that take multiple arguments.” 
>> Nowhere does that proposal discuss tuple destructuring, and nowhere does it 
>> discuss optional parentheses around closure parameter lists.
>> 
>> I might go so far as to say that any commits which *do* affect those things, 
>> cannot possibly be correct implementations of the accepted proposal SE–110, 
>> because SE–110 did not describe any changes there.
>> 
>> With SE–66 
>> 
>>  the case is even more clearcut: that proposal explicitly addresses the 
>> question, “Should we require parentheses in closure expression parameter 
>> lists?“ and answers it in the negative. The core team’s notes 
>> 
>>  on accepting also specify, “The core team did not feel that this proposal 
>> needed to include required parentheses within closures, which have their own 
>> fairly specific grammar.”
>> 
>> 
>> While technically feasible, it's not desirable to overload parentheses in 
>> this manner.
>> 
>> I strongly disagree. Language features are desirable exactly to the extent 
>> that they make life better for developers.
>> 
>> Moreover, parentheses are *already* optional in closure parameter lists. 
>> Making them mandatory would be source-breaking for no benefit to 
>> programmers. Plus having to write double-parentheses in “dict.map{ ((key, 
>> value)) in … }” would be needlessly annoying.
> 
> This is basically my perspective.  There are language features where we've 
> made an intentional decision to require the user to write things in a 
> specific way.  Closure parameter lists are not one of them; we've already 
> committed to using a very permissive and flexible grammar.  Perhaps that was 
> a mistake, but it's a mistake we've made and cannot reasonably undo, 
> notwithstanding the proposals that are basically "we should ban such-and-such 
> style that, coincidentally, I happen not to use."  In the long term, I feel 
> confident that we can deliver an implementation that resolves the 
> multiple-parameter vs. tuple-decomposition ambiguity without making any 
> significant compromises, but I'm not sure whether we can reasonably achieve 
> that in 4.0.
> 
> John.

As far as I can tell, right now is the earliest possible opportunity for us to 
get real feedback on the impact of this proposal.

Therefore, it seems unfortunate that the apparent response is that it is 
already too late to fix the problem. Or, perhaps I am misunderstanding?

- Tony

> 
>> 
>> In my view there have been far too many calls for making Swift “consistent” 
>> in ways that actually make it less enjoyable to use. That is the opposite of 
>> “Swifty”, and we should instead prioritize convenience for users above rigid 
>> consistency of implementation.
>> 
>> In the case at hand, with Dictionary.map, the vast majority of the time the 
>> user doesn’t actually care whether the closure takes two arguments or a 
>> single 2-tuple argument. They just know that it takes a key and a value, and 
>> they want to be able to write “dict.map{ (key, value) in … }”.
>> 
>> Sure, the closure *does* take a 2-tuple, and it does not take two arguments, 
>> but the programmer *using* it shouldn’t have to bother about that 
>> distinction most of the time. They just want to assign the key to one 
>> identifier and the value to another. If they try to write “key, value” 
>> without any parentheses the compiler will complain and they’ll add the 
>> parens. But if the compiler demands a *second* set of parentheses, that will 
>> just seem ridiculous.
>> 
>> Nevin
>> ___
>> 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-0110

[Tony Parker via swift-evolution]

> On May 24, 2017, at 1:01 PM, Pavel Yaskevich <pavel.yaskev...@gmail.com> 
> wrote:
> 
> 
> 
> On Wed, May 24, 2017 at 12:57 PM, Tony Parker <anthony.par...@apple.com 
> <mailto:anthony.par...@apple.com>> wrote:
> 
> 
>> On May 24, 2017, at 12:51 PM, Pavel Yaskevich <pavel.yaskev...@gmail.com 
>> <mailto:pavel.yaskev...@gmail.com>> wrote:
>> 
>> Hi Tony,
>> 
>> On Wed, May 24, 2017 at 12:37 PM, Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> The way I interpreted SE-110 is that it was suppose to address anonymous 
>> arguments. 
>> 
>> Instead of using $0.0, $0.1, One needs to use $0, $1 when there are multiple 
>> arguments. 
>> 
>> I was not aware of any implications for explicitly named parameters. 
>> 
>> Perhaps the issue is with the signature of forEach. Does it need to be a 
>> nested tuple?
>> 
>> public func forEach(_ body: ((key: Key, value: Value)) throws -> Void) 
>> rethrows
>> 
>> Jose is right about this one, since the signature of forEach is a tuple 
>> nested into paren it means that `forEach` expects a single argument
>> of a tuple type instead of two arguments, such "tuple argument 
>> destructuring" was supported by Swift 3 but after SE-0110 no longer is
>> because type-checker is preserving top level parens in parameters/arguments. 
>> 
>> Best Regards, Pavel.
> 
> Well, frankly, I don’t think we should ship with such a glaring usability 
> regression.
> 
> What’s the mitigation plan? Perhaps we should wholesale revert it until we 
> have time to reconsider the fallout?
> 
> There is a migrator support, and I've made a couple of diagnostic 
> improvements for it, that produce fix-its which are exactly
> what you see in the aforementioned PR. Otherwise, I'd defer to Slava, who was 
> implementor of SE-0110.
> 

The migrator support resulted in the fix-it below, which I believe is a subpar 
experience for such a core part of using collections and closures in general.

- Tony

>  
> 
> - Tony
> 
>>  
>> 
>> 
>>> On May 24, 2017, at 12:12 PM, Tony Parker via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> We received a pull request in swift-corelibs-foundation which is apparently 
>>> in response to a language change for SE-0110.
>>> 
>>> It turns this perfectly reasonable code:
>>> 
>>> -self.forEach { (keyItem, valueItem) in
>>> 
>>> into this:
>>> 
>>> 
>>> +self.forEach { (arg) in
>>> +let (keyItem, valueItem) = arg
>>> 
>>> Is that really the design pattern we want to encourage? What was wrong with 
>>> the previous code?
>>> 
>>> (https://github.com/apple/swift-corelibs-foundation/pull/995/files 
>>> <https://github.com/apple/swift-corelibs-foundation/pull/995/files>)
>>> 
>>> - Tony
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Tony Parker via swift-evolution]

> On May 24, 2017, at 12:51 PM, Pavel Yaskevich <pavel.yaskev...@gmail.com> 
> wrote:
> 
> Hi Tony,
> 
> On Wed, May 24, 2017 at 12:37 PM, Jose Cheyo Jimenez via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> The way I interpreted SE-110 is that it was suppose to address anonymous 
> arguments. 
> 
> Instead of using $0.0, $0.1, One needs to use $0, $1 when there are multiple 
> arguments. 
> 
> I was not aware of any implications for explicitly named parameters. 
> 
> Perhaps the issue is with the signature of forEach. Does it need to be a 
> nested tuple?
> 
> public func forEach(_ body: ((key: Key, value: Value)) throws -> Void) 
> rethrows
> 
> Jose is right about this one, since the signature of forEach is a tuple 
> nested into paren it means that `forEach` expects a single argument
> of a tuple type instead of two arguments, such "tuple argument destructuring" 
> was supported by Swift 3 but after SE-0110 no longer is
> because type-checker is preserving top level parens in parameters/arguments. 
> 
> Best Regards, Pavel.

Well, frankly, I don’t think we should ship with such a glaring usability 
regression.

What’s the mitigation plan? Perhaps we should wholesale revert it until we have 
time to reconsider the fallout?

- Tony

>  
> 
> 
>> On May 24, 2017, at 12:12 PM, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi everyone,
>> 
>> We received a pull request in swift-corelibs-foundation which is apparently 
>> in response to a language change for SE-0110.
>> 
>> It turns this perfectly reasonable code:
>> 
>> -self.forEach { (keyItem, valueItem) in
>> 
>> into this:
>> 
>> 
>> +self.forEach { (arg) in
>> +let (keyItem, valueItem) = arg
>> 
>> Is that really the design pattern we want to encourage? What was wrong with 
>> the previous code?
>> 
>> (https://github.com/apple/swift-corelibs-foundation/pull/995/files 
>> <https://github.com/apple/swift-corelibs-foundation/pull/995/files>)
>> 
>> - Tony
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Revisiting SE-0110

[Tony Parker via swift-evolution]

Hi everyone,

We received a pull request in swift-corelibs-foundation which is apparently in 
response to a language change for SE-0110.

It turns this perfectly reasonable code:

-self.forEach { (keyItem, valueItem) in

into this:


+self.forEach { (arg) in
+let (keyItem, valueItem) = arg

Is that really the design pattern we want to encourage? What was wrong with the 
previous code?

(https://github.com/apple/swift-corelibs-foundation/pull/995/files 
)

- Tony

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

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Here are the pull requests to cc yourself on:

The compiler and standard library part:

https://github.com/apple/swift/pull/9004 
<https://github.com/apple/swift/pull/9004>

The Foundation part:

https://github.com/apple/swift/pull/9005 
<https://github.com/apple/swift/pull/9005>

- Tony

> On Apr 26, 2017, at 9:26 AM, Shawn Erickson <shaw...@gmail.com> wrote:
> 
> Can you ping the list when aspects of this work lands in master? I have real 
> world code that I want to see how this new stuff shakes out when attempting 
> to use.
> 
> On Wed, Apr 26, 2017 at 9:24 AM Tony Parker via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hi Riley,
> 
>> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I’m sure this has already been discussed, but why are the methods throwing 
>> NSErrors and not Enums? If I’m remembering correctly, the original reason 
>> for this was because this was meant to be a part of Foundation. Now that 
>> this is in the Standard Library, however, it seems strange that we’re still 
>> using NSError.
>> 
>> Second question that again I’m sure was asked and answered already, but: why 
>> do we require implementations for each concrete numeric type (Int, Int8, 
>> Int16, Float, etc), instead of using protocols (such as the new Integer 
>> protocols)?
> 
> To answer your second question, the reason is that using the protocol implies 
> that all encoders and decoders must support anything that conforms to that 
> protocol. We’re not sure this is a reasonable requirement. Many formats do 
> not have any kind of support for arbitrary size integers, for example. 
> Therefore, we felt it was best to limit it to a set of concrete types.
> 
> We could change our minds on this before we ship Swift 4, if we feel it was 
> the wrong decision. Now that the proposals are accepted we will be landing 
> these branches in master soon, which means everyone has a great chance to try 
> it out and see how it feels in real world usage before it’s final.
> 
> - Tony
> 
>> 
>>> On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Proposal Link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>>  
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md>
>>> 
>>> Hello Swift Community,
>>> 
>>> The review of SE-0166 “Swift Archival & Serialization” ran from April 
>>> 6...12, 2017. The proposal is accepted with some minor modifications. 
>>> Specifically, the core protocols and types will be sunk down into the Swift 
>>> standard library for more tight integration with the Swift language and 
>>> compiler, and the operations specifically involving Foundation’s “Data” 
>>> type will be removed. The proposal document has been updated with more 
>>> detail. Thank you everyone for participating in this review!
>>> 
>>> - Doug
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

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

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi Riley,

> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> I’m sure this has already been discussed, but why are the methods throwing 
> NSErrors and not Enums? If I’m remembering correctly, the original reason for 
> this was because this was meant to be a part of Foundation. Now that this is 
> in the Standard Library, however, it seems strange that we’re still using 
> NSError.
> 
> Second question that again I’m sure was asked and answered already, but: why 
> do we require implementations for each concrete numeric type (Int, Int8, 
> Int16, Float, etc), instead of using protocols (such as the new Integer 
> protocols)?

To answer your second question, the reason is that using the protocol implies 
that all encoders and decoders must support anything that conforms to that 
protocol. We’re not sure this is a reasonable requirement. Many formats do not 
have any kind of support for arbitrary size integers, for example. Therefore, 
we felt it was best to limit it to a set of concrete types.

We could change our minds on this before we ship Swift 4, if we feel it was the 
wrong decision. Now that the proposals are accepted we will be landing these 
branches in master soon, which means everyone has a great chance to try it out 
and see how it feels in real world usage before it’s final.

- Tony

> 
>> On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>  
>> 
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0166 “Swift Archival & Serialization” ran from April 
>> 6...12, 2017. The proposal is accepted with some minor modifications. 
>> Specifically, the core protocols and types will be sunk down into the Swift 
>> standard library for more tight integration with the Swift language and 
>> compiler, and the operations specifically involving Foundation’s “Data” type 
>> will be removed. The proposal document has been updated with more detail. 
>> Thank you everyone for participating in this review!
>> 
>>  - Doug
>>  Review Manager
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi Karl,

> On Apr 22, 2017, at 6:23 AM, Karl Wagner <razie...@gmail.com> wrote:
> 
>> 
>> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi everyone,
>> 
>> Thanks for your feedback on this proposal. Based on that plus additional 
>> feedback from core team members and others who responded off-thread, we are 
>> making the following small adjustments:
>> 
>> * KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, 
>> UnkeyedEncodingContainer, UnkeyedDecodingContainer, 
>> SingleValueEncodingContainer, SingleValueDecodingContainer will drop their 
>> Data-taking functions. Data will conform to Codable, so it just goes through 
>> the normal paths like other types.
>> * The above will allow those protocols, plus Encodable, Decodable, typealias 
>> Codable,  Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part 
>> of the standard library (not in Foundation), resolving the concern about 
>> reaching too far up the stack for the compiler.
>> * JSONEncoder/Decoder, PropertyListEncoder/Decoder remain in Foundation. 
>> These are concrete implementations of the above protocols, like the ones 
>> that will appear in many libraries, we hope.
>> 
>> We are not currently proposing using the integer protocols. The reasoning is 
>> that using them them confers a requirement upon all possible encoders and 
>> decoders to support arbitrary-width integers and floating point values. 
>> We’re not convinced this is feasible, but we will continue to evaluate.
>> 
>> If the core team accepts the modified proposal, we will get this merged as 
>> soon as possible with the goal of allowing all of you to try everything out 
>> via Swift’s frequent toolchain snapshots. We will be looking for feedback on 
>> how it works in more real world scenarios, and we will consider further 
>> adjustments to the API before Swift 4 is final. We are hoping that this 
>> extended trial period will allow us to make sure that everything works out 
>> the way we expected.
>> 
>> Thanks,
>> - Tony
> 
> 
> That’s a great step; thanks a lot!
> 
> As for Data/UnsafeRawBufferPointer (beyond this proposal): I agree that a 
> Data object which owns its buffer should be the common-currency for passing 
> buffers around, but I also think that the standard library should own that 
> “Data” type. Data is (IMO), no less "primitive” than, say, Array, Dictionary, 
> Set and String - yet while all of those types are part of the standard 
> library, Data lives much further down the stack, in Foundation. The standard 
> library is limited to unsafe buffers, without a “safe” alternative. Even 
> though Foundation is a core library and very useful, it is still an optional 
> component of any Swift installation or application, and I feel it’s not 
> unreasonable to ask for a safe buffer without that dependency.
> 
> I could of course define my own RAII, UnsafeRawBufferPointer-wrapping “Data” 
> type, but then it either spreads throughout my API and undermines Data as a 
> common currency, or I need to convert it (with a copy, in order to preserve 
> value semantics). This is the same issue that affects DispatchData/Data 
> bridging, which in that case undermines APIs such as DispatchIO; either all 
> of my APIs now take a DispatchData (leaking implementation details), or I 
> have to copy the buffer in to a Foundation Data.
> 

We’re aware of this, but it’s something I’d like to tackle separately from the 
Coding proposals.

> That’s an issue which I would like to help solve more comprehensively one 
> day, but for the mean time:
> 
> 1) Is untyped data really a “primitive” in the context of serialisation? If 
> so...
> 2) Why are we removing it? Is it only because the standard library lacks a 
> good type to represent the data? If so...
> 3) Why not introduce a generic function?
> 
> mutating func encodeBytes(_ bytes: C,  forKey key: Key) throws where C: 
> Collection, C.Element == UInt8
> 
> This single function would be able to encode Data, DispatchData, 
> UnsafeRawBufferPointer, and even an Array.
> 
> - Karl

We considered something along these lines:

func encode(_ value: T?, ...) // existing
func encode(_ value: T?, ...) where 
T.Iterator.Element == UInt8

but this is ambiguous when we have conditional conformance and Array where 
Element : Encodable is Encodable. Did you mean to encode base64-encoded data 
for JSON or an array of UInt8? Data resolves the ambiguity by assigning more 
meaning to a Collection of UInt8.

We could resolve the ambiguity by using a different na

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi Brent,


> On Apr 20, 2017, at 11:37 PM, Brent Royal-Gordon <br...@architechies.com> 
> wrote:
> 
>> On Apr 20, 2017, at 10:08 AM, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> * The above will allow those protocols, plus Encodable, Decodable, typealias 
>> Codable,  Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part 
>> of the standard library (not in Foundation), resolving the concern about 
>> reaching too far up the stack for the compiler.
> 
> I think this is a huge win for Swift and a great move, but...
> 
>> * KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, 
>> UnkeyedEncodingContainer, UnkeyedDecodingContainer, 
>> SingleValueEncodingContainer, SingleValueDecodingContainer will drop their 
>> Data-taking functions. Data will conform to Codable, so it just goes through 
>> the normal paths like other types.
> 
> 
> ...I hope the `Data`-taking primitive will not be deleted, but rather 
> replaced by one that takes `UnsafeRawBufferPointer` or some similar standard 
> library representation of a byte sequence. Even if it has to be called 
> `encodeBytes` and `decodeBytes` to clarify that it's not somehow coding a 
> pointer, I think a series of bytes truly *is* a primitive type, and something 
> fairly distinct from an unkeyed container of `UInt8`s.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

We still believe the right representation for the majority of data use cases is 
Data. UnsafeRawBufferPointer is not really the same thing, because (a) it’s 
unsafe, and (b) it has different mutation characteristics than CoW Data. In any 
case, this change encourages each encoder to decide for itself how to handle 
specific types if they make sense for that format. For example, JSONEncoder 
will switch on the type of the Encodable thing passed to it and do something 
different if it’s Data. It puts Data in the same bucket as things like Date and 
URL as types that some coders may just want to treat specially.

It may be reasonable for the *BufferPointer APIs to adopt Codable themselves 
now. They could encode themselves as [UInt8] by default. Concrete encoders 
(like JSONEncoder) could switch on the type to do something special if they 
want, like base64 encoding them. We could easily propose that as an addition to 
this if we think it’s valuable.

One more thing, which we realized after I sent my original email: the default 
implementation of many of the protocols needs to throw errors. Therefore we 
will add enum EncodingError and enum DecodingError to the list of new types. 
Those enums will have various associated values according to what is useful 
debug information. To preserve the ability for developers to present these 
errors to users with localized and user-presentable messages, when these enums 
are cast to NSError (e as? NSError), they will have the Cocoa error domain and 
a Foundation-provided code. (This is done via an extension to the enum in 
Foundation).

- Tony

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi everyone,

Thanks for your feedback on this proposal. Based on that plus additional 
feedback from core team members and others who responded off-thread, we are 
making the following small adjustments:

* KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, 
UnkeyedEncodingContainer, UnkeyedDecodingContainer, 
SingleValueEncodingContainer, SingleValueDecodingContainer will drop their 
Data-taking functions. Data will conform to Codable, so it just goes through 
the normal paths like other types.
* The above will allow those protocols, plus Encodable, Decodable, typealias 
Codable,  Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part of 
the standard library (not in Foundation), resolving the concern about reaching 
too far up the stack for the compiler.
* JSONEncoder/Decoder, PropertyListEncoder/Decoder remain in Foundation. These 
are concrete implementations of the above protocols, like the ones that will 
appear in many libraries, we hope.

We are not currently proposing using the integer protocols. The reasoning is 
that using them them confers a requirement upon all possible encoders and 
decoders to support arbitrary-width integers and floating point values. We’re 
not convinced this is feasible, but we will continue to evaluate.

If the core team accepts the modified proposal, we will get this merged as soon 
as possible with the goal of allowing all of you to try everything out via 
Swift’s frequent toolchain snapshots. We will be looking for feedback on how it 
works in more real world scenarios, and we will consider further adjustments to 
the API before Swift 4 is final. We are hoping that this extended trial period 
will allow us to make sure that everything works out the way we expected.

Thanks,
- Tony

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi Rex,

> On Apr 10, 2017, at 12:48 PM, Rex Fenley via swift-evolution 
>  wrote:
> 
> Forgive me if I'm missing something, this is a very large proposal and a lot 
> to parse through. I like how everything is designed as far as I can tell 
> except I'm not sure from this proposal how one would compose multiple 
> different types of Decoders against the same output type. For example, with 
> Location we have.
> 
> // Continuing examples from before; below is automatically generated by the 
> compiler if no customization is needed.
> public struct Location : Codable {
>   private enum CodingKeys : CodingKey {
> case latitude
> case longitude
> }
> 
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> latitude = try container.decode(Double.self, forKey: .latitude)
> longitude = try container.decode(Double.self, forKey: .longitude)
> }
> }
> 
> However, this initializer seems strictly tied to the `CodingKeys` set of 
> coding keys. From what it appears, if this was used to decode from JSON the 
> format would have to always be:
> 
> {
>   "latitude" : 20.0
>   "longitude" : 20.0
> }
> 
> I have a use case we're on my client we began the process of switching from 
> one version of an API to another. In one version we had a payload similar to
> 
> {
>   "user" : {
>   "uuid" : "uuid string..."
>   "can_send_message" : true
>   "can_delete_message" : false
>   }
> }
> 
> this would result in the following Codable (from "user") from what I'm 
> following
> 
> public struct User : Codable {
>   private enum CodingKeys : CodingKey {
> case uuid
> case can_send_message
> case can_delete_message
> }
> 
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> uuid = try container.decode(Double.self, forKey: .uuid)
> canSendMessage = try container.decode(Bool.self, forKey: 
> .can_send_message)
> canDeleteMessage = try container.decode(Bool.self, forKey: 
> .can_delete_message)
> }
> }
> 
> when we began switching over to the new api the payload was returned as
> 
> {
>   user {
>   "uuid" : "uuid string..."
>   "permissions" : {
>   "can_send_message" : true
>   "can_delete_message" : false
>   }
>   }
> }
> 
> Here with "permissions" we have a new internal container with a separate set 
> of coding keys. Issue is in my use case I still need to maintain a way to 
> decode the old version simultaneously; we guard all new changes behind 
> feature flags in case something goes awry and we need to roll back our 
> changes.
> 
> How would one go about expressing this new Decoding and the previous Decoding 
> simultaneously on the same User type?

You would fall out of the automatically-generated scenario here, but this use 
case is exactly what the ‘container’ API is for. You can create a container 
with a new set of keys, then decode from it.

Another approach would be to create a nested type that conforms with Codable 
which represents the “permissions” as a type of its own.

- Tony

> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> 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 Encoders

[Tony Parker via swift-evolution]

Hi David,

> On Apr 4, 2017, at 10:33 PM, David Hart via swift-evolution 
>  wrote:
> 
> Very interesting discussion below. Here are a few more points:
> 
> Sent from my iPhone
> On 4 Apr 2017, at 23:43, Itai Ferber via swift-evolution 
> > wrote:
> 
>> Hi Brent,
>> 
>> Thanks for your comments and thorough review! :)
>> Responses inline.
>> 
>> On 4 Apr 2017, at 1:57, Brent Royal-Gordon wrote:
>> 
>> 
>> On Apr 3, 2017, at 1:31 PM, Itai Ferber via swift-evolution 
>> > wrote:
>> Hi everyone,
>> 
>> With feedback from swift-evolution and additional internal review, we've 
>> pushed updates to this proposal, and to the Swift Archival & Serialization 
>> proposal.
>> Changes to here mostly mirror the ones made to Swift Archival & 
>> Serialization, but you can see a specific diff of what's changed here. Full 
>> content below.
>> 
>> We'll be looking to start the official review process very soon, so we're 
>> interested in any additional feedback.
>> 
>> Thanks!
>> 
>> — Itai
>> 
>> This is a good revision to a good proposal.
>> 
>> I'm glad `CodingKey`s now require `stringValue`s; I think the intended 
>> semantics are now a lot clearer, and key behavior will be much more reliable.
>> 
>> Agreed
>> 
>> 
>> I like the separation between keyed and unkeyed containers (and I think 
>> "unkeyed" is a good name, though not perfect), but I'm not quite happy with 
>> the unkeyed container API. Encoding a value into an unkeyed container 
>> appends it to the container's end; decoding a value from an unkeyed 
>> container removes it from the container's front. These are very important 
>> semantics that the method names in question do not imply at all.
>> 
>> I think that consistency of phrasing is really important here, and the 
>> action words "encode" and "decode" are even more important to connote than 
>> the semantics of pushing and popping.
>> (Note that there need not be specific directionality to an unkeyed container 
>> as long as the ordering of encoded items is eventually maintained on 
>> decode.) But on a practical note, names like encodeAtEnd and decodeFromFront 
>> (or similar) don't feel like they communicate anything much more useful than 
>> the current encode/decode.
>> 
>> 
>> Certain aspects of `UnkeyedDecodingContainer` also feel like they do the 
>> same things as `Sequence` and `IteratorProtocol`, but in different and 
>> incompatible ways. And I certainly think that the `encode(contentsOf:)` 
>> methods on `UnkeyedEncodingContainer` could use equivalents on the 
>> `UnkeyedDecodingContainer`. Still, the design in this area is much improved 
>> compared to the previous iteration.
>> 
>> Which aspects of Sequence and IteratorProtocol do you feel like you're 
>> missing on UnkeyedDecodingContainer? Keep in mind that methods on 
>> UnkeyedDecodingContainer must be able to throw, and an 
>> UnkeyedDecodingContainercan hold heterogeneous items whose type is not 
>> known, two things that Sequence and IteratorProtocol do not do.
>> 
>> In terms of an equivalent to encode(contentsOf:), keep in mind that this 
>> would only work if the collection you're decoding is homogeneous, in which 
>> case, you would likely prefer to decode an Array over getting an unkeyed 
>> container, no? (As soon as conditional conformance arrives in Swift, we will 
>> be able to express extension Array : Decodable where Element : Decodable { 
>> ... } making decoding homogeneous arrays trivial.)
>> 
>> 
>> (Tiny nitpick: I keep finding myself saying "encode into", not "encode to" 
>> as the API name suggests. Would that be a better parameter label?)
>> 
>> On a personal note here — I agree with you, and had originally used "into". 
>> However, we've reviewed our APIs and more often have balanced from:/to: 
>> rather than from:/into: on read/write/streaming calls. We'd like to rein 
>> these in a bit and keep them consistent within our naming guidelines, as 
>> much as possible.
>> 
>> 
>> I like the functionality of the `userInfo` dictionary, but I'm still not 
>> totally satisfied casting out of `Any` all the time. I might just have to 
>> get over that, though.
>> 
>> I think this is the closest we can get to a pragmatic balance between 
>> dynamic needs and static guarantees. :)
>> 
>> 
>> I wonder if `CodingKey` implementations might ever need access to the 
>> `userInfo`. I suppose you can just switch to a different set of `CodingKeys` 
>> if you do.
>> 
>> I don't think CodingKey should ever know about userInfo — CodingKeys should 
>> be inert data. If you need to, use the userInfo to switch to a different set 
>> of keys, as you mention.
>> 
>> 
>> Should there be a way for an `init(from:)` implementation to determine the 
>> type of container in the encoder it's just been handed? Or perhaps the 
>> better question is, do we want to promise users that all decoders can 

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

[Tony Parker via swift-evolution]

Hi Oliver,

> On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution 
>  wrote:
> 
> Like everyone I’m excited by this new proposal.  But…
> 
> > protocol Codable: Adopted by types to opt into archival. Conformance may be 
> > automatically derived in cases where all properties are also Codable.
> 
> … can I make one suggestion.  Please do not repeat the mistakes of NSCoding 
> in combining the encoding and decoding into a single protocol.  Just as there 
> are Encoder and Decoder classes their should be Encodable and Decodable 
> protocols (maybe have an aggregate Codable protocol for convenience but do 
> not force it).
> 
> My reasoning:
> 
> Sometimes you only want to decode or encode and object and not vice versa.  
> This is often the case with Web APIs and JSON serialisation.  
> 
> Eg:
> 
> Often an app only consumes (decodes) JSON encoded objects and never writes 
> them out (a read only app for example). So the encode(to:) methods are 
> completely redundant and someone adopting Codable should not be forced to 
> write them.  
> 
> If only I had a dollar for all the times I’ve seen this sort of code in 
> projects:
> 
> class MyClass : NSCoding {
> init?(coder: NSCoder) {
>   // ... some decoding code
> }
> 
> func encode(with aCoder: NSCoder) {
>preconditionFailure(“Not implemented”)
> }
> }
> 
> 
> Another example: 
> 
> Web APIs often take data in a different structure as input (i.e. “Request” 
> objects) than they output.  These request objects are only ever encoded and 
> never decoded by an application so implementing init(from:) is completely 
> redundant.
> 
> Personally I think the approach taken by libraries like Wrap 
> (https://github.com/johnsundell/wrap ) 
> and Unbox (https://github.com/JohnSundell/Unbox 
> ) is a much better design.  Encoding 
> and decoding should not be the same protocol.
> 
> Yes I understand that Codable could provide no-op (or preconditionFailure) 
> protocol extension based default implementations of init(from:) and 
> encode(to:) (or try to magic up implementations based on the Codable nature 
> of public properties as suggested in the proposal) but to me that seems like 
> a hack that is papering over bad design.  I think this joint Codable design 
> probably fails the Liskov substitution principle too.
> 
> So I again implore you to consider splitting Codable into two protocols, one 
> for encoding and another for decoding.
> 
> Sorry if I’m repeating what other people have already said.  I’ve not read 
> every response to this proposal on the list.
> 
> Regards

Thanks for your feedback. We are indeed considering splitting this up into 3 
protocols instead of 1 (“Encodable", “Decodable", "Codable : Encodable, 
Decodable”).

The main counterpoint is the additional complexity inherent in this approach. 
We are considering if the tradeoff is worth it.

- Tony


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

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

[Tony Parker via swift-evolution]

Hi Kenny,

> On Mar 19, 2017, at 9:53 PM, Kenny Leung via swift-evolution 
>  wrote:
> 
> Hi All.
> 
> Forgive me if I missed it - I haven’t read the proposal in full detail - but 
> it seems to make no mention of archiving graphs with circular references. Is 
> this implicitly supported, or explicitly unsupported?
> 

We expect this to be left up to the encoders and decoders. In Foundation 
itself, we actually have subclasses of NSCoder that support this and subclasses 
that do not.

> While we’re at it, my only real exposure to archiving is through Foundation, 
> so I’d like to know how everybody else understands these terms:
> 
> serialization - the process of “flattening” out an object graph into a serial 
> stream of objects
> 
> encoding - the process of converting internal object data into an external 
> format
> 
> archiving - the whole enchilada of serialization + encoding
> 
> Thanks!
> 
> -Kenny

Good question about terminology. Here is how we’ve tried to define these:

Serialization: conversion of a small fixed set of types to a data format and 
back
ex. NSJSONSerialization, NSPropertyListSerialization

Encoding: conversion of an arbitrary type to a smaller set of serialized types 
and back
ex: Encoder, Decoder, JSONEncoder, PropertyListEncoder

Archiver: In the ObjC Foundation, the objects which do the encoding. In this 
proposal we have chosen not to re-use this term to avoid confusion. Instead we 
tried to simplify the terminology by calling the top level concrete object an 
encoder.

- Tony

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

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

[Tony Parker via swift-evolution]

> On Mar 19, 2017, at 12:14 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On Mar 19, 2017, at 10:47 AM, Tony Parker  > wrote:
> 
>> Hi Matthew, Brent,
>> 
>> I see why you are asking for this Context parameter, but putting it into the 
>> basic Codable protocol introduces too much conceptual overhead. There are 
>> too many benefits to keeping adoption to just one protocol, including 
>> discoverability, ease of use, reducing the need for overloads on protocols 
>> elsewhere, and more. Supporting this one use case does not outweigh those 
>> benefits, especially considering I expect that most library code would not 
>> use it (as you say: it would be weird to pass this context between modules).
>> 
>> Can you figure out a way to get the context info passed through the 
>> encoder/decoder instead? It would make more sense as something optionally 
>> retrieved from the encoder/decoder that was set at the top level.
> 
> Hi Tony.  I can see the argument that the this is a feature that should be 
> relatively rarely used and thus should have as simple a design as possible.
> 
> If you feel like the impact of threading a typed context on the API surface 
> area is too heavy you could just add a `var context: Any? { get }` 
> requirement to Encoder and Decoder.  The expectation is that encoders and 
> decoders would accept a context in the top level call and make it available 
> to all Codable types.  This would solve the problem with minimal API impact 
> at the cost of the ability to statically verify that all types receive the 
> context they need to encode / decode correctly.
> 
> I much prefer the static safety but having a solution is better than not 
> having one.  :)

The Any context property is reasonable, but it would be nice to find something 
in the middle. =)

One other possibility is that we define a user info dictionary instead, with a 
custom key type that can be extended (much like our string enumerations). In 
general I haven’t been a fan of the user info pattern in Swift because of the 
necessity to cast, but as you say it’s better than nothing. e.g. userInfo : 
[CodingUserInfoKey: Any].

- Tony

> 
>> 
>> - Tony
>> 
>>> On Mar 17, 2017, at 5:56 PM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 
 On Mar 17, 2017, at 6:15 PM, Brent Royal-Gordon > wrote:
 
> On Mar 17, 2017, at 3:35 PM, Matthew Johnson  > wrote:
> 
>> In all seriousness, I see the design as very slightly weak, in that it 
>> makes it easy to forget to pass a context through, but quite acceptable. 
> 
> Easy for who?  I was not requiring Codable types to thread it through at 
> all.  The context was fully managed by the Encoder / Decoder type.  The 
> only place Codable types work with the context is as an argument they 
> receive.  They never pass it when encoding or decoding anything.  The 
> Encoder / Decoder would need to store the context internally and when 
> call is made to encode / decode a ContextAwareCodable it would pass the 
> result of a dynamic cast to ContextAwareCodable.Context as the context.
 
 Oh, I see. Sorry, I missed that when I was looking at your design.
 
 In practice, in my design, you would only need to manually pass a context 
 to `encode(_:forKey:with:)` if the context was of a different type than 
 `self`’s. 
>>> 
>>> Oh, I see.  I missed that part of your design.  I really like it with the 
>>> shorthands.  I’m fully on board with this being the right way to handle 
>>> contexts now.  I think Context should be in the basic Codable protocol.  
>>> That leaves the question of what to do with NSKeyedArchiver and 
>>> NSKeyedUnarchiver.  I’m not sure what the answer is for those but it would 
>>> be unfortunate to see the design compromised solely because of a 
>>> requirement to interoperate with them.
>>> 
 This would probably happen at module or subsystem boundaries. Imagine, for 
 instance, that your FooKit module (for interacting with the foo.io 
  web service) needs to encode a GeoKit.Location instance, 
 but both FooKit and GeoKit need information from a context to encode 
 themselves properly, and they use different context types. When FooKit 
 encoded a GeoKit.Location, it could construct and pass a GeoKit context.
 
 I believe that in your design, unless the FooKit context was a subtype of 
 the GeoKit context, you wouldn't be able to get GeoKit.Location to do the 
 right thing.
>>> 
>>> Right.  It was assuming only one context would be needed for an entire 
>>> encoding / decoding process.  I don’t know of use cases where one module 
>>> could meaningfully 

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

[Tony Parker via swift-evolution]

Hi Matthew, Brent,

I see why you are asking for this Context parameter, but putting it into the 
basic Codable protocol introduces too much conceptual overhead. There are too 
many benefits to keeping adoption to just one protocol, including 
discoverability, ease of use, reducing the need for overloads on protocols 
elsewhere, and more. Supporting this one use case does not outweigh those 
benefits, especially considering I expect that most library code would not use 
it (as you say: it would be weird to pass this context between modules).

Can you figure out a way to get the context info passed through the 
encoder/decoder instead? It would make more sense as something optionally 
retrieved from the encoder/decoder that was set at the top level.

- Tony

> On Mar 17, 2017, at 5:56 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Mar 17, 2017, at 6:15 PM, Brent Royal-Gordon > > wrote:
>> 
>>> On Mar 17, 2017, at 3:35 PM, Matthew Johnson >> > wrote:
>>> 
 In all seriousness, I see the design as very slightly weak, in that it 
 makes it easy to forget to pass a context through, but quite acceptable. 
>>> 
>>> Easy for who?  I was not requiring Codable types to thread it through at 
>>> all.  The context was fully managed by the Encoder / Decoder type.  The 
>>> only place Codable types work with the context is as an argument they 
>>> receive.  They never pass it when encoding or decoding anything.  The 
>>> Encoder / Decoder would need to store the context internally and when call 
>>> is made to encode / decode a ContextAwareCodable it would pass the result 
>>> of a dynamic cast to ContextAwareCodable.Context as the context.
>> 
>> Oh, I see. Sorry, I missed that when I was looking at your design.
>> 
>> In practice, in my design, you would only need to manually pass a context to 
>> `encode(_:forKey:with:)` if the context was of a different type than 
>> `self`’s. 
> 
> Oh, I see.  I missed that part of your design.  I really like it with the 
> shorthands.  I’m fully on board with this being the right way to handle 
> contexts now.  I think Context should be in the basic Codable protocol.  That 
> leaves the question of what to do with NSKeyedArchiver and NSKeyedUnarchiver. 
>  I’m not sure what the answer is for those but it would be unfortunate to see 
> the design compromised solely because of a requirement to interoperate with 
> them.
> 
>> This would probably happen at module or subsystem boundaries. Imagine, for 
>> instance, that your FooKit module (for interacting with the foo.io 
>>  web service) needs to encode a GeoKit.Location instance, 
>> but both FooKit and GeoKit need information from a context to encode 
>> themselves properly, and they use different context types. When FooKit 
>> encoded a GeoKit.Location, it could construct and pass a GeoKit context.
>> 
>> I believe that in your design, unless the FooKit context was a subtype of 
>> the GeoKit context, you wouldn't be able to get GeoKit.Location to do the 
>> right thing.
> 
> Right.  It was assuming only one context would be needed for an entire 
> encoding / decoding process.  I don’t know of use cases where one module 
> could meaningfully provide a context to another module unless they were very 
> closely related (i.e. built as parts of the same system) but maybe they do 
> exist.  Your design is able to accommodate this very well.
> 
> I made some compromises to try and diverge from the current proposal as 
> little as possible while still solving the primary use cases I’m aware of.  
> Now that I understand your design I think it has enough advantages that we 
> should go in that direction.  And we certainly should not go in the direction 
> of something that requires Any.
> 
>> 
>> If that weren't the case—if you were encoding a type with a matching 
>> context, or with a `Void` context—you could use the two convenience methods, 
>> which would handle the context argument for you. So threading contexts would 
>> only be necessary in a relatively rare case.
> 
> Yep, that’s very elegant!
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
> ___
> 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

[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

[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

[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

[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] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

[Tony Parker via swift-evolution]

I’m concerned about the large source compatibility impact this change would 
have. Even if we claim that it’s only for Swift 4, migration would be 
difficult. Even if it were just a warning, that could be extremely noisy for 
large projects.

What do you propose to mitigate that problem?

I also think that before proceed with this change any further, we should have a 
lot more data about the impact that it has on real world applications in 
general. How many places use as for bridging now? What alternative approach 
would they use? We should see a diff of some of that real world code and see if 
we actually like the result. I’m not convinced that it is wrong, semantically, 
to use an as cast to indicate the conversion of a reference type to a value 
type. As is used to indicate type conversion. Bridging is a side effect, yes, 
but warning on this change may just feel pedantic without actually improving 
the situation.

And finally, as you and I have discussed separately, I don’t believe we should 
confuse the issue of what happens when bridging NSNumber into Swift with the 
issue of if ‘as’ bridges or not. The Foundation team believes there is a lot of 
room for improvement in the behavior of ‘as’ casting for NSNumber that would 
provide a more predictable and safer answer.

- Tony

> On Mar 1, 2017, at 8:11 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> I’d like to investigate separating Objective-C bridging from the behavior of 
> the as/as?/is operator family again for Swift 4. Last year, I proposed 
> SE–0083 
> ,
>  but we deferred the proposal for lack of time to evaluate its impact. As 
> complicating factors, we now have source compatibility with Swift 3 as a 
> requirement, and the id-as-Any work from SE–0116 
> 
>  more or less requires bridging dynamic casts to work. I think we can 
> nonetheless make important improvements in this area in order to simplify the 
> core language and provide more portable behavior across platforms with and 
> without ObjC interop. In retrospect, submitting SE–0083 as an omnibus “fix 
> casting” proposal was a mistake. We can separate out a few smaller 
> subproblems from the overall concept:
> 
> Replacing as for bridging coercion
> 
> Swift 0 shipped with implicit conversions between standard library value 
> types and their bridged Cocoa classes in both directions, and as we’ve eased 
> off of the implicit conversions, we still left the as operator with the 
> ability to force the conversions. This complicates the meaning of as: 
> normally, it just provides type context, but it also has the power to force 
> bridging conversions. These meanings are often at odds:
> 
> // `NSNumber` is `ExpressibleByIntegerLiteral`, so this gives type context to 
> the literal 0
> // and is equivalent to `NSNumber(integerLiteral: 0)`
> 0 as NSNumber
> 
> // `x` already has type `Int`, so this forces the bridging conversion and is 
> equivalent to
> // `_bridgeToObjectiveC(x)` (and thereby gives you a different kind of 
> `NSNumber`!)
> let x: Int = 0
> x as NSNumber
> Aside from the complexity and non-portability of this behavior, this is also 
> inconsistent with the Swift naming conventions, which recommend that 
> conversions between related types be presented as initializers. Additionally, 
> the bridging conversions often have specialized behavior for performance or 
> semantic reasons that aren’t intended to be exposed in the normal API of 
> either type (for example, bridging a Swift number type to NSNumber produces a 
> “type-preserving” instance of NSNumber so that the bridge doesn’t lose type 
> information, even though NSNumber’s own API presents a type-agnostic numeric 
> object). Therefore, I propose that we remove the bridging behavior from as, 
> and provide APIs for conversion where they don’t yet exist. as is purely a 
> compile-time construct with no runtime interaction, so the Swift 3 
> compatibility and ABI issues are much simpler than they are when runtime 
> casting behavior becomes involved.
> 
> Warning on is/as?/as! casts that statically induce bridging
> 
> Without changing the runtime behavior of casting, we could still discourage 
> users from using dynamic casting to perform bridging conversions when it’s 
> statically evident that a bridging conversion is the only way a cast 
> succeeds. For example:
> 
> func abuseBridgingCasts(on object: AnyObject) {
> // warning: dynamic cast requires a bridging conversion; use 
> `Int(bridgedFrom:)` instead
> let _ = object as? Int
> }
> This wouldn’t be perfect, since we wouldn’t be able to warn about fully 
> dynamic casts, but it could help encourage users to write portable code that 
> doesn’t rely on the Objective-C bridge in common situations.
> 
> Limiting when the runtime allows 

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

[Tony Parker via swift-evolution]

It seems like the main complaints about NSProgress revolve around KVO, which 
there is no question about not being right for Swift in many ways. I’m aware of 
that. I think the right answer there is instead to improve KVO in Swift, not to 
replace all KVO in the SDK on a case-by-case basis with ad-hoc observation 
mechanisms. I acknowledge that improving KVO is not a small task.

Responding to some of the other notes in your description:


* KVO

NSProgress does not use KVO to update its parent progress objects. You can 
actually see this in the swift-corelibs-foundation version of NSProgress. It 
does post notifications for its properties this way though.

* Implicit tree composition

I agree that implicit tree composition is not a great idea except in very 
controlled circumstances. That’s why I introduced the explicit API.

* Explicit tree composition

It looks like you’ve used this incorrectly. The reason the ProgressReporting 
protocol exists is for types to expose a progress that the caller can then 
compose into their own progress tree. There is no requirement to use it, but it 
establishes the pattern.

// disclaimer: typed in Mail
class X {
var progress: Progress {
let p = Progress.discreteProgress(totalUnitCount: 10)
// start with some progress
p.completedUnitCount = 5
}
}

var x = X()
var p = Progress.discreteProgress(totalUnitCount: 2)
var childA = Progress(totalUnitCount: 4, parent: p, pendingUnitCount: 1) // 
childA is 50% of p
p.addChild(x.progress, pendingUnitCount: 1) // x.progress is 50% of p

p.fractionCompleted // 0.25

* Updating progress in a tight loop

No matter how efficient you make updating the properties (and, again, I 
acknowledge that KVO support adds a cost here), the fact that progress forms 
trees and the trees are designed to be arbitrarily large, means that you should 
always consider the cost of updating too frequently. Reducing the cost per 
update is still a noble goal. As is reducing autoreleases.

* Updating completedUnitCount atomically

The best practice here is to keep the progress object thread local. I think 
that updating one progress from multiple threads could be a code smell. Perhaps 
then you are doing several parts of the work and you should instead form a 
tree. This also leads in a direction where completed unit count is either 100% 
handed out to children or 100% controlled by your work-update-progress loop. 
Mixing the two leads to easy confusion about who is responsible for which 
portion. If you follow this rule, you never have to get the completed unit 
count, which means the race you describe does not exist.


> On Feb 21, 2017, at 2:25 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Feb 21, 2017, at 3:52 PM, Rod Brown > > wrote:
>> 
>> It still holds the fundamental oddities of NSProgress that I find weird. 
>> Like "current progress" always strikes me as very odd concept.
> 
> The “current progress” bit is there mainly for source compatibility. I’d 
> expect it would not be the norm for new code.
> 
>> I'd be interested to see what Tony Parker and the Core Team think!
> 
> So would I.
> 
> Charles
> 
> ___
> 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: Replacement for FileHandle

[Tony Parker via swift-evolution]

> On Feb 15, 2017, at 2:25 PM, Charles Srstka  wrote:
> 
>> On Feb 15, 2017, at 3:11 PM, Itai Ferber > > wrote:
>> 
>> FYI, Tony is the manager of the Foundation team. :)
>> We care very much about making sure that the experience of using our 
>> framework is a positive one — the more Radars we get, the better we can 
>> prioritize improving APIs that are not working as well as they could be for 
>> our users. Even if the Radar gets duped to an existing one, thats one more 
>> +1 for that Radar saying "this is a problem".
>> 
> Yeah I know, but it’s a frustrating experience, spending a half hour writing 
> a detailed bug report (sometimes with videos attached to demonstrate the 
> issue), just to effectively do the same thing as spending 5 seconds to hit 
> the +1 button on most issue trackers you come across.
> 
> Especially since you never find out what happened to the original bug report. 
> You can see if it’s open or closed, but did they fix it in some internal 
> build? Did they decide it “behaves correctly?” Did somebody just skim your 
> report, and mistakenly attach it to some other, unrelated issue? There’s no 
> way to know.
>> I will search for your old Radar, but in any case, please do file a new one 
>> about this, and about any other issues you have, because we are indeed 
>> listening.
>> 
> 
> I was pretty sure I'd submitted something way, way back in the misty days of 
> yore, but I can’t find it. I’ve filed a couple of new ones: rdar://30543037 
>  and rdar://30543133 .
> 
> Charles
> 

Thanks for filing these.

Sometimes, for process reasons, we do indeed mark bugs as dupes of other ones. 
Usually the polite thing to do is to dupe to the earliest filed one. Sometimes 
this comes across with an appearance of not caring to the filer of the new bug, 
but our intent is simply to consolidate the reports we have so that we know 
that the issue is serious.

We do not make API changes without going through a vigorous review process, to 
avoid churn for the many clients above us. The flip side is that this can take 
some time. I’m sure you understand that all software engineering is about 
tradeoffs.

All of that said, we’ll take a look at these and see what improvements we can 
make here. As I said, I’m not a fan of exception-based API.

- Tony


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

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker via swift-evolution]

Hi Charles,

Have you happened to file a radar for Foundation that I can look up (for both 
this and process)?

We are working hard on making sure that our API is right for Swift, and areas 
like this where we can make fairly trivial improvements are things that we can 
try to prioritize. As you say, the purpose of swift-corelibs-foundation is to 
present a unified API and prevent the need to fork. That means the best 
possible solution is to improve the API in Objective-C (where 
exceptions-as-control flow is wrong too) first, and then naturally flow that 
into Swift.

Thanks,
- Tony

> On Feb 14, 2017, at 12:46 PM, Charles Srstka  wrote:
> 
>> On Feb 14, 2017, at 1:05 PM, Tony Parker > > wrote:
>> 
>> Hi Charles,
>> 
>> For both this and the Process proposal - why would we not just improve the 
>> API on the existing types instead of renaming them?
>> 
>> - Tony
> 
> 1) The Objective-C Foundation isn’t open source. It’s now 14 years since the 
> introduction of NSError, and those types still throw exceptions when they hit 
> runtime errors, despite the community consistently complaining about this 
> during the intervening decade and a half. I just don’t think it’s going to 
> happen. Those of us that asked for the change have mostly given up and 
> resigned ourselves to either writing our own file handle classes or using 
> exception handling for these things years ago (I would presume the problem is 
> backwards compatibility; there might be some legacy code out there that 
> depends on the exceptions being thrown, and that might prevent the change—an 
> issue that doesn’t exist for Swift code, since it can’t catch exceptions). 
> The Swift solution would start from code which is open-source, meaning that 
> implementation could be done by the community, without depending on the 
> Foundation team.
> 
> 2) For any changes that are made to the API for the Objective-C types, the 
> same changes will have to be made to the corelibs types anyway for 
> cross-platform source compatibility. Presumably, the unimplemented parts in 
> corelibs are going to need to be implemented as well in order for that 
> project to be complete. So why not kill two birds with one stone?
> 
> Charles
> 

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

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker via swift-evolution]

> On Feb 14, 2017, at 7:18 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> MOTIVATION:
> 
> In Swift 3, NSFileHandle was renamed to FileHandle, making it the de facto 
> file handle class for use in Swift applications. Unfortunately, it’s not a 
> very good API. NSFileHandle supports no error reporting whatsoever, instead 
> throwing Objective-C exceptions whenever something goes wrong during reading 
> or writing. There is no way that I know of to catch these exceptions in 
> Swift, meaning that if a write failed because the disk ran out of space or 
> something, there’s no way to deal with that other than crashing the whole 
> application.
> 
> In addition, NSFileHandle’s asynchronous API is broken. It provides a 
> readabilityHandler property which allows blocks-based reading of files, but 
> this handler does not provide any way to detect when the end of the file is 
> reached, which makes it not useful for many applications.
> 
> PROPOSED SOLUTION:
> 
> Rename FileHandle back to NSFileHandle, and provide a Swift-native FileHandle 
> class for Foundation in Swift 4 that mimics NSFileHandle’s interface, but 
> provides throwing versions of all the read and write methods:
> 
> open class FileHandle : NSObject, NSSecureCoding {
> open func readDataToEndOfFile() throws -> Data
> 
> open func readData(ofLength length: Int) throws -> Data
> 
> open func write(_ data: Data) throws
> 
> // etc.
> }
> 

Hi Charles,

For both this and the Process proposal - why would we not just improve the API 
on the existing types instead of renaming them?

- Tony

> Much of the work for this is already done, in the swift-corelibs-Foundation 
> project. The main thing that would need to be done for the synchronous APIs 
> would be simply to replace the fatalErrors with throws, a simple enough 
> operation. The asynchronous  read/write APIs are still unimplemented in 
> corelibs, but given that a new implementation of those based on DispatchIO 
> could be engineered in such a way that it would correctly report EOF, the 
> benefits to the end-user would likely justify the expense.
> 
> For backward source compatibility, the existing, non-throwing APIs could be 
> provided as well, but deprecated. These could simply call the throwing APIs 
> and either call fatalError() or throw an NSException when an error is caught.
> 
> Since FileHandle is just a wrapper around a file descriptor, bridging to 
> Objective-C should not be difficult; just use the file descriptor from one 
> side to build a handle on the other side.
> 
> IMPACT ON EXISTING CODE:
> 
> Since the new class would have the same name as the existing FileHandle 
> class, as it is exposed to Swift, this would not break source compatibility. 
> It would break binary compatibility, which makes it a consideration for Swift 
> 4.
> 
> Charles
> 
> ___
> 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] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

[Tony Parker via swift-evolution]

Hi Andy, everyone,

The short answer is that fixing struct Data requires a source breaking change 
(the enum for the deallocator has to change to use the raw buffer type), so I 
do not want to introduce it until Swift 4 provides a better transition path for 
this kind of change.

- Tony

> On Jan 4, 2017, at 2:12 PM, Andrew Trick  wrote:
> 
> 
>> On Dec 27, 2016, at 12:16 AM, Karl via swift-evolution 
>> > wrote:
>> 
>> Looking for feedback before submitting a PR: 
>> https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/-corelibs-unsafebytes.md
>>  
>> 
>> 
>> —
>> 
>> Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer
>> 
>> Proposal: SE- 
>> 
>> Authors: Karl Wagner 
>> Review Manager: TBD
>> Status: Awaiting review
>> During the review process, add the following fields as needed:
>> 
>> Decision Notes: Rationale 
>> , Additional Commentary 
>> 
>> Bugs: SR- , SR- 
>> 
>> Previous Revision: 1 
>> 
>> Previous Proposal: SE- 
>> 
>>  
>> Introduction
>> 
>> The standard library's Array and ContiguousArray types expose the method 
>> withUnsafeBytes, which allows you to view their contents as a contiguous 
>> collection of bytes. The core libraries Foundation and Dispatch contain 
>> types which wrap some allocated data, but their withUnsafeBytes method only 
>> allows you to view the contents as a pointer to a contiguous memory location 
>> of a given type.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal 
>> 
>>  
>> Motivation
>> 
>> The current situation makes it awkward to write generic code. Personally, I 
>> use the following extension in my projects to sort the naming confusion out:
>> 
>> protocol ContiguousByteCollection {
>>   func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
>> rethrows -> T
>> }
>> 
>> // stdlib types are fine.
>> extension Array: ContiguousByteCollection {}
>> extension ArraySlice: ContiguousByteCollection {}
>> extension ContiguousArray: ContiguousByteCollection {}
>> 
>> // corelibs types give us a pointer, should be: { pointer, count }
>> #if canImport(Dispatch)
>>   import Dispatch
>> 
>>   extension DispatchData : ContiguousByteCollection {
>> func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
>> rethrows -> T {
>>   return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: 
>> $0, count: count)) }
>> }
>>   }
>> #endif
>> 
>> #if canImport(Foundation)
>>   import Foundation
>> 
>>   extension Data : ContiguousByteCollection {
>> func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
>> rethrows -> T {
>>   return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: 
>> $0, count: count)) }
>> }
>>   }
>> #endif
>> Conceptually, the corelibs types are untyped regions of memory, and it would 
>> make sense for them to adopt the UnsafeRawBufferPointer model.
>> 
>>  
>> Proposed
>>  solution
>> 
>> The proposed solution would be to deprecate the current methods on 
>> (Dispatch)Data (with 2 generic parameters), and replace them with methods 
>> with identical signatures to Array (with 1 generic parameter).
>> 
>> To be deprecated:
>> 
>> public func withUnsafeBytes(_ body: 
>> (UnsafePointer) throws -> ResultType) rethrows -> ResultType
>> Replaced with:
>> 
>> public func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> R) 
>> rethrows -> R
>>  
>> 
> Thanks Karl. Good observation.
> 
> I proposed exactly this API along with a few other UnsafeRawBufferPointer 
> compatibility API’s during SE-0183. Look for Tony to follow up on this.
> 
> -Andy

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Swift Extensions on Overlay Structs

[Tony Parker via swift-evolution]

> On Nov 13, 2016, at 11:43 PM, Fabian Ehrentraud via swift-evolution 
>  wrote:
> 
> That's an interesting idea without having to write type signatures twice.
> 
> The different nullability of the absoluteURL is strange indeed - what if I do 
> a guaranteed cast from NSURL to URL, and absoluteURL would have been nil in 
> the original object?

Much of the nullability of struct URL changed (for the better) because we 
removed the reason for it possibly being nil in NSURL: file reference URLs.

What happens on bridging is that we resolve the file reference URL to a real 
URL. If this fails, then the struct URL points to a specific invalid URL:

https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/URL.swift#L1129
 


In practice file reference URLs are actually pretty rare. And anyway, if the 
file reference URL was invalid upon bridging it would have been invalid when 
you tried to use it from Swift later anyway.

- Tony

> 
> Eiher way, I'd really like to know if URL extensions could be bridged too 
> without casting in a future Swift version.
> 
>   -- Fabian
> 
> 
>> On 13 Nov 2016, at 03:45, Dennis Lysenko > > wrote:
>> 
>> Hmm... would it be possible to define a protocol like "UnifiedURLType", 
>> define each of the properties you need to work with inside your extension 
>> functions as protocol properties inside the protocol UnifiedURLType {} 
>> declaration, create an extension UnifiedURLType {} and include doSomething() 
>> inside the extension, and then create extensions on both URL and NSURL 
>> causing them to conform to UnifiedURLType? (extension URL: UnifiedURLType 
>> {}; extension NSURL: UnifiedURLType {})
>> 
>> You could try it, but I wouldn't hold my breath, especially if you're 
>> planning on using absoluteURL within your extension as something as basic as 
>> the type of that variable is already different between the two types. 
>> 
>> Dennis
>> 
>> On Fri, Nov 11, 2016 at 3:08 AM Fabian Ehrentraud via swift-evolution 
>> > wrote:
>> Hi list,
>> 
>> Since Swift 3 there exist overlay structs, e.g. NSURL gets bridged to URL.
>> Unfortunately now extensions on URL are not getting bridged back to ObjC:
>> 
>> 
>> extension URL {
>> func doSomething() -> URL {
>> return self.absoluteURL
>> }
>> }
>> 
>> + (NSURL *)swiftStructExtensionCaller {
>> NSURL *url = [NSURL 
>> URLWithString:@"https://apple.github.io/swift-evolution/ 
>> "];
>> return [url doSomething];
>> }
>> 
>> The compiler does not see the method `doSomething`. Is this on purpose, or 
>> something that has yet to be improved?
>> 
>> I'm aware that I could write the extension on NSURL, but that would mean a 
>> lot of casting on the Swift side.
>> 
>> 
>>   -- Fabian
>> ___
>> 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] [Discussion] API Guidelines

[Tony Parker via swift-evolution]

Hi Adrian, Charlie,

One additional thing that we considered when naming methods like this was how 
central the operation described in the method was to the overall purpose of the 
type.

For example, the core purpose of an array is to store things. Having functions 
with a base name of ‘add’ or ‘remove’ makes sense. Also, the array(contentsOf:) 
is a special case. Array could store other Arrays (Array), and we 
needed to disambiguate between appending the stuff in the array vs the array 
itself.

We decided that this was not the case for URL (although clearly reasonable 
people could disagree — we made a decision and stuck with it). Therefore: 
appendingPathComponent instead of appending(pathComponent:).

There is no doubt in my mind that these guidelines leave a lot more flexibility 
to the API designer than similar guidelines for Objective-C. That is probably 
best at this point. I think we, as a community, are still evolving the best 
practices. I hope we can learn new patterns and idioms over time as we write 
more and more Swift API. The Objective-C guidelines have evolved dramatically 
from when Objective-C was as young as Swift (think about things like not even 
declaring a method return type and assuming ‘id’, or extending NSObject for 
so-called “informal protocols”, or even the relatively recent addition of 
property syntax).

- Tony

> On Oct 14, 2016, at 7:49 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m still not convinced in some cases.
> 
> Take a look at UIViews and its method addSubview.
> 
> open func addSubview(_ view: UIView)
> Personally I’d change or write this function like so:
> 
> open func add(subview: UIView)
> This reduces unnecessary noise _ view for both the implementation and usage.
> 
> // Implementation
> open func add(subview: UIView) {
> // `subview` is descriptive and just fine here
> }
> 
> // Usage
> 
> self.view.add(subview: someOtherView)
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 14. Oktober 2016 um 16:42:06, Zach Waldowski via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> The base name of the function describes its core purpose.
>> 
>> There is no ambiguity instructing an Array to "append" something, but
>> there is context needed: "what are we appending? The contents of the
>> newElements parameter." But there is ambiguity asking URL to "give me a
>> new URL by appending". Appending what? Similarly, telling a collection
>> to "replace". Replace what?
>> 
>> A rule of thumb my team has applied is to put the parameter parens where
>> you would have put `with` in ObjC. This is instructive for your
>> questions as well. "URLByAppendingWithPathComponent" and
>> "replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
>> does.
>> 
>> Cheers!
>>   Zachary Waldowski
>>   z...@waldowski.me
>> 
>> On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
>> wrote:
>> > Hi there,
>> > 
>> > I am really grateful for the API guidelines that were created as part of
>> > Swift 3, however, I'm having trouble with distinguishing which part of
>> > the method name should be already an argument. To illustrate this, here
>> > are two examples:
>> > 
>> > // On Array
>> > public mutating func append(contentsOf newElements: S)
>> > 
>> > // On Foundation.URL
>> > public func appendingPathComponent(_ pathComponent: String) -> URL
>> > 
>> > 
>> > Is there a particular reason why it's not
>> > 
>> > public func appending(pathComponent: String) -> URL
>> > 
>> > ?
>> > 
>> > In my opinion the entire stdlib and Foundation is full of such
>> > discrepancies which make it hard to decide when you name your own methods
>> > since there are preceding cases in the language itself (or Foundation)
>> > that go both ways.
>> > 
>> > The same goes for why don't the replace methods (this is on String)
>> > follow the same - when there is append(contentsOf:):
>> > 
>> > public mutating func replaceSubrange(_ bounds: ClosedRange,
>> > with newElements: String)
>> > 
>> > instead of
>> > 
>> > public mutating func replace(subrange bounds: ClosedRange,
>> > with newElements: String)
>> > 
>> > 
>> > 
>> > I know there was an extensive discussion about this here when the stdlib
>> > names were discussed. And given that these would be breaking changes, I
>> > don't necessarily want to start a lengthy discussion about renaming those
>> > again - I'm just wondering what are the reasons behind this and what
>> > should be the correct naming conventions.
>> > 
>> > Thanks!
>> > 
>> > Charlie
>> > ___
>> > 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] [swift-evolution-announce] SE-0138 UnsafeBytes

[Tony Parker via swift-evolution]

Hi Andy,

> On Sep 2, 2016, at 1:08 PM, Andrew Trick <atr...@apple.com> wrote:
> 
>> 
>> On Sep 2, 2016, at 9:31 AM, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi Andy, Dave,
>> 
>> I have two major objections to this proposal.
>> 
>> The first is timing. It is too late for us to evaluate this correctly for 
>> Swift 3.
>> 
>> The second is that this API overlaps too much with Foundation’s struct Data. 
>> We should be standardizing on a small number of common types, so that 
>> developers do not need to find ways to translate one API output into another 
>> API’s input.
>> 
>> I think we should instead focus on what needs to be added to struct Data 
>> (and other API, like Stream) to fill this role. The proposal touches only 
>> touches on this briefly, but in my opinion it is the direction we should 
>> pursue — and for Swift 4 or perhaps some Swift 3 update.
>> 
>> - Tony
> 
> Foundation Data needs an interface to UnsafePointers. UnsafeBytes
> perfectly fits that need. The same is true of any Stream or
> BinaryFormat abstraction that we design in the future. In fact,
> migrating Data itself to the raw pointer changes in Swift 3 is enough
> motivation to add UnsafeBytes.
> 
> It's really unfortunate that Data's interface can't take advantage of
> UnsafeBytes in Swift 3 because it would help with adoption of
> Data. There is currently a design flaw whenever a client of Data
> doesn't know the memory's original type. I'm not happy about that, but
> I think we can live with it for a while.
> 
> The issue at hand is the large amount of Swift code out there working
> with UnsafePointers. We urgently need to provide a migration strategy
> for that code. Obviously, we don't have an urgent need to migrate code
> already using Data, so improving it's interface can wait until Swift 4.
> 
> I've seen many attempts to migrate to Swift 3 (this has been my job
> for the past month). I can claim with certainty that if we don't
> give developers a natural way to replace their UnsafePointer,
> we are going to be left with a lot of incorrect Swift code.
> 
> Let me make it clear that there is no overlap between Data and UnsafeBytes.
> 
> For public APIs, UnsafeBytes is meant to replace those functions that
> currently take (UnsafePointer, Int) including Data's own
> interfaces. Otherwise, we're strongly encouraging users to write
> incorrect code on the client side. Won't NSStream, for example,
> continue to to support UnsafePointer for those developers who need it?
> If the developer does not need UnsafePointers, that's great, and
> that's what we should continue striving for. But when developers are
> using UnsafePointer, we need a natural way to use it correctly.
> 
> For general Swift code, Unsafe means something special and
> important. The ultimate goal of the standard library and frameworks is
> that application developers never need to do something Unsafe. If
> they do, it needs to be explicitly marked Unsafe. If we are promoting
> Foundation Data as the right way to solve problems for app developers,
> then it needs to *not* be Unsafe.
> 
> UnsafeBytes simply provides a missing bridge between Unsafe pointers
> and safe APIs like Data. By definition, Data and UnsafeBytes use cases
> don't overlap. You either need to use Unsafe pointers because you're
> programming at the systems level, or existing (safe) libraries do the
> job. In practice, there are points at which these worlds meet.
> 
> So...
> 
> - Today we need UnsafeBytes so that we can migrate existing Swift
>   code correctly to a well-defined memory model.
> 
> - In the future we need UnsafeBytes to safely implement the transitions
>   between "systems code" and "application code”.
> 
> -Andy

If the goal is to simplify the story for developers, so they can understand the 
complicated topic of the way that binding memory works in Swift, then 
introducing a new intermediate type feels to me like working in the opposite 
direction.

I would instead prefer to look at what we can do with adding API to the 
existing types to cover this use case. You point out in the proposal that it 
has become customary to use [UInt8] in API. I would prefer that we work towards 
a solution that makes it customary to use Data when you want to expose an API 
that uses Data. The example of migrated code in the proposal illustrates my 
concern. It suggests that the conversion for handleMessages should end here:

func handleMessages(_ bytes: UnsafeBytes) -> Int

I think instead handleMessages should take a Data argument. The input driver 
code should be able to use

Re: [swift-evolution] [swift-evolution-announce] SE-0138 UnsafeBytes

[Tony Parker via swift-evolution]

Hi Andy, Dave,

I have two major objections to this proposal.

The first is timing. It is too late for us to evaluate this correctly for Swift 
3.

The second is that this API overlaps too much with Foundation’s struct Data. We 
should be standardizing on a small number of common types, so that developers 
do not need to find ways to translate one API output into another API’s input.

I think we should instead focus on what needs to be added to struct Data (and 
other API, like Stream) to fill this role. The proposal touches only touches on 
this briefly, but in my opinion it is the direction we should pursue — and for 
Swift 4 or perhaps some Swift 3 update.

- Tony

> On Sep 1, 2016, at 3:18 PM, Andrew Trick  wrote:
> 
> I’m resending this for Review Manager Dave A. because the announce list is 
> dropping his messages...
> 
> Hello Swift community,
> 
> The review of "UnsafeBytes" begins now and runs through September
> 7th. This late addition to Swift 3 is a follow-up to SE-0107:
> UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
> allowing developers to continue working with collections of UInt8 values,
> but now doing so via a type safe API. The UnsafeBytes API will not require 
> direct manipulation of raw pointers or reasoning about binding memory.
> 
> The proposal is available here:
> 
>  
>   
> >
> 
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> 
>   >
> 
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at
> the top of the message:
> 
> Proposal link:
>   >
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
> 
>  * What is your evaluation of the proposal?
>  * Is the problem being addressed significant enough to warrant a
>change to Swift?
>  * Does this proposal fit well with the feel and direction of Swift?
>  * If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   >
> 
> Thank you,
> 
> -Dave Abrahams
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

[Tony Parker via swift-evolution]

> On Aug 24, 2016, at 11:09 AM, Douglas Gregor  wrote:
> 
>> 
>> On Aug 23, 2016, at 4:00 PM, Tony Parker > > wrote:
>> 
>> Hi Doug,
>> 
>>> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> Introduction
>>> 
>>> A handful of Swift numeric types are bridged to NSNumber when passed into 
>>> Objective-C object contexts. We should extend this bridging behavior to all 
>>> Swift numeric types. We should also bridge common Cocoa structs such as 
>>> NSRangeby boxing them into NSValue objects.
>>> 
>>> Swift-evolution thread: TBD 
>>> 
>>>  
>>> Motivation
>>> 
>>> SE-0116 
>>> 
>>>  changed how Objective-C's id and untyped collections import into Swift to 
>>> use the Any type. This makes it much more natural to pass in Swift value 
>>> types such as String and Array, but introduces the hazard of passing in 
>>> types that don't bridge well to Objective-C objects. Particularly 
>>> problematic are number types; whereas Int, UInt, and Double will 
>>> automatically bridge as NSNumber, other-sized numeric types fall back to 
>>> opaque boxing:
>>> 
>>> let i = 17
>>> let plist = ["seventeen": i]
>>> // OK
>>> try! NSJSONSerialization.data(withJSONObject: plist)
>>> 
>>> let j: UInt8 = 38
>>> let brokenPlist = ["thirty-eight": j]
>>> // Will throw because `j` didn't bridge to a JSON type
>>> try! NSJSONSerialization.data(withJSONObject: brokenPlist)
>>> We had shied away from enabling this bridging for all numeric types in the 
>>> Swift 1.x days, among other reasons because we allowed implicit bridging 
>>> conversions in both directions from Swift value types to NS objects and 
>>> back, which meant that you could slowly and brokenly convert between any 
>>> two numeric types transitively via NSNumber if we allowed this. We killed 
>>> the implicit conversions completely with SE-0072 
>>> 
>>>  so that is no longer a concern, so expanding the bridging behavior should 
>>> no longer be a major problem, since it must now always be explicitly asked 
>>> for.
>>> 
>>> There are also many Cocoa APIs that accept NSArray and NSDictionary objects 
>>> with members that are NSValue-boxed structs. Matt Neuberg highlights Core 
>>> Automation as an example in this bug report 
>>> . With id-as-Any, it's natural to 
>>> expect this to work:
>>> 
>>> anim.toValue = CGPoint.zero
>>> However, the CGPoint value does not box as a meaningful Objective-C object, 
>>> so this currently breaks Core Animation at runtime despite compiling 
>>> successfully. It would be more idiomatic to bridge these types to NSValue.
>>> 
>>>  
>>> Proposed
>>>  solution
>>> 
>>> All of Swift's number types should be made to bridge to NSNumber when used 
>>> as objects in Objective-C:
>>> 
>>> Int8
>>> Int16
>>> Int32
>>> Int64
>>> UInt8
>>> UInt16
>>> UInt32
>>> UInt64
>>> Float
>>> Double
>>> Cocoa structs with existing NSValue factory and property support should be 
>>> made to bridge to NSValue when used as objects:
>>> 
>>> NSRange
>>> CGPoint
>>> CGVector
>>> CGSize
>>> CGRect
>>> CGAffineTransform
>>> UIEdgeInsets
>>> UIOffset
>>> CATransform3D
>>> CMTime
>>> CMTimeRange
>>> CMTimeMapping
>>> MKCoordinate
>>> MKCoordinateSpan
>>> SCNVector3
>>> SCNVector4
>>> SCNMatrix4
>> 
>> How do new types get added to this list? It’s certainly not the case that 
>> NSValue knows about them specifically; usually some kind of category is 
>> added after the fact.
> 
> I think the list was gathered from the documentation at:
> 
>   
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSValue_Class/
>  
> 
> 
> New types would get added when the owner of a particular framework determines 
> that one of their value types can be mapped to a more-specific Objective-C 
> class than Swift’s box type, at which point an _ObjectiveCBridgeable 
> conformance can be added to do it. This proposal is taking the presence of 
> those NSValue categories as an indication that NSValue is the best 
> Objective-C class to which these types should be mapped.
> 
>> Also, how does this bridging work for swift-corelibs-foundation on Linux, 
>> where bridging is disabled?
> 
> It 

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

[Tony Parker via swift-evolution]

Hi Doug,

> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Introduction
> 
> A handful of Swift numeric types are bridged to NSNumber when passed into 
> Objective-C object contexts. We should extend this bridging behavior to all 
> Swift numeric types. We should also bridge common Cocoa structs such as 
> NSRangeby boxing them into NSValue objects.
> 
> Swift-evolution thread: TBD 
> 
>  
> Motivation
> 
> SE-0116 
> 
>  changed how Objective-C's id and untyped collections import into Swift to 
> use the Any type. This makes it much more natural to pass in Swift value 
> types such as String and Array, but introduces the hazard of passing in types 
> that don't bridge well to Objective-C objects. Particularly problematic are 
> number types; whereas Int, UInt, and Double will automatically bridge as 
> NSNumber, other-sized numeric types fall back to opaque boxing:
> 
> let i = 17
> let plist = ["seventeen": i]
> // OK
> try! NSJSONSerialization.data(withJSONObject: plist)
> 
> let j: UInt8 = 38
> let brokenPlist = ["thirty-eight": j]
> // Will throw because `j` didn't bridge to a JSON type
> try! NSJSONSerialization.data(withJSONObject: brokenPlist)
> We had shied away from enabling this bridging for all numeric types in the 
> Swift 1.x days, among other reasons because we allowed implicit bridging 
> conversions in both directions from Swift value types to NS objects and back, 
> which meant that you could slowly and brokenly convert between any two 
> numeric types transitively via NSNumber if we allowed this. We killed the 
> implicit conversions completely with SE-0072 
> 
>  so that is no longer a concern, so expanding the bridging behavior should no 
> longer be a major problem, since it must now always be explicitly asked for.
> 
> There are also many Cocoa APIs that accept NSArray and NSDictionary objects 
> with members that are NSValue-boxed structs. Matt Neuberg highlights Core 
> Automation as an example in this bug report 
> . With id-as-Any, it's natural to 
> expect this to work:
> 
> anim.toValue = CGPoint.zero
> However, the CGPoint value does not box as a meaningful Objective-C object, 
> so this currently breaks Core Animation at runtime despite compiling 
> successfully. It would be more idiomatic to bridge these types to NSValue.
> 
>  
> Proposed
>  solution
> 
> All of Swift's number types should be made to bridge to NSNumber when used as 
> objects in Objective-C:
> 
> Int8
> Int16
> Int32
> Int64
> UInt8
> UInt16
> UInt32
> UInt64
> Float
> Double
> Cocoa structs with existing NSValue factory and property support should be 
> made to bridge to NSValue when used as objects:
> 
> NSRange
> CGPoint
> CGVector
> CGSize
> CGRect
> CGAffineTransform
> UIEdgeInsets
> UIOffset
> CATransform3D
> CMTime
> CMTimeRange
> CMTimeMapping
> MKCoordinate
> MKCoordinateSpan
> SCNVector3
> SCNVector4
> SCNMatrix4

How do new types get added to this list? It’s certainly not the case that 
NSValue knows about them specifically; usually some kind of category is added 
after the fact.

Also, how does this bridging work for swift-corelibs-foundation on Linux, where 
bridging is disabled?

- Tony
>  
> Detailed
>  design
> 
> Bridged NSNumber and NSValue objects must be castable back to their original 
> Swift value types. NSValue normally preserves the type information of its 
> included struct in its objCType property. We can check the objCType of an 
> NSValue instance when attempting to cast back to a specific bridged struct 
> type.
> 
> NSNumber is a bit trickier, since Cocoa's implementation does not generally 
> guarantee to remember the exact number type an instance was constructed from. 
> We can instead say that casting an NSNumber to a Swift number type succeeds 
> if the value of the NSNumber is exactly representable as the target type. 
> This is imperfect, since it means that an NSNumbercan potentially be cast to 
> a different type from the original value, but it at least ensures that Swift 
> values round-trip through the bridge without depending on NSNumber 
> implementation details.
> 
>  
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

[Tony Parker via swift-evolution]

For what it’s worth, I agree with Dmitri on the naming of this function. I 
think we should find a way to give it a name without “NonObjC” in it.

- Tony

> On Jul 20, 2016, at 8:15 AM, Arnold via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 20, 2016, at 6:50 AM, Dave Abrahams  wrote:
>> 
>> 
>>> on Tue Jul 19 2016, Dmitri Gribenko  wrote:
>>> 
 On Tue, Jul 19, 2016 at 10:51 PM, Chris Lattner  wrote:
 The review of "SE-0125: Remove NonObjectiveCBase and
 isUniquelyReferenced" begins now and runs through July 22. The
 proposal is available here:
 
   
 https://github.com/apple/swift-evolution/blob/master/proposals/0125-remove-nonobjectivecbase.md
>>> 
>>> I like the API simplification.  A few thoughts that I have after
>>> reading the proposal that could take the simplification it even
>>> further:
>>> 
>>> - I find it a little strange to see a mention of Objective-C, and a
>>> negation in `isUniquelyReferencedNonObjC`.  For example, if we get C++
>>> import, would we need to rename it to
>>> `isUniquelyReferencedNonObjCAndNonCXX`?  
>> 
>> Only if we were unable to determine that CXX imports were
>> uniquely-referenced.
>> 
>>> I think that is the issue with negation.  If we want to emphasize that
>>> the API will work only with Swift types, we can do something
>>> `isUniquelyReferencedSwiftReference`.  
>> 
>> That's not really the point.  The point is to find out whether it's
>> *known* to be a unique reference.  False negatives are part of the
>> game.
>> 
>>  isKnownUniquelyReferenced
>> 
>> would work.
> 
> 
> This would be a change to the semantics of the API. Currently, you can rely 
> on -- and is documented as -- that if it returns true you can assume the 
> reference points to a non-@objc instance.
> 
> Users may be relying on this behavior.
> 
> Do we want to add an isNativeSwiftReference API?
> 
> 
>> 
>>> But I would probably suggest that we just go with just
>>> `isUniquelyReferenced` and mention the Swift-only requirement in the
>>> documentation.
>> 
>> It's not a requirement, as in “precondition.”  The point of having
>> `NonObjC` in this API is actually that it *does* work on ObjC
>> references, by returning false.
>> 
>>> - I find the use of different names in `isUniquelyReferenced()` and
>>> `ManagedBufferPointer.holdsUniqueReference()` to be strange.  Why not
>>> call the latter `ManagedBufferPointer. isUniquelyReferenced()`?  It is
>>> true that we are not checking that pointer is not uniquely referenced,
>>> if we want to emphasize that, maybe something like
>>> `ManagedBufferPointer.isBufferUniquelyReferenced()` or
>>> `isPointeeUniquelyReferenced()` will work?
>> 
>>  isUniqueReference
>> 
>> would work for ManagedBufferPointer.
>> 
>>> The reason why I'm suggesting this is that `isUniquelyReferenced` and
>>> `holdsUniqueReference` don't immediately strike me as performing the
>>> same operation, the immediate impression I get is that these
>>> operations are related, but subtly different, and it is not obvious
>>> what the difference is (but after reading the docs I figure out that
>>> there is no difference... until I need to use these APIs again).
>>> 
>>> - We have `ManagedBufferPointer.holdsUniqueOrPinnedReference()`, but
>>> don't have an equivalent free function `isUniquelyReferencedOrPinned`
>>> (we actually have one, but it is internal).  Do we need a public one?
>>> If we do, we could as well add it as a part of this proposal, while we
>>> are cleaning up this library subsystem.
>> 
>> Maybe, but it's not crucial.
>> 
>> -- 
>> Dave
> ___
> 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] Notification.Name

[Tony Parker via swift-evolution]

Hi Brent,

In general, I agree with your idea that the scope of the name of these things 
is with the type it’s used for. The type of it is of course Notification.Name.

One thing we did in the short term to make this feature even remotely possible 
was to add an importer rule: global const NSStrings that end in ‘Notification’ 
are imported as Notification.Name.something — otherwise everyone would have to 
either cast these, or we’d have to audit the whole SDK to add an attribute to 
each one.

I think we can probably do a better job of putting these where they belong with 
a combination of setting the attribute and using either API notes or the 
NS_SWIFT_NAME macro to get them into the right scope. Probably the only real 
way to accomplish this is to file radars on each relevant framework (including 
Foundation itself).

Thanks,
- Tony

> On Jun 29, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Not 100% sure this belongs here, but I'll bite.
> 
> The new `Notification.Name` type is a beautiful application of SE-0033 
> "Import Objective-C Constants as Swift Types"[1] which removes a lot of 
> boilerplate. However,  I think it puts the resulting constants in the wrong 
> place. They all get piled into `Notification.Name`, resulting in:
> 
>   Notification.Name.NSSystemTimeZoneDidChange
>   Notification.Name.NSThreadWillExit
>   Notification.Name.NSURLCredentialStorageChanged
>   Notification.Name.NSUbiquityIdentityDidChange
>   Notification.Name.NSUndoManagerCheckpoint
> 
> I think these would be a lot better off as:
> 
>   TimeZone.systemTimeZoneDidChange
>   Thread.willExit
>   URLCredentialStorage.changed
>   FileManager.ubiquityIdentityDidChange
>   UndoManager.checkpoint
> 
> Most of these could probably be inferred by prefix matching, but some, like 
> `TimeZone.systemTimeZoneDidChange` and 
> `FileManager.ubiquityIdentityDidChange`, would probably have to be done 
> manually. There might even be a few which have no natural attachment point, 
> though I can't think of any off the top of my head.
> 
> To be clear, I don't think we want this behavior on all `swift_wrapper` 
> types. For instance, the specified behavior is probably appropriate for 
> `HKQuantityTypeIdentifier` and `NSErrorDomain`, the primary examples in 
> SE-0033. But `Notification.Name` is a slightly different use from what we 
> imagined for this feature, and I think it needs a slightly different behavior.
> 
> So, what's the best way to pursue fixing this issue?
> 
> 1. A new proposal, perhaps introducing `swift_wrapper(struct,prefix_matched)`?
> 
> 2. An amendment to SE-0033?
> 
> 3. A radar filed with the Foundation team?
> 
> 4. A blizzard of radars filed with *every* framework team?
> 
> 5. Deferral to post-Swift 3?
> 
> 
> 
> [1] 
> https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [swigt-evolution] [Pitch] Make NSOrderedSet behave like any other collections from Foundation

[Tony Parker via swift-evolution]

Hi Remy, Brent,

We’re thinking about it but there are no plans for Swift 3 in this respect 
(although I think we’re going to keep the NS prefix on these types).

One of the complexities with this type is its performance characteristics, 
especially when used with CoreData (the reason it was introduced). CoreData 
relies a lot on proxying for performance reasons, but there is currently an 
impedance mismatch between that behavior and Swift’s focus on static typing.

- Tony

> On Jun 17, 2016, at 10:43 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> Unlike its companion collections like NSArray, NSDictionary, and NSSet, 
>> NSOrdered is still a class rather than a struct and has a subclass that is 
>> still NSMutableOrderedSet. This should probably receive the same treatment 
>> as the other classes
> 
> Swift Evolution proposal SE-0069 "Mutability and Foundation Value Types" 
> notes at the bottom 
> :
> 
>> The following classes were considered and rejected or deferred for the 
>> described reasons:
>> …
>>  • OrderedSet, CountedSet: We will consider these types in a future 
>> proposal.
> 
> 
> So sit tight—the Foundation team is already thinking about this. (That 
> doesn't mean you'll necessarily see it this year, though.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Tony Parker via swift-evolution]

> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> I second Matthew’s points. I believe dropping NS- is more harmful than 
> helpful, especially for the future. People have been using Foundation with 
> the prefix for decades, so I don’t think there’s a longing need that will 
> make using it in Swift unbearable. It has an older Objective-C flavoured 
> approach, relying heavily on classes, run loops, key value observing (e.g. 
> NSOperation), exceptions, and notifications. I think its philosophy will 
> stand out more than its NS- prefix. Even if many classes become value types, 
> it feels more like a port.
> 
> I think for something to be so central as the recommended ‘foundational’ 
> library for Swift, it carries too much baggage, which is unfortunate in the 
> light of Swift’s radical eagerness to reject unnecessary legacy.
> 
> Many Foundation classes expect NSObject subclasses for delegates and for key 
> value coding & observing. Key value observing requires on-the-fly subclassing 
> at run time, something which goes strongly against Swift’s philosophy AFAIK.
> 
> Foundation is in some cases a wrapper around underlying technologies such as 
> GCD, because years ago an Objective-C wrapper was seen as a more friendly, 
> more safe, and a more familiar object-oriented approach. With Swift we have 
> the power to make those technologies themselves more friendly, safe, and 
> familiar with modernisations such as the current proposal for libdispatch. 
> Extensions allow us to add properties and methods directly to the native 
> types.
> 
> NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable 
> state.
> 
> I think removing the prefixes will take valuable real estate for types such 
> as ‘URL’ and ‘Data’, which instead can have new replacements made, focused on 
> the use-cases of only Swift. I think DispatchData could be a fine choice for 
> ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.
> 

Perhaps you missed it, but SE-0069 adds corresponding value types for URL and 
Data, among others.

- Tony

> I fully support the idea of improving Foundation, and of there being a 
> Linux-compatible version. I don’t support it being as first class as the 
> standard library or libdispatch, and don’t support removing the NS prefixes.
> 
> Patrick
> 
> 
>> On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> I very much support hoisting types, updating enumerations, and updating the 
>> NSStringEncoding constants.  
>> 
>> I do not support dropping NS on type level names.  Dropping the 2 character 
>> prefix is a very small benefit and it comes with very real costs.  I believe 
>> unprefixed top level names should not be taken without a manual review of 
>> the API design.  
>> 
>> Types which will be value types in the future are obvious candidates for 
>> redesign but are not the only types whose API would benefit by human 
>> consideration and Swiftification.  Keeping the NS prefix until this happens 
>> recognizes that the Swiftification of Foundation is a work in progress.  It 
>> will give us more options in the future that don’t involve breaking changes. 
>>  
>> 
>> It will also serve as a signal to developers about what kinds of APIs should 
>> be considered idiomatic in Swift.  If we want developers to learn how to 
>> distinguish idiomatic Swift, our API guidelines, etc from Objective-C 
>> mappings we need to provide some cues.  I believe name prefixes are a good 
>> way to do this.
>> 
>> I hope that we will move forward with most of this proposal while keeping 
>> the NS prefix for top-level names.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> Yes, but we need to do this carefully, deliberately and in a way that we 
>> won’t regret in the future.  I believe several parts of the proposal are 
>> warranted, but the namesake “drop NS prefix” portion should deferred until 
>> each type receives manual consideration and possibly redesign.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> Mostly yes.  However, taking top-level unprefixed names without a process of 
>> Swiftification does not.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> I think this question is N/A for this proposal.
>> 
>> I hesitate in saying this, but I think the best comparison to consider is 
>> the origin of Foundation and Cocoa themselves.  They are fantastic 
>> Objective-C APIs.  If they had originated by wrapping pre-existing APIs 
>> written in a different language with different idioms and then incrementally 
>> enhanced I wonder if they may have been less fantastic.  
>> 
>> I believe reserving unprefixed top-level names 

Re: [swift-evolution] Dropping NS Prefix in Foundation

[Tony Parker via swift-evolution]

Hi Matthew (and others),

> On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> This is exactly the way I see it, too. Many people are coming to Swift
>> and immediately decrying the language because it doesn't have built-in
>> support for regex, date parsing, collections beyond the built-in 3,
>> etc., when it in fact has a rich tapestry of things from Foundation.
>> 
>> While I agree with many of the points made in the thread, I think we're
>> missing the forest for the trees. Foundation is the best at many of the
>> things it does on any platform. This is in spite of many of the points
>> made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
>> It *does* have crufty edges.
>> 
>> Foundation not having a super-Swifty API is a solvable problem over
>> time, of which this is a first step down that road. Revamping the
>> Foundation API in the Swift 3 timeframe is not a solvable problem.
> 
> I agree with everything you say here.  My only concern is trying to ensure we 
> don't take steps today that will make it difficult to implement the best 
> design down the road.  

It’s true that Foundation is the foundation of the Objective-C stack. However, 
while some see this as a weakness, I see it as a great opportunity. The role of 
this library puts it in a unique spot as a leverage point: low enough level to 
be used in nearly all applications on all platforms, but high enough level to 
establish API and patterns that you see across the SDK.

The idea of leaving existing API behind somehow by keeping the prefix means 
that the leverage would be gone. With all existing API in terms of those 
existing types, any new types are effectively unused in all API above 
Foundation. We would need to introduce conversion methods to move between the 
two types (if that is even possible).

If, instead, we evolve the existing API to be better for Swift, then we benefit 
the entire stack without having a boil-the-ocean type of adoption problem. 
Therefore, we have already made the decision that we are not going to invent an 
entirely new set of a fundamental types but to instead iteratively improve the 
API of the ones we have.

- Tony

> 
>> 
>> Cheers
>>  Zach Waldowski
>>  z...@waldowski.me
>> 
>>> On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
>>> If I am coming to Swift as a new user (possibly as a first language,
>>> even) without any prior Objective-C experience and very little knowledge
>>> of the long history of Foundation, the NS prefix, etc, this is going to
>>> feel worse than a little out of place - it will feel downright wrong,
>>> broken, and confusing to see these weird NS prefixes on some seemingly
>>> “standard” classes and not on others.
>>> 
>>> I’m +1 for removing the NS and evolving forward from there - let’s not
>>> create a confusing tangle of old and new that is navigable only by those
>>> with knowledge of the esoteric.
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
>>>> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> I have mixed feelings about this; while I agree that prefixing names isn’t 
>>>> a good fit for Swift, at the same time that’s kind of the appeal of it. 
>>>> Assuming that Foundation will eventually be replaced by a more Swift-like 
>>>> alternative, or will be incrementally reworked, I think it makes sense for 
>>>> it to feel a little weird to use as it is right now.
>>>> 
>>>> The NS prefix makes it clear that this is something different, something 
>>>> not originally designed with Swift in mind, and in a way that’s a good 
>>>> thing. I know in my own case it makes me instinctively shy away from it, 
>>>> and actually encourages me to wrap NS constructs in something more 
>>>> Swift-like for convenience.
>>>> 
>>>>> On 6 May 2016, at 21:52, Tony Parker via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> Thanks to all of you for your feedback on SE-0069 (Foundation Value 
>>>>> Types). I’m back again with more information on another part of our plan 
>>>>> to integrate Foundation API into Swift: dropping the NS prefix.
>&

Re: [swift-evolution] Dropping NS Prefix in Foundation

[Tony Parker via swift-evolution]

> On May 7, 2016, at 6:06 AM, Jonathan Hull  wrote:
> 
> -1 on this as well.  How much does dropping NS really help things anyway?  
> 
> All it does is force everyone to learn which things still have NS and which 
> don’t.  It also makes things much more difficult to search for… searching for 
> NS_ gives the results you want quickly vs searching for anything in Swift 
> foundation (e.g. Array -- which gives you a mixture of other programming 
> languages and Taylor Swift gossip).
> 
> My proposal would be to keep NS for everything and then slowing making 
> versions without the prefix, either by rewriting them to be better in Swift 
> or simply aliasing the NS version.  Once you have critical mass for useful 
> things (around Swift 5~6), you can separate all the NSStuff out into their 
> own NSFoundation which would be used only for backwards compatibility.
> 
> To the inevitable question: Wont having NS and Non-NS versions be confusing 
> (especially if some are just aliases)?  My answer is that it is less 
> confusing than this proposal. There is a simple rule: Things without NS are 
> always the new and preferred methods. Things with NS are there for 
> compatibility and will continue to work the way they do in ObjectiveC (even 
> if you have to import “NSFoundation” to get them instead of just “Foundation")
> 

I think that this approach ends up with confusion as well. Maybe we end up with 
UserDefaults and NSUserDefaults? One is written in Swift and other is not, but 
what difference would that make to the caller? Swift itself is not written 
completely in Swift. Instead, let’s have one UserDefaults that has an API 
appropriate for Swift. You’ve seen some of that already with changes to the 
names of its methods 
(https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575 
as one example, which takes advantage of overloading to simplify the API).

> Side Note: I would also REALLY like to see a swift native improvement on 
> NSAttributedString with native literal support.

NSAttributedString was part of the value types proposal at the beginning but 
deferred for a few practical reasons. One reason is that I want additional 
existential support in the language first. AttributedString has the concept of 
a “longest effective run”, which is calculated by checking for equality between 
attributes. Attributed string should allow for AnyEquatableAndCopyable members 
of its attribute dictionary. A second problem is that the entire Cocoa text 
system (and hundreds of higher level APIs) are based on top of the NSString 
Index concept, which is hidden behind the unicodeScalar view of Swift.String. I 
would like a more unified story of how these two can interoperate before we 
revamp the base type.

Both of these are solvable, but they require time to collaborate between teams 
to decide what the right platform-wide approach is. We’ll do it, but it will 
not happen immediately.

> 
>> There’s no question that we can improve Coding for Swift. I have actually 
>> explored this area quite a bit although I don’t have anything planned for 
>> Swift 3 at this time.
>> 
>> The general point is though, that we can do it by extending Foundation in 
>> that direction over time. In fact, keyed archiving is the perfect example of 
>> how we were able to do just that in the past in Objective-C. NSArchiver 
>> already existed and served a particular purpose, so we extended the concept 
>> into NSKeyedArchiver using the facilities available to us at the time.
> I would be curious to hear about your explorations (either in another thread 
> or offlist)
> 
> I have written a couple of experimental versions of an improved Coding system 
> for Swift.  The key idea is to use closures to allow coding of arbitrarily 
> complex nested types (e.g an array of tuples of Dictionaries: [(String, 
> [String:Int])] ).  It works pretty well, but unfortunately currently taxes 
> the compiler to the point where it randomly crashes during compilation.  I am 
> waiting for the new generics stuff to come online before I explore further, 
> since I believe that will dramatically simplify the code.
> 
> The other idea which I would like to see replicated is that it codes to an 
> intermediate format which can then be transformed to/from binary data, XML, 
> BSON (JSON + some representation for Binary Data) or some other format...
> 
> It also interoperates very well with existing NSCoding classes, which is an 
> important feature.
> 
> Thanks,
> Jon

One thing to think about here is what the role of NSCoding is in the first 
place. It was designed to support archiving of UI objects to nib files. It has 
been pressed into service for all kinds of other interesting tasks since; UI 
state restoration, document formats, and IPC wire protocol, to name a few. It 
may be worthwhile to decide if these are really all the same use case or not. 
I’m honestly not sure yet. Some of these are very focused on dynamic behavior 

Re: [swift-evolution] Dropping NS Prefix in Foundation

[Tony Parker via swift-evolution]

Hi Matthew,

> On May 7, 2016, at 5:22 AM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 7, 2016, at 5:03 AM, David Hart via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Hi Tony,
>> 
>> I'm very positive about the proposal but I have similar fears, even if less 
>> strong, to David Waite. I agree that the core libraries can be improved with 
>> time, but it's going to be difficult to rethink them profoundly. 
>> NSKeyedArchiver was an improvement, but a fairly mild one, to stay 
>> backwards-compatible. It's going to be difficult to introduce major changes, 
>> like the ones David Waite gave as example, post Swift 3.
>> 
>> But on a more pragmatic level, I know there is not much we can do about it, 
>> with the current deadlines. All we can hope for is make corelibs-foundation 
>> as Swifty as possible by the time Swift 3 comes out. And I imagine that 
>> third party libraries will come to replace the aspects of it that feel too 
>> alien to Swift.
>> 
>> Any thoughts?
> 
> +1.  I have similar concerns.  The worst case would be if Foundation does not 
> eventually get the appropriate Swift-native rethinking and third party 
> libraries with the same functionality are developed for that reason.  If that 
> happens the community will be split between those who favor various 
> libraries.  That should not happen just because corelibs doesn't feel 
> Swift-native.
> 
> It would be far better to see that happen as part of the evolution process so 
> we eventually end up with fully Swift-native types in Foundation itself.  I 
> think a strong commitment to doing this over the next couple years would go a 
> long way towards addressing the concerns many of us have about this.
> 

I totally understand what you’re saying. I believe we’ve made that commitment, 
by virtue of placing Foundation (dispatch and XCTest too) into swift-corelibs 
and also by sending this proposal and the value types one to this list. We are 
trying to avoid exactly the split you are concerned about.

There is always going to be new functionality in Foundation and other 
frameworks in the SDK that is tied to OS releases, which we simply cannot talk 
about here until those releases are made public. However, the rest of the 
Foundation team and I are always advocating for the best possible Swift API 
wherever and whenever we can.

There is no doubt it will take time to make the many thousands of APIs that you 
use every day feel native and natural in Swift. I’ll beat the drum of iterative 
improvement again: the best way to get there from here is to make continuous 
adjustments and improvements from release to release. You will see the 
rethinking you are looking for over the course of that process.

Thanks,
- Tony

>> 
>> David (Hart).
>> 
>> On 07 May 2016, at 00:06, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> Hi David,
>>> 
>>>> On May 6, 2016, at 2:56 PM, David Waite <da...@alkaline-solutions.com 
>>>> <mailto:da...@alkaline-solutions.com>> wrote:
>>>> 
>>>> -1 On the group as-is. I do not believe all of these classes have the 
>>>> behavior that would be expected if ‘foundation’ were a from-scratch 
>>>> foundational library for Swift (as it exists on non Apple platforms). This 
>>>> will lock Swift into an evolutionary path for these types going forward.
>>>> 
>>>> There is enough here that I will just pick one example to focus on - 
>>>> NSCoding/NSCoder, and elements I would suspect from such a from-scratch 
>>>> design
>>>> 
>>>> - Coding would incorporate SecureCoding into its design (I did not see 
>>>> NSSecureCoding even on the list of protocols to get the prefix dropped)
>>> 
>>> SecureCoding should be on the list actually.
>>> 
>>>> - Archiver/Unarchiver would not exist; we would only have keyed versions
>>>> - Coder would be a split in half to Coder and Decoder
>>>> - Coder and Decoder would be protocols
>>>> - The Coder protocol might have a single method, encode(value:Coding, 
>>>> forKey:String)
>>>> - The Decoder protocol might single method,  decode(type:T.Type, 
>>>> forKey: String) -> T?
>>>> - Compiler generation of a default Coding implementation
>>>> 
>>>> And possibly more such as:
>>>> - Add Coders limited to trees of objects vs graphs, to allow the 
>>>> Coder/Dec

Re: [swift-evolution] Dropping NS Prefix in Foundation

[Tony Parker via swift-evolution]

Hi David,

> On May 6, 2016, at 2:56 PM, David Waite <da...@alkaline-solutions.com> wrote:
> 
> -1 On the group as-is. I do not believe all of these classes have the 
> behavior that would be expected if ‘foundation’ were a from-scratch 
> foundational library for Swift (as it exists on non Apple platforms). This 
> will lock Swift into an evolutionary path for these types going forward.
> 
> There is enough here that I will just pick one example to focus on - 
> NSCoding/NSCoder, and elements I would suspect from such a from-scratch design
> 
> - Coding would incorporate SecureCoding into its design (I did not see 
> NSSecureCoding even on the list of protocols to get the prefix dropped)

SecureCoding should be on the list actually.

> - Archiver/Unarchiver would not exist; we would only have keyed versions
> - Coder would be a split in half to Coder and Decoder
> - Coder and Decoder would be protocols
> - The Coder protocol might have a single method, encode(value:Coding, 
> forKey:String)
> - The Decoder protocol might single method,  decode(type:T.Type, 
> forKey: String) -> T?
> - Compiler generation of a default Coding implementation
> 
> And possibly more such as:
> - Add Coders limited to trees of objects vs graphs, to allow the 
> Coder/Decoder protocols to be used for more intuitive JSON/XML representations
> - Custom/specific assignment operator for Decoder to capture desired type 
> without requiring said type to be specified in decode(type:forKey:) calls
> 
> -DW

There’s no question that we can improve Coding for Swift. I have actually 
explored this area quite a bit although I don’t have anything planned for Swift 
3 at this time.

The general point is though, that we can do it by extending Foundation in that 
direction over time. In fact, keyed archiving is the perfect example of how we 
were able to do just that in the past in Objective-C. NSArchiver already 
existed and served a particular purpose, so we extended the concept into 
NSKeyedArchiver using the facilities available to us at the time.

It’s not a goal to rewrite Foundation from scratch in Swift. All Swift apps 
that are running out there today are in fact using a combination of Swift, 
Objective-C, C, C++, various flavors of assembly, and more. The goal is to 
present the existing API of Foundation in a way that fits in with the language 
today while allowing us to iteratively improve it over time.

- Tony

> 
>> On May 6, 2016, at 2:52 PM, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi everyone,
>> 
>> Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). 
>> I’m back again with more information on another part of our plan to 
>> integrate Foundation API into Swift: dropping the NS prefix.
>> 
>> When we originally proposed this as part of the API guidelines document 
>> (SE-0023, 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md>),
>>  we took a very broad approach to which classes would drop their prefix. 
>> This time, we’ve narrowed the scope considerably, plus taken advantage of 
>> the ability to nest types inside classes to further reduce the possibility 
>> of introducing conflicting names.
>> 
>> I’ve written up a draft of the proposal, which includes an extensive section 
>> on motivation plus a list of changes. Please take a look and let me know 
>> what you think. We’ll start a formal review period soon.
>> 
>> https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/-drop-foundation-ns.md
>>  
>> <https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/-drop-foundation-ns.md>
>> 
>> Thanks again for your help,
>> - Tony
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>

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

[swift-evolution] Dropping NS Prefix in Foundation

[Tony Parker via swift-evolution]

Hi everyone,

Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). I’m 
back again with more information on another part of our plan to integrate 
Foundation API into Swift: dropping the NS prefix.

When we originally proposed this as part of the API guidelines document 
(SE-0023, 
https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md),
 we took a very broad approach to which classes would drop their prefix. This 
time, we’ve narrowed the scope considerably, plus taken advantage of the 
ability to nest types inside classes to further reduce the possibility of 
introducing conflicting names.

I’ve written up a draft of the proposal, which includes an extensive section on 
motivation plus a list of changes. Please take a look and let me know what you 
think. We’ll start a formal review period soon.

https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/-drop-foundation-ns.md

Thanks again for your help,
- Tony

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

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

[Tony Parker via swift-evolution]

Hi Rod,

> On May 4, 2016, at 4:59 AM, Rod Brown  wrote:
> 
> 
> Tony,
> 
> With regard to this proposal, is there any reason that this proposal did not 
> include an OrderedSet value type? I suspect perhaps this is an oversight?
> 
> - Rod
> 

We considered it, but did not include it in this proposal for scoping reasons. 
It’s not quite as straightforward to bridge as the other types because it 
really should allow containment of “Any”, but NSOrderedSet would instead 
require “AnyObject.” This is fixable but involves a large amount of engineering 
work.

- Tony

>> On 4 May 2016, at 1:50 PM, Rod Brown via swift-evolution 
>> > wrote:
>> 
>> I believe this would fall in line with by Proposal SE-0069: Mutability and 
>> Foundation Value Types:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  
>> 
>> 
>> I notice there is no OrderedSet in this proposal. I find it odd that it 
>> doesn’t yet include it.
>> 
>> - Rod
>> 
>> 
>> 
>>> On 4 May 2016, at 1:24 PM, Nicholas Maccharoli via swift-evolution 
>>> > wrote:
>>> 
>>> Hello Swift Community,
>>> 
>>> Recently I have noticed that there is a Set type but no OrderedSet type yet.
>>> If I want a set that preserves the original order I have to go with 
>>> NSOrderedSet 
>>> but I think it would be nice to have a native implementation in the 
>>> standard library. 
>>> 
>>> What are your thoughts on this?
>>> 
>>> Thanks!
>>> 
>>> - Nick
>>> 
>>> ___
>>> 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] Mutability for Foundation types in Swift

[Tony Parker via swift-evolution]

Hi Ben,

> On Apr 24, 2016, at 3:51 PM, Ben Rimmington via swift-evolution 
>  wrote:
> 
>  0069-swift-mutability-for-foundation.md>
> 
> The proposal looks great.
> 
> ## Introduction
> 
> Broken link:
> 
> -- 
> ++ 
> 

Thanks; I’ll fix that.

> ### New Value Types
> 
> CharacterSet:
> 
> * Rename to UnicodeScalarSet?

We made a decision to leave the names of the types the same between Swift and 
Foundation. It’s a tradeoff for sure, but it seems better than other 
alternatives. Consistent documentation and hindering a common understanding of 
purpose for the type would be the biggest challenge if we change the names.

> * Update APIs to follow SE-0059 (SetAlgebra) proposal?

We’ll make sure they match in the implementation.

> * Add `enumerateRanges` method, similar to NSIndexSet?
> 

Not a bad idea. We’ll consider new API separately from the main thrust of the 
proposal (its transition to a value type in the first place).

Thanks!
- Tony


> -- 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] Mutability for Foundation types in Swift

[Tony Parker via swift-evolution]

Hi Brent,

Thanks for your feedback! You’ve got some great questions below, I’ll try to 
answer them as best I can.

> On Apr 24, 2016, at 3:44 AM, Brent Royal-Gordon  
> wrote:
> 
>> We took this feedback seriously, and I would like to share with you the 
>> start of an important journey for some of the most commonly used APIs on all 
>> of our platforms: adopting value semantics for key Foundation types.
> 
> This proposal is way cool, and I think you've selected a great starting set 
> of APIs.
> 
> Of the other candidate APIs you mentioned, I'm definitely looking forward to 
> AttributedString and some parts of the NSURL Loading system (primarily the 
> requests and responses; the connections and sessions should probably be 
> object types). Predicate, OrderedSet, CountedSet, and possibly Number and 
> Value make sense as well.
> 
> However, I think that Locale, Progress, Operation, Calendar, and Port are 
> poor candidates for becoming value types, because they represent specific 
> resources which may be partially outside of your thread's/process's control; 
> that is, they're rather like NS/UIView, in that they represent a specific, 
> identifiable "thing" which cannot be copied without losing some aspect of its 
> meaning.

Agreed, that is why they are at the bottom in the “not value types” section. =)

> (I also see little value in an Error type; honestly, in the long run I'd like 
> to see Swift-facing Foundation grow towards pretending that NSError doesn't 
> exist and only ErrorProtocol does.)
> 

ErrorProtocol is a kind-of-NSError today, as the compiler magically generates 
the two NSError primitives for you (code and domain), but does not expose this 
anywhere to make it possible to do the correct thing w.r.t. localized error 
messages.

Anyway this is a complicated topic, which is why I deferred it to another 
proposal.

>> The following code is a more natural match for the way Swift developers 
>> would expect this to work:
>> 
>>  var myDate = Date()
>>  myDate.addTimeInterval(60) // OK
>>  
>>  let myOtherDate = Date()
>>  myOtherDate.addTimeInterval(60) // Error, as expected
> 
> The semantic is definitely more what Swift users expect, but the name may not 
> be. As far as I can tell, this method should be called `add`, with 
> `TimeInterval` elided under the "omit needless words" rule of Swift API 
> translation. (Or just call it `+=`, of course…)

The actual API uses +=, this is just an example to prove a point.

> 
>> URL  NSURL
>> URLComponentsNSURLComponents
> 
> 
> Have you considered unifying these? NSURL has no mutable counterpart, but 
> NSURLComponents sort of informally plays that role. As it is, it seems like 
> URL would not really be able to support mutation very well—the operations 
> would all be nonmutating under the hood.
> 

The pattern here is that URLComponents properties are basically the arguments 
to a factory that creates URL. They aren’t really the same thing as a URL 
itself. Also, like DateComponents or PersonNameComponents, you may want to 
represent a “partial URL” as some kind of intermediate object, in which case a 
URLComponents would be the right type because a URL should be valid.

>> Using Swift structures for our smallest types can be as effective as using 
>> tagged pointers in Objective-C.
> 
> 
> Have you looked at the performance and size of your value type designs when 
> they're made Optional? In the general case, Optional works by adding a tag 
> byte after the wrapped instance, but for reference types it uses the 0x0 
> address instead. Thus, depending on how they're designed and where Swift is 
> clever enough to find memory savings, these value types might end up taking 
> more memory than the corresponding reference types when made Optional, 
> particularly if the reference types have tagged pointer representations.
> 

That’s true, but not all reference types wind up as tagged pointers either. 
NSString, for example, does it based on the content and length of the C string.

I’m ok with the tradeoff here for the few types we have in this category 
(primarily Date).

>>if !isUniquelyReferencedNonObjC(&_box) {
> 
> 
> Something I have often wondered about: Why doesn't `isUniquelyReferenced(_:)` 
> use `-retainCount` on Objective-C objects? Alternatively, why not use 
> `-retainCount` on fields in your value types when you're trying to implement 
> COW behavior? It seems like that would allow you to extend the copy-on-write 
> mechanism to Objective-C objects. I know that `-retainCount` is usually not 
> very useful, but surely this copy-on-write situation, where you are using it 
> in an advisory fashion and an overestimated retain count will simply cause 
> you to unnecessarily lose some efficiency, is the exception to the rule?
> 
> There are likely good reasons for this decision—they simply aren't obvious, 
> and I'd like to understand them.
> 
> -- 
> Brent Royal-Gordon
> 

Re: [swift-evolution] Mutability for Foundation types in Swift

[Tony Parker via swift-evolution]

Hi Jose,

> On Apr 22, 2016, at 2:53 PM, Jose Cheyo Jimenez <ch...@masters3d.com> wrote:
> 
> Hi Tony, 
> 
> Would value types like NSDateFormatterStyle or NSCalendarUnit etc get renamed 
> with out `NS` in Swift ?
> 

This, we are still iterating on in our team. I hope to have an update on that 
soon.

> Would supporting classes to NSDate like NSDateComponents NSDateFormatter etc 
> also get value semantics? 
> 
> Thank you!
> 

NSDateComponents will, but I forgot to put it on the list! Thanks for noticing 
that. I will fix it.

NSDateFormatter will remain a class type, at least for now. Formatters are part 
of a public class hierarchy (inheriting from NSFormatter), so if we want to 
turn them into value types I think we’ll need some additional motivation to 
change their API surface in this way.

Thanks,
- Tony

> 
>> On Apr 22, 2016, at 10:18 AM, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Dear swift-evolution denizens,
>> 
>> As you know from our announcement of Swift Open Source and our work on 
>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for 
>> Foundation. We want to to make the cross-platform Foundation API that is 
>> available as part of swift-corelibs feel like it is not tied to just Darwin 
>> targets. We also want to reinforce the idea that new Foundation API must fit 
>> in with the language, standard library, and the rapidly evolving design 
>> patterns we see in the community.
>> 
>> You challenged us on one part of this plan: some Foundation API just doesn’t 
>> “feel Swifty”, and a large part of the reason why is that it often does not 
>> have the same value type behavior as other Swift types. We took this 
>> feedback seriously, and I would like to share with you the start of an 
>> important journey for some of the most commonly used APIs on all of our 
>> platforms: adopting value semantics for key Foundation types.
>> 
>> We have been working on this for some time now, and the set of diffs that 
>> result from this change is large. At this point, I am going to focus effort 
>> on an overview of the high level goals and not the individual API of each 
>> new type. In order to focus on delivering something up to our quality 
>> standards, we are intentionally leaving some class types as-is until a 
>> future proposal. If you don’t see your favorite class on the list — don’t 
>> despair. We are going to iterate on this over time. I see this as the start 
>> of the process.
>> 
>> One process note: we are still trying to figure out the best way to 
>> integrate changes to API that ship as part of the operating system (which 
>> includes Foundation) into the swift-evolution review process. 
>> Swift-evolution is normally focused on changes to functionality in the 
>> compiler or standard library. In general, I don’t expect all new Foundation 
>> API introduced in the Darwin/Objective-C framework to go through the open 
>> source process. However, as we’ve brought up this topic here before, I felt 
>> it was important to bring this particular change to the swift-evolution list.
>> 
>> As always I welcome your feedback.
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md>
>> 
>> Thanks,
>> - Tony
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] Mutability for Foundation types in Swift

[Tony Parker via swift-evolution]

Hi Riley,

> On Apr 22, 2016, at 1:34 PM, Riley Testut <rileytes...@gmail.com> wrote:
> 
> Very happy to see this proposal; felt strange that for a language so focused 
> on value-types an entire framework open sourced with the language was 
> composed entirely of reference-types (albeit for obvious reasons). So +1 for 
> that.
> 
> One particular section that caught my interest was this:
>> The most obvious drawback to using a struct is that the type can no longer 
>> be subclassed. At first glance, this would seem to prevent the customization 
>> of behavior of these types. However, by publicizing the reference type and 
>> providing a mechanism to wrap it (mySubclassInstance as ValueType), we 
>> enable subclasses to provide customized behavior.
> 
> I'm incredibly biased, but I recently proposed and submitted a pull request 
> that would introduce "factory initializers" to the language 
> (https://github.com/apple/swift-evolution/pull/247 
> <https://github.com/apple/swift-evolution/pull/247>). The full proposal has 
> more info, but essentially factory initializers would allow for directly 
> returning initialized types from designated factory initializers, similar to 
> how initializers are implemented in Objective-C.
> 
> Anyway, I feel the Factory Initializer proposal would work very well with 
> this Foundation proposal. While I believe the current suggestion of casting 
> the reference type as the value type works well, I don't believe it is 
> necessarily the client of the API's job to use it; I believe it would make 
> far more sense for there to be an extension adding additional factory 
> initializers to the class, which would determine the underlying reference 
> type to use based on the input parameters.
> 
> For example, here is the example of using a custom subclass for the Data type 
> mentioned in this Foundation proposal:
>> /// Create a Data with a custom backing reference type.
>> class MyData : NSData { }
>> let dataReference = MyData()
>> let dataValue = dataReference as Data // dataValue copies dataReference
> 
> I personally would rather see something akin to this:
> 
> public extension Data {
>   factory init(inputData: ...)
>   {
>   if ... {
>   // Return subclass best suited for storing this 
> particular input data
>   return MyData(inputData) as Data
>   }
>   else {
>   let data = NSData()
> 
>   /* OMITTED: add hypothetical inputData to NSData 
> depending on what it is */
>   
>   return data 
> }
> 
> This means the client of the API never has to worry about which subclass is 
> best suited for them; everything would "just work". This also better mimics 
> the existing class cluster pattern in Foundation, which might help with this 
> transition should my proposal be accepted.
> 
> Regardless though, very happy to see this being pushed forward. Just thought 
> I'd suggest ways to make this proposal (hopefully) easier to both implement 
> and use :)

Thanks for your feedback.

For what it’s worth, I’m fully in support of your factory type proposal as 
well. I think we need it in order to finish a complete implementation of 
swift-corelibs-foundation, at the very least.

We can certainly extend these types to include use of the factory types once we 
get them into the language.

- Tony

> 
> On Apr 22, 2016, at 12:52 PM, Tony Parker via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Hi David,
>> 
>>> On Apr 22, 2016, at 12:13 PM, David Waite <da...@alkaline-solutions.com 
>>> <mailto:da...@alkaline-solutions.com>> wrote:
>>> 
>>> Amazing, I am really looking forward to this feature!
>>> 
>>> Comments:
>>> 
>>> - For Locale and Calendar, one possible Swift layout would be to synthesize 
>>> a protocol and to use that to represent bridged API. You could then bridge 
>>> inbound to either the immutable value type or the dynamic class-based type. 
>>> On the swift side, these are constructed as two distinct types.
>> 
>> That’s an interesting approach, I’ll consider that for these.
>> 
>>> 
>>> - For any of these types, are there improvements (similar to String) which 
>>> would be worth making before exposing ’the’ Swift type and API? The ones 
>>> I’m specifically worried about are Date and URL, since I’ve seen so many 
>>> standard language time and networking API show their age over time.
>>> 
>>>

Re: [swift-evolution] Mutability for Foundation types in Swift

[Tony Parker via swift-evolution]

Hi David,

> On Apr 22, 2016, at 12:13 PM, David Waite <da...@alkaline-solutions.com> 
> wrote:
> 
> Amazing, I am really looking forward to this feature!
> 
> Comments:
> 
> - For Locale and Calendar, one possible Swift layout would be to synthesize a 
> protocol and to use that to represent bridged API. You could then bridge 
> inbound to either the immutable value type or the dynamic class-based type. 
> On the swift side, these are constructed as two distinct types.

That’s an interesting approach, I’ll consider that for these.

> 
> - For any of these types, are there improvements (similar to String) which 
> would be worth making before exposing ’the’ Swift type and API? The ones I’m 
> specifically worried about are Date and URL, since I’ve seen so many standard 
> language time and networking API show their age over time.
> 
> -DW

We’re absolutely going to be making Swift-specific improvements to many of 
these types. I think the resulting API is better in many ways. For example, on 
URL the main improvement is that the resource values dictionary is now struct 
type with a lot of strongly-typed properties. It’s still got a lot of optionals 
because of the way that the underlying fetch works, but it’s better. Date gains 
mutating methods along with support for operators like += and < >. 

One of the guiding principles of our effort was evolution over revolution. 
Foundation is obviously used in tons and tons of API. We want to maintain 
conceptual compatibility with the entire OS X / iOS / watchOS / tvOS SDK when 
it is imported into Swift. Hopefully this also means that converting from 
reference to value types in your own uses of these API does not require a 
complete rethink of how you use them, but still provide the benefits outlined 
in the proposal. We’ll continue to iterate and improve over time.

Thanks,

- Tony

>  
>> On Apr 22, 2016, at 11:18 AM, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Dear swift-evolution denizens,
>> 
>> As you know from our announcement of Swift Open Source and our work on 
>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for 
>> Foundation. We want to to make the cross-platform Foundation API that is 
>> available as part of swift-corelibs feel like it is not tied to just Darwin 
>> targets. We also want to reinforce the idea that new Foundation API must fit 
>> in with the language, standard library, and the rapidly evolving design 
>> patterns we see in the community.
>> 
>> You challenged us on one part of this plan: some Foundation API just doesn’t 
>> “feel Swifty”, and a large part of the reason why is that it often does not 
>> have the same value type behavior as other Swift types. We took this 
>> feedback seriously, and I would like to share with you the start of an 
>> important journey for some of the most commonly used APIs on all of our 
>> platforms: adopting value semantics for key Foundation types.
>> 
>> We have been working on this for some time now, and the set of diffs that 
>> result from this change is large. At this point, I am going to focus effort 
>> on an overview of the high level goals and not the individual API of each 
>> new type. In order to focus on delivering something up to our quality 
>> standards, we are intentionally leaving some class types as-is until a 
>> future proposal. If you don’t see your favorite class on the list — don’t 
>> despair. We are going to iterate on this over time. I see this as the start 
>> of the process.
>> 
>> One process note: we are still trying to figure out the best way to 
>> integrate changes to API that ship as part of the operating system (which 
>> includes Foundation) into the swift-evolution review process. 
>> Swift-evolution is normally focused on changes to functionality in the 
>> compiler or standard library. In general, I don’t expect all new Foundation 
>> API introduced in the Darwin/Objective-C framework to go through the open 
>> source process. However, as we’ve brought up this topic here before, I felt 
>> it was important to bring this particular change to the swift-evolution list.
>> 
>> As always I welcome your feedback.
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md>
>> 
>> Thanks,
>> - Tony
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] Mutability for Foundation types in Swift

[Tony Parker via swift-evolution]

Hi Nate,

> On Apr 22, 2016, at 11:55 AM, Nate Cook <natec...@gmail.com> wrote:
> 
> This looks amazing—really looking forward to seeing the progression here!
> 
> I do have a question about how copy-on-write is handled for larger data types 
> like Data (née NSData). The standard library types that can use bridged 
> storage use immutable classes until there's a mutation, at which point the 
> contents are copied into native storage. From then on (as long as the native 
> storage is still uniquely referenced) the contents can be mutated in place 
> without any copying.
> 
> With the proposed value semantics around an NSData instance, how do you 
> handle that in-place mutation? When bridging from Objective-C to Swift, it 
> sounds like you'll call copy() on an NSData instance. Does NSMutableData 
> perform the role of the native storage when mutating? If so, is another copy 
> needed when bridging a Data instance backed by NSMutableData back to NSData? 
> 
> The proposal says: "For reference-holding types like Data, we simply pass our 
> interior NSData pointer back to Objective-C. The underlying data is not 
> copied at bridging time." If the Data instance is backed by NSMutableData, 
> can we still successfully check for uniqueness once we pass it back to 
> Objective-C?
> 
> Thanks!
> Nate
> 

In reality, the stored reference object is a Swift class with Swift-native ref 
counting that implements the methods of the Objective-C NSData “protocol” (the 
interface described by @interface NSData) by holding a “real” NSMutableData 
ivar and forwarding messages to it. This technique is actually already in use 
in the standard library. 

Starts around here:

https://github.com/apple/swift/blob/master/stdlib/public/core/Runtime.swift.gyb#L497

and then look here:

https://github.com/apple/swift/blob/e67acdb70d8887507747d0ed14898306f07a74f4/stdlib/public/stubs/SwiftNativeNSXXXBase.mm.gyb#L59

and finally here:

https://github.com/apple/swift/blob/4fd8418ba724963e1414e4d720a05bb9cc5fb77a/stdlib/public/core/SwiftNativeNSArray.swift#L40

This means that if an Objective-C client calls retain on this object (which is 
a _SwiftNativeNSData), it actually calls swift_retain, which mutates the Swift 
ref count. This means that a call to _isUniquelyReferencedNonObjC from Swift 
actually still works on this class type.

- Tony

> 
>> On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Dear swift-evolution denizens,
>> 
>> As you know from our announcement of Swift Open Source and our work on 
>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for 
>> Foundation. We want to to make the cross-platform Foundation API that is 
>> available as part of swift-corelibs feel like it is not tied to just Darwin 
>> targets. We also want to reinforce the idea that new Foundation API must fit 
>> in with the language, standard library, and the rapidly evolving design 
>> patterns we see in the community.
>> 
>> You challenged us on one part of this plan: some Foundation API just doesn’t 
>> “feel Swifty”, and a large part of the reason why is that it often does not 
>> have the same value type behavior as other Swift types. We took this 
>> feedback seriously, and I would like to share with you the start of an 
>> important journey for some of the most commonly used APIs on all of our 
>> platforms: adopting value semantics for key Foundation types.
>> 
>> We have been working on this for some time now, and the set of diffs that 
>> result from this change is large. At this point, I am going to focus effort 
>> on an overview of the high level goals and not the individual API of each 
>> new type. In order to focus on delivering something up to our quality 
>> standards, we are intentionally leaving some class types as-is until a 
>> future proposal. If you don’t see your favorite class on the list — don’t 
>> despair. We are going to iterate on this over time. I see this as the start 
>> of the process.
>> 
>> One process note: we are still trying to figure out the best way to 
>> integrate changes to API that ship as part of the operating system (which 
>> includes Foundation) into the swift-evolution review process. 
>> Swift-evolution is normally focused on changes to functionality in the 
>> compiler or standard library. In general, I don’t expect all new Foundation 
>> API introduced in the Darwin/Objective-C framework to go through the open 
>> source process. However, as we’ve brought up this topic here before, I felt 
>> it was important to bring this parti

[swift-evolution] Mutability for Foundation types in Swift

[Tony Parker via swift-evolution]

Dear swift-evolution denizens,

As you know from our announcement of Swift Open Source and our work on naming 
guidelines, one of our goals for Swift 3 is to “drop NS” for Foundation. We 
want to to make the cross-platform Foundation API that is available as part of 
swift-corelibs feel like it is not tied to just Darwin targets. We also want to 
reinforce the idea that new Foundation API must fit in with the language, 
standard library, and the rapidly evolving design patterns we see in the 
community.

You challenged us on one part of this plan: some Foundation API just doesn’t 
“feel Swifty”, and a large part of the reason why is that it often does not 
have the same value type behavior as other Swift types. We took this feedback 
seriously, and I would like to share with you the start of an important journey 
for some of the most commonly used APIs on all of our platforms: adopting value 
semantics for key Foundation types.

We have been working on this for some time now, and the set of diffs that 
result from this change is large. At this point, I am going to focus effort on 
an overview of the high level goals and not the individual API of each new 
type. In order to focus on delivering something up to our quality standards, we 
are intentionally leaving some class types as-is until a future proposal. If 
you don’t see your favorite class on the list — don’t despair. We are going to 
iterate on this over time. I see this as the start of the process.

One process note: we are still trying to figure out the best way to integrate 
changes to API that ship as part of the operating system (which includes 
Foundation) into the swift-evolution review process. Swift-evolution is 
normally focused on changes to functionality in the compiler or standard 
library. In general, I don’t expect all new Foundation API introduced in the 
Darwin/Objective-C framework to go through the open source process. However, as 
we’ve brought up this topic here before, I felt it was important to bring this 
particular change to the swift-evolution list.

As always I welcome your feedback.

https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
 


Thanks,
- Tony



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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Tony Parker via swift-evolution]

> On Apr 13, 2016, at 12:57 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Apr 13 2016, Dave Abrahams  wrote:
> 
>>> Reverse is the best opposite we have of advance, so it makes sense to
>>> me. 
>> 
>> Oh, I get it.
>> 
>>> Or we could use retreat. =) There are other pairs of words that work
>>> as well, like “increment/decrement”. 
>> 
>> Yeah, unfortunately those carry an incorrect implication when the
>> indices are numbers, because, e.g. the collection might be offsetting
>> the number by 2 for each position.  One could of course argue that using
>> numbers that way as indices was a bad design choice.
>> 
>> I'll have to think about that idea again.  We considered and rejected it
>> for a reason, but it might not be a really strong one.  Thanks for
>> bringing it up.
> 
> ...and having talked it over at lunch, now I remember why we rejected
> it: there's no good way to make a nonmutating version.
> 
>  let x = c.incremented(i)   // reads like an assertion about the past
>  let y = c.incrementing(i)  // reads like it has side-effects and returns c, 
> or
> // a new version of c
> 

In fact, it does return a new version* of c; just like this:

let s2 = myString.appending(“foo”)

*new version: the result is related to the argument

This works out great:

let next = c.incrementing(first)
c.increment()

- Tony

> APIs where the receiver returns a modified version of an argument don't
> lend themselves to verb forms.
> 
> -- 
> Dave
> 
> ___
> 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] [Review] SE-0065 A New Model for Collections and Indices

[Tony Parker via swift-evolution]

> On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Thanks for your review, Tony!
> 
> on Mon Apr 11 2016, Tony Parker  > wrote:
> 
>>> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "A New Model for Collections and Indices" begins now and runs 
>>> through April 18th. The proposal is available here:
>> 
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at:
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under
>>> review through constructive criticism and, eventually, determine the
>>> direction of Swift. When writing your review, here are some
>>> questions you might want to answer in your review:
>>> 
>>> * What is your evaluation of the proposal?
>> 
>> I agree with the general direction and scope of the proposal, but I
>> think the names could use some changes. Specifically, I don’t think
>> the fallback to ‘form’ is required. 
> 
> It's not a fallback whatsoever.  The updated guidelines referenced from
> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
>  
> 
> (which was accepted this morning; announcement forthcoming) make the
> “form” prefix a first-class citizen that one chooses based on the
> noun-ness of the underlying operation.  Furthermore, *treating*
> “formXXX” as a fallback and avoiding it will continue to strengthen the
> sense that it's not something we should normally use, leading to more
> naming arguments in the future.  It's a strong guideline and as long as
> we have it, we shouldn't be afraid to apply it, thereby increasing
> uniformity and predictability.
> 
> [To all my fellow “InPlace” lovers out there: yes, another guideline
> might be more optimal, but this is the guideline we have/can get].
> 

In other cases, the mutating pair of methods refer to the receiver, not the 
argument. 

x = y.union(z) // new value x
y.formUnion(z) // mutates y, not z

x = y.successor(z) // new value x
y.formSuccessor(z) // mutates z (or replaces), not y

I think using the form prefix here will confuse this case with the others, when 
they are meaningfully different.

>> It would be a significant readability improvement to use a meaningful
>> verb to describe the action of altering the argument. The methods that
>> create new indices probably need a label on the first argument,
>> because otherwise it looks as if the IndexDistance is what is
>> described by ‘index’.
>> 
>> Proposed:
>> 
>>  func successor(of i: Index) -> Index
>>  func formSuccessor(i: inout Index)
>> 
>> Instead, I suggest:
>> 
>>  func successor(of i : Index) -> Index
>>  func advance(i: inout Index)
> 
> Why is that an improvement?  It loses the correspondence between the
> operations, which are still a mutating/nonmutating pair.  What's it got
> to recommend it?  I have the same question about all of the suggestions
> below.

It’s an improvement because it is much easier to read and understand what it 
means. The phrase “form successor” only makes sense if you dive into the naming 
guidelines to see why we have the “form” prefix in the first place. Plus, as I 
said, the form prefix implies a mutation of the wrong argument.

> 
>> Proposed:
>> 
>>  func index(n: IndexDistance, stepsFrom i: Index) -> Index
>>  func index(n: IndexDistance, stepsFrom i: Index, limitedBy limit: Index) -> 
>> Index
>>  func formIndex(n: IndexDistance, stepsFrom i: inout Index)
>>  func formIndex(n: IndexDistance, stepsFrom i: inout Index, limitedBy limit: 
>> Index)
>> 
>> Suggested (taking into account Nate’s suggestion of reversing the order):
>> 
>>  func index(startingAt i: Index, movedBy n: IndexDistance) -> Index
>>  func index(startingAt i: Index, movedBy n: IndexDistance, limitedBy limit: 
>> Index) -> Index
> 
> I find Nate Cook's concerns about the use of “index” here (a mental
> clash with unrelated methods having the same basename) especially
> convincing.  So I think I want to look for other names for these.
> 
>> 
>>  func move(i : inout Index, by n: IndexDistance) 
>>  func move(i : inout Index, by n: IndexDistance, limitedBy limit: Index)
>> 
>> Proposed:
>> 
>>  func predecessor(of i: Index) -> Index
>>  func formPredecessor(i: inout Index)
>> 
>> Suggested:
>> 
>>  func predecessor(of i: Index) -> Index
>>  func reverse(i: inout Index)
>> 
>> I think reversing 

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

[Tony Parker via swift-evolution]

> On Dec 19, 2015, at 7:59 PM, Dmitri Gribenko  wrote:
> 
> On Fri, Dec 18, 2015 at 1:47 PM, Paul Cantrell via swift-evolution 
> > wrote:
> I was quite surprised to learn that it’s possible to create Swift strings 
> that do not contain things other than valid Unicode characters. Is it 
> feasible to guarantee that this cannot happen?
> 
> String.init(bytes:encoding:) is failable, and does in fact validate that the 
> given bytes are decodable with the given encoding in most circumstances:
> 
> // Returns nil
> String(
> bytes: [0xD8, 0x00] as [UInt8],
> encoding: NSUTF8StringEncoding)
> 
> However, that initializer does not reject invalid surrogate characters in 
> UTF-16:
> 
> // Succeeds (wat?!)
> let bogusStr = String(
> bytes: [0xD8, 0x00] as [UInt8],
> encoding: NSUTF16BigEndianStringEncoding)!
> 
> Adding this would be a useful guarantee, I support this.  The current 
> behavior looks inconsistent to me.  OTOH, the current behavior of 
> String(bytes:encoding:) mirrors the behavior of the NSString method, so this 
> would create inconsistency.  But I think the extra guarantee is worth it.
> 
> Tony, what do you think?
> 

NSString deals with this issue more on the ‘get’ side. For example, 
CFStringGetBytes has a ‘lossByte’ for use in replacement when the requested 
encoding cannot represent something stored by the receiver string. Also, the 
abstract NSString interface can be extended to add additional encodings (which 
is why the string encoding values are not an enumeration).

- Tony

> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/


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

Re: [swift-evolution] Testing Assertions

[Tony Parker via swift-evolution]

Hi Mohamed,

I agree it’s very difficult to test assertions in XCTest today. This approach 
looks interesting, but I’m not sure how it’s possible to implement within 
XCTest’s current architecture. Do you have any idea how this would be 
implemented? 

- Tony

> On Dec 31, 2015, at 1:35 AM, Mohamed Ebrahim Afifi via swift-evolution 
>  wrote:
> 
> Right now, we cannot easily test failed assertions (assert, assertionFailure, 
> precondition, preconditionFailure, fatalError) in our own code without some 
> hacks in the code under test. Like this example 
> https://github.com/mohamede1945/AssertionsTestingExample 
> 
> 
> So, my suggestion is to add for XCTest something very similar to 
> expectCrashLater that is defined here 
> https://github.com/apple/swift/blob/9b15d03b73b9e8a6dbd3f71b5c78660a359e8e26/stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
>  
> 
> and used in tests like this example 
> https://github.com/apple/swift/blob/master/validation-test/stdlib/Assert.swift
>  
> 
> 
> What do you think?
> 
> Best Regards,
> Mohamed Afifi
>  ___
> 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] Philosophy question: Foundation and Standard Library

[Tony Parker via swift-evolution]

Not that I need to say this, but I’ll chime in anyway with a big +1 to what 
Chris said. =)

Fortunately, the current code owners for swift-corelibs-foundation are the same 
people that work on Foundation for all of our other platforms. That means we’re 
in a great position to make Foundation great in Swift everywhere. As Chris 
said, we have a giant task of getting the fundamentals up and running without 
Objective-C, so that is our primary goal for Swift 3. However, we are 
interested in all kinds of improvements in the long term.

Thanks,
- Tony

> On Jan 1, 2016, at 10:32 PM, Rod Brown via swift-evolution 
>  wrote:
> 
> Brilliant. Makes sense and seems to be a best-of-both-worlds approach.
> 
> - Rod
> 
> On 2 Jan 2016, at 3:16 PM, Chris Lattner  wrote:
> 
 On Jan 1, 2016, at 3:32 PM, Rod Brown  wrote:
 Thanks Chris.  I want to figure out what the guiding principles are before 
 I blow any further proposal-capital. This gives me a good place to start 
 chewing on some thoughts.  In particular, I'm considering two scenarios.
 
 First, are things that seem unnaturally split between both places, such as 
 "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" 
 (fnd, NSString). The latter super non-Swifty but could easily evolve to be 
 componentsSeparatedBySequence and rangeOfSequence. (We had some nifty 
 attempts at this last night on #swift-lang in terms of trying to do this 
 with reasonable speed.)
>>> 
>>> I find this a very good point and points to something interesting with 
>>> Swift Foundation.
>>> 
>>> Is it more important to maintain design closely similar to Objective-C 
>>> foundation, or to push for a more "swift" design philosophy that may indeed 
>>> push away from Objective C foundation?
>> 
>> Our goal is to pull the two together, so that Foundation ultimately feels 
>> 100% Swift native.  This is one major reason that we’re doing 
>> corelibs-foundation the way we are in the first place, to force the design 
>> discussions to happen.
>> 
>> We plan to do this through a combination of improving how Swift imports 
>> Objective-C APIs (something that made a lot of progress in Swift 2, and 
>> should make at least some more progress in Swift 3) as well as by adding 
>> “more swifty” interfaces manually where it makes sense (e.g. through 
>> overlays).  This is something you should discuss on a case by case basis 
>> with the corelibs folks, because there is no one blanket answer.
>> 
>>> We are essentially outlining some of the foundational (no pun intended) 
>>> elements of Swift, and a clean, coherent design makes sense. That said, I 
>>> suspect branching away from Objective-C Foundation may create confusion for 
>>> developers who write both for Apple Platforms and for servers - "Am I using 
>>> Swift Foundation, or Objective-C Foundation?”
>> 
>> This would be a pretty big problem, defeating the goal of supporting 
>> cross-platform development with Swift.
>> 
>> -Chris
>> 
> ___
> 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