Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Rod Brown via swift-evolution]

> What is your evaluation of the proposal?
+1 to the idea. Disappointing that we don’t seem to be able to add this to 
@objc enums. Could we come up with some kind of workaround for this?

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, this is a common problem where I constantly write all case static 
properties, and where I use the count. To be honest, for such a robust system, 
I found it a glaring omission.

> Does this proposal fit well with the feel and direction of Swift?
Yes, the way the proposed solution is designed seems to work well.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I’ve done a lot of hacked enum “allCases” implementations in Swift, and we 
really didn’t have this power in the other languages I’ve used.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Quick reading.

Sent from my iPad

> On 9 Jan 2018, at 6:02 am, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0194 "Derived Collection of Enum Cases" begins now and runs 
> through January 11, 2018. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.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/0194-derived-collection-of-enum-cases.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 Gregor
> 
> 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

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

[Rod Brown via swift-evolution]

I think you make a fair point here - either case is currently untestable in a 
non-exhaustive enum.

Perhaps this pushes harder on the “future” case and a way we can test this in 
Unit Tests when we @testable import other frameworks to simulate an additional 
case.

> On 22 Dec 2017, at 5:36 am, Kevin Nattinger via swift-evolution 
>  wrote:
> 
>>> [...]
>> 
>> Hi, Nacho. This is discussed in the proposal as "'future' cases" under 
>> "Alternatives considered". The main blocker was that such a case becomes 
>> untestable (see also "Testing invalid cases"). That didn't seem like an 
>> acceptable state of affairs to me or to the people I had originally 
>> discussed the proposal with, but maybe the community feels differently?
> 
> As you state in the proposal, using `default` instead is exactly as 
> untestable, in exactly the same way. Using that as an argument against future 
> but not default is disingenuous. And default additionally introduces the 
> enormous issue of killing compile-time safety, while future does not..
> 
>> 
>> I would love if someone could think of something I haven't yet; by no means 
>> do I think I'm the only one who can have ideas in this space.
>> 
>> Jordan
>> ___
>> 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] [Review] SE 0192 - Non-Exhaustive Enums

[Rod Brown via swift-evolution]

Thanks for this response, John.

I think you’re right. This would be very helpful. It a) helps those who are 
source compiling with their app, and b) avoids fragmenting the language because 
it would be a core understanding of the code you are compiling, rather than 
creating a new “variant” of Swift for the binary compatible framework vs client 
code.

- Rod

> On 22 Dec 2017, at 6:26 am, John McCall via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On Dec 20, 2017, at 12:35, Karl Wagner  wrote:
 
 
 
> On 20. Dec 2017, at 19:54, Jordan Rose  wrote:
> 
> 
> 
>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution 
>>  wrote:
>> 
>> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs 
>> through January 3, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
> +1, it needs to happen (and ASAP, since it _will_ introduce 
> source-breaking changes one way or the other).
> 
> I think non-exhaustive is the correct default. However, does this not 
> mean that, by default, enums will be boxed because the receiver doesn’t 
> know their potential size?
 
 It's not always boxing, but yes, there will be more indirection if the 
 compiler can't see the contents of the enum. (More on that below.)
 
 
> That would mean that the best transition path for multi-module Apps would 
> be to make your enums @exhaustive, rather than adding “default” 
> statements (which is unfortunate, because I imagine when this change 
> hits, the way you’ll notice will be complaints about missing “default” 
> statements).
 
 Yep, that's going to be the recommendation. The current minimal-for-review 
 implementation does not do this but I'd like to figure out how to improve 
 that; at the very least it might be a sensible thing to do in the migrator.
 
> 
> I do have some thoughts about how we could ease the transition (for this 
> and other resilience-related changes), but it’s best to leave that to a 
> separate discussion.
> 
> The one thing I’m still not overly fond of is the name - I would like us 
> to keep the set of resilience/optimisation related keywords to a minimum. 
> “exhaustive” for enums feels an awful lot like “fixed_contents” for 
> structs - couldn’t we come up with a single name which could be used for 
> both? I don’t think anybody’s going to want to use “exhaustive” for 
> structs.
 
 The core team was very focused on this too, but I contend that 
 "exhaustive" is not about optimization and really isn't even about 
 "resilience" (i.e. the ability to evolve a library's API while preserving 
 binary compatibility). It's a semantic feature of an enum, much like 
 'open' or 'final' is for classes, and it affects what a client can or 
 can't do with an enum. For libaries compiled from source, it won't affect 
 performance at all—the compiler still knows the full set of cases in the 
 current version of the library even if the programmer is forced to 
 consider future versions.
 
 I'm working on the fixed-contents proposal now, though it won't be ready 
 for a while, and the same thing applies there: for structs compiled from 
 source, the compiler can still do all the same optimizations. It's only 
 when the library has binary compatibility concerns that we need to use 
 extra indirection, and then "fixed-contents" becomes important. (As 
 currently designed, it doesn't affect what clients can do with the struct 
 at all.) This means that I don't expect a "normal" package author to write 
 "fixed-contents" at all (however it ends up being spelled), whereas 
 "exhaustive" is a fairly normal thing to consider whenever you make an 
 enum public.
 
 I hope that convinces you that "fixed-contents" and "exhaustive" don't 
 need to have the same name. I don't think anyone loves the particular name 
 "exhaustive", but as you see in the "Alternatives considered" we didn't 
 manage to come up with anything significantly better. If reviewers all 
 prefer something else we'd consider changing it.
 
 Thanks for responding!
 Jordan
 
>>> 
>>> When you say “libraries compiled from source”, what do you mean?
>> 
>> - Other targets in your project
>> - Source packages built through SwiftPM / CocoaPods / Carthage / other
>> 
>> And I was being imprecise with the terminology, but also

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

[Rod Brown via swift-evolution]

Thanks for this reply, Chris. It addresses most of my concerns with the current 
design - scalability (with the attributes), confusion (over the meaning of ABI) 
and changes in declarations as things change.

I think your approach is a far better solution.

> On 21 Dec 2017, at 6: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 example.
> 
> It would be better to go with something like “apiPublic” or “symbolPublic” or 
> “linkableButNotAccessible” or something else long.  This will not be commonly 
> used in user code, so being long and descriptive is a good thing.
> 
> 
> Counterproposal:
> 
> There is a simple way to address the two concerns above: we already have a 
> framework for handling API evolution with binary frameworks, the @available 
> attribute.  We can spell these “attributes” as:
> 
>   @available(inlinable)   // this symbol has been inlinable since it was 
> introduced
> 
> which generalizes properly when we add version ranges:
> 
>   @available(iOS 14, *)   // this was introduced in iOS 14
>   

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Rod Brown via swift-evolution]

> On 20 Dec 2017, at 9:58 am, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
> January 3, 2018.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
> Reviews are an important part of the Swift evolution process. All review 
> feedback 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/0192-non-exhaustive-enums.md
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
+1. I was involved in some of the earlier discussions and discussed the pros 
and cons of each way, tossed and turned, and to be honest, like “public vs 
open” I think this comes out to “it’s the best compromise”. 


We need to handle additional cases safely, and people need to think carefully 
as it will be a compatibility issue to leave new enum cases unhandled. This 
proposal sums this up well.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
Yes. This is an important change.

> Does this proposal fit well with the feel and direction of Swift?
> 
Feel? Not 100%, but this is a compromise for compatibility. Direction? Yes. It 
is in a direction to allow ABI compatibility, so yes.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
I’ve dealt with not handling extra cases in Obj-C, and handling the 
compatibility issues with current Swift code.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
Somewhere between a quick reading and a in-depth study. This was one of my 
bugbears, something I knew we needed to sort out and I’m glad Jordan picked it 
up. I was involved in the conversation, and churned through the issues there in 
the earlier discussions.
> Thanks,
> Ted Kremenek
> 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

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

[Rod Brown via swift-evolution]

> On 17 Nov 2017, at 9:23 am, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE-0190 - Target environment platform condition" begins now 
> and runs through November 24, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0190-target-environment-platform-condition.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback 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/0190-target-environment-platform-condition.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
I think it’s good in theory, but I am concerned that there is currently only 
one example case of “simulator”, which also seems somewhat limited to Apple 
Platforms. Would another case “device” make sense?

Also a few questions I have:
How would this be extended to make sense for each platform? Say on platforms 
that actually have an emulator (rather than a simulator) how would this apply 
to those cases?
How does it make sense for the desktop where we could compile on the platform, 
and there would *be* no simulator?
Could there be other relevant cases we can add at other times?
Would these cases only make sense for Platform Vendors or IDEs to manage?
> Does this proposal fit well with the feel and direction of Swift?
> 
I think it makes sense to clean this up. The current checks are remarkably 
obscure and full of unsafe assumptions it would be good to sort out. But I’d 
like to see this solution fleshed out to a solution that is appropriate beyond 
the iOS/tvOS/watchOS ecosystems.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
No, but I have run into the same problems documented here in Obj-C and Swift.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
A quick reading.
> Thanks,
> Ted Kremenek
> 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

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

[Rod Brown via swift-evolution]

> On 7 Nov 2017, at 6:24 am, Tony Parker via swift-evolution 
>  wrote:
> 
> 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

I’ve been curious for some time about if we can do something about an opt-in 
import in Swift?

For example, currently UIGestureRecognizer in UIKit has “subclass only” methods 
that are protected and opt in. Importing UIKit itself doesn’t bring it in, and 
instead you need to specifically import UIKit.UIGestureRecognizerSubclass.

I realise this is a standalone case, but I’m wondering whether we can 
generalise this into something we can propose, to actively support nested 
scopes in the same way?

This would lend well to disclosing the internals like this. It would avoid 
users jumping straight for the internal types because they wouldn’t be there 
with “import Foundation” - it would require something eg “import Foundation.xyz 
”.

Was this part of an earlier discussion of modules etc?

- Rod

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

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

Re: [swift-evolution] JSONEncoder: Key strategies

[Rod Brown via swift-evolution]

I’m a fan. I understand that the CodingKey was the initial thought behind how 
to customise this, but a transformative approach is nice where there is a 
patterned update to keys.

Just one question: is there much performance impact by running through a key 
encoding strategy, even if it’s just a return in the case of `useDefaultKeys`?


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

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

[Rod Brown via swift-evolution]

> On 30 Oct 2017, at 6:16 am, Ted Kremenek via swift-evolution 
>  wrote:
> 
> A complementary tactic would be that migration tool support to Swift 5 would 
> insert the needed casts to NSString.  That way even if the magic lookup is 
> gone in Swift 5 the code could be automatically migrated and preserve the 
> same semantics.  If this came to a formal proposal I’d really like to see 
> something like that considered.

Agreed.

I think that a lot of the NSString APIs would be nice to bring over native to 
Swift, and for those that are not yet implemented (or won’t be for various 
reasons) this would be a reasonable solution.

> 
>> On Oct 24, 2017, at 3:56 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> I think to maintain source compatibility, the old behavior would be 
>> preserved until/if we remove -swift-version 4 mode. By deprecating it 
>> though, we won’t have to devote as much time to maintaining it going forward.
>> 
>> Slava
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Rod Brown via swift-evolution]

Kevin,

I really like your reasoning about avoiding the code churn, and finding a 
better way to flag something to avoid optional hoisting. I think its better 
solution to the problem. It also has the added benefit of kicking out to map() 
and getting a slightly optimised version of the same method - free speed win 
for devs who unknowingly used `flatMap` not realizing `map()` is the preferred 
solution.

I’m not sure the potential for confusion is enough to add a full new attribute 
flag for “Warning” though. It’s a minor win with a large relative overhead, and 
explaining in the deprecation warning that flat maps that act like direct maps 
are not recommended is reasonable enough.

- Rod




> On 9 Nov 2017, at 5:43 am, John McCall via swift-evolution 
>  wrote:
> 
> 
>> On Nov 8, 2017, at 1:20 PM, Kevin Ballard > > wrote:
>> 
>> On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote:
>>> 
 On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution 
 > wrote:
 
 On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>  
> 
> 
> • What is your evaluation of the proposal?
 
 This proposal is going to cause an insane amount of code churn. The 
 proposal suggests this overload of flatMap is used "in certain 
 circumstances", but in my experience it's more like 99% of all flatMaps on 
 sequences are to deal with optionals, not to flatten nested sequences.
 
> • Is the problem being addressed significant enough to warrant a change 
> to Swift?
 
 I don't think so. It's a fairly minor issue, one that really only affects 
 new Swift programmers anyway rather than all users, and it will cause far 
 too much code churn to be worthwhile.
 
 I'd much rather see a proposal to add a new @available type, something 
 like 'warning', that lets you attach an arbitrary warning message to a 
 call (which you can kind of do with 'deprecated' except that makes the 
 warning message claim the API is deprecated).
>>> 
>>> As review manager, I generally try to avoid commenting on threads, but I 
>>> find this point interesting in a way that, if you don't mind, I'd like to 
>>> explore.
>>> 
>>> Would this attribute not be a form of deprecation?  Certainly it acts to 
>>> discourage current and subsequent use, since every such use will evoke a 
>>> warning.
>>> 
>>> Is the word "deprecation" just too strong?  Often we think of deprecated 
>>> APIs as being ones with more functional problems, like an inability to 
>>> report errors, or semantics that must have seemed like a good idea at the 
>>> time.  Here it's just that the API has a name we don't like, and perhaps 
>>> "deprecation" feels unnecessarily judgmental.
>> 
>> What I'm suggesting is that we don't change the API name at all. That's why 
>> I don't want to use 'deprecated', because we're not actually deprecating 
>> something. I'm just suggesting an alternative way of flagging cases where 
>> the user tries to use flatMap but accidentally invokes optional hoisting, 
>> and that's by making a new overload of flatMap that works for non-optional 
>> (non-sequence) values and warns the user that what they're doing is better 
>> done as a map. Using the 'deprecated' attribute for this would be confusing 
>> because it would make it sound like flatMap itself is deprecated when it's 
>> not.
> 
> I see.  Thanks.
> 
> John.
> 
>> 
>>> Also, more practically, it conflates a relatively unimportant suggestion — 
>>> that we should call the new method in order to make our code clearer — with 
>>> a more serious one — that we should revise our code to stop using a 
>>> problematic API.  Yes, the rename has a fix-it, but still: to the extent 
>>> that these things demand limited attention from the programmer, that 
>>> attention should clearly be focused on the latter set of problems.  Perhaps 
>>> that sense of severity is something that an IDE should take into 
>>> consideration when reporting problems.
>>> 
>>> What else would you have in mind for this warning?
>> 
>> The main use for this warning would be for adding overloads to methods that 
>> take optionals in order to catch the cases where people invoke optional 
>> hoisting, so we can tell them that there's a better way to handle it if they 
>> don't have an optional. flatMap vs map is the obvious example, but I'm sure 
>> there are other cases where we can do this too.
>> 
>> But there are also other once-off uses. For example, in the past I've 
>> written a function that should only ever be used for debugging, so I marked 
>> it as deprecated with a message saying 'remove this before committing 

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

[Rod Brown via swift-evolution]

Hi Jon,

An interesting proposal. I see value in an external markdown-formatted document 
to compliment our Swift code, but currently I already do this when discussing 
ideas or architecture and just call it “.md”.

I agree with Erica on the point though that documentation with code is actually 
helpful to me and I would probably prefer documentation around methods and 
types to sit with the content itself. I also find documentation really helpful 
in breaking up a swift file, away from being code soup, and into a very 
formalised structure that I find easier to cognitively parse.

I really would like some work on Xcode though to allow hiding documentation, 
and improvements to the generated interfaces which are somewhat lacking atm.

- Rod

> On 9 Nov 2017, at 5:57 am, Erica Sadun via swift-evolution 
>  wrote:
> 
> Colocation of docs with the material they document is valuable to me and I 
> presume anyone updating code. If anything, it would be nice if Xcode provided 
> a show/hide doc headers toggle though.
> 
> -- E
> 
> 
>> On Nov 8, 2017, at 11:20 AM, Jon Gilbert via swift-evolution 
>>  wrote:
>> 
>> When I go to look at the actual source code of something, it’s almost always 
>> because:
>> (a) the documentation was insufficient for me to really understand what’s 
>> going on, or
>> (b) I already know what’s happening but I just want set a breakpoint for 
>> debugging.
>> 
>> In both of these cases, the presence of huge amounts of inline documentation 
>> in the source files just makes the code very difficult to read. 
>> 
>> In ObjectiveC we could mostly get around this by putting docs in the 
>> headers. But Swift doesn’t have headers.
>> 
>> So I find myself wishing I could keep documentation in a separate file, 
>> perhaps a file that even takes advantage of XCode 9’s new built-in Markdown 
>> formatting. 
>> 
>> Is this a pipe dream or could it someday happen? 
>> 
>> I could even imagine a future in which the leading Swift IDEs can show you a 
>> split screen view in which the documentation for a function automatically 
>> appears in an *editable* side bar, and when you edit it there, the .swiftDoc 
>> file gets updated as well, but your code itself remains pure.
>> 
>> That way, you can keep comments to a minimum in your source files.
>> 
>> Thoughts?
>> 
>> (If this has been pitched before, slap me please, but I didn’t see it.)
>> 
>> - Jon
>> ___
>> 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] Adding Result to the Standard Library

[Rod Brown via swift-evolution]

I was thinking the same thing. Typed throws vs `Error` throws are the two major 
differences between different Result implementations, and they seem somewhat 
tied from a discussion perspective.

I agree with others here, I would like to see this added to the library, and I 
think it’s a generally valuable type that has broad uses beyond the completion 
handler solution that it’s commonly been used for. But if we add things to do 
the standard library, they need to be consistent, with the direction of Swift, 
and that’s a big call at this stage to either write in or out typed throws...

Rod

> On 3 Nov 2017, at 2:41 pm, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evolution 
>>  wrote:
>> 
>> Swift-Evolution:
>>  I’ve written a first draft of a proposal to add Result to the 
>> standard library by directly porting the Result type used in Alamofire to 
>> the standard library. I’d be happy to implement it (type and tests for 
>> free!) if someone could point me to the right place to do so. I’m not 
>> including it directly in this email, since it includes the full 
>> implementation and is therefore quite long. (Discourse, please!) 
>> 
>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
> 
> I’m generally supportive of this, but the design of such a thing forces 
> another contentious issue: whether the error handling model should be 
> extended to support "typed throws”.  Without result, we can carry on pushing 
> the "typed throws” debate down the road.  Adding it would force that issue to 
> be decided, which is complicated.
> 
> -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

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 18 Sep 2017, at 9:46 am, Christopher Kornher  wrote:
> 
> 
>> On Sep 17, 2017, at 5:04 PM, BJ Homer > > wrote:
>> 
>> Please note that, as proposed, enums are always treated as exhaustive 
>> *within the same module*. A new user writing MyFirstEnum is likely using it 
>> within the same module, and will thus get exhaustive behavior with no extra 
>> keywords required.
> 
> • What is your evaluation of the proposal?
>   Uh, +1
> 
>  • How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
>   not enough
> 
> Apologies for wasting everyone’s time…

Haha no problems. Yes, it seems clear people are jumping to conclusions. This 
is a case specifically for framework developers purely for interface 
consistency, with is *exactly* when you want the default behaviour to protect 
you from external dependency changes.

Within the context of a single application at compile time, you will always 
know all cases already and therefore exhaustive can become the default. Cross 
frameworks, not so much.


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

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 17 Sep 2017, at 4:35 am, Christopher Kornher  wrote:
> 
>> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution 
>> > wrote:
>> 
>> If a library writer can’t remember to declare non-exhaustive enums as such, 
>> they probably will forget many more important aspects of creating a library. 
>> They probably should not be writing libraries. Arguments like this make 
>> sense on the surface, but creating libraries involves hundreds or thousands 
>> of decisions. I wish you luck in making that process idiot proof. A library 
>> linter could easily warn that exposed enums are exhaustive. The exhaustive 
>> keyword should be optional to make the decision obvious and suppress 
>> warnings. Complicating the user experience in a vain attempt to make 
>> “expert" coding safer is misguided.

I think the same logic goes both ways: If a library author can’t remember to 
declare exhaustive enums as such, they will probably forget many more important 
aspects of creating a library.

The problem here is fundamental: Exhaustive is a guarantee. A guarantee should 
require action. Non-Exhaustive guarantees nothing. It makes you safer. That is 
all.

> 
> This may be a little harsh, but there don’t seem to be many advocates for 
> novice and “ordinary” application developers on this list. That is not 
> unexpected given the number of extremely knowledgeable compiler and library 
> developers on this list (for whom I have the highest respect). I believe that 
> there are more creative (and probably more difficult to build) possible 
> solutions to some of the tough problems in Swift’s future. In that spirit, 
> see below.

I personally am an “ordinary” application developer.

I think the issue here is that everyone is seeing Swift as *they* intend to use 
it. For App Devs, exhaustive switches are nice, which means they really are 
fighting tooth and nail to keep them. I understand that. But I’m also trying to 
keep my mind open for “what happens to an app I compiled in iOS 15 that I 
compiled for iOS 11?” And this gives me pause. I can’t ask Apple or any other 
library author to be completely knowledgable about every case in the future, 
and to audit every line of code and manually give non-exhaustive.

Why do people want “exhaustive” to be the default? Because we like things as 
they are. Because we like not having to consider edge cases. Because we want to 
imagine that will give framework developers the control to make our lives 
difficult because they’ll just be lazy and make our lives hard by not 
annotating. And this certainly is a concern. But I think a larger concern is 
breaking apps left, right and centre, or not being able to extend frameworks 
because an earlier developer on a project made an oversight.

Its in everyone’s best interest to think before we put handcuffs on, no matter 
how painful that is. Even if that means you make apps where you just write 
“default: fatalError(“I don’t handle unreachable defaults”)"

And lets be clear: Swift isn’t an app development language. It also isn’t a 
framework development language. It’s a multipurpose language designed to Take 
Over The World™. This means we need to think holistically about what is better 
for everyone. Not just ourselves.

> 
>> 
>> 
>>> 
>>> If you declare it is exhaustive and it was an oversight, and then realise 
>>> after the fact that you are wrong, you have to open it up. This will break 
>>> third party apps. It will be disallowed by the ABI compatibility 
>>> requirements.
>>> 
>>> If you declare it isn’t exhaustive due to an oversight (or perhaps you’re 
>>> just not sure yet), and then realise after the fact it is exhaustive, you 
>>> can close it up. This will not break third party apps. It will also be 
>>> allowed for ABI compatibility.
>>> 
>>> This benefits everyone. Make library owners choose a guarantee, rather than 
>>> be defaulted into it. Much like they have to declare choose to declare 
>>> “final” on a class: you can’t retroactively reneg that promise: it will 
>>> break everyone who assumed it to be the case!
>> 
>> It does not benefit the creation of 90+% of enums. It is one more arcane 
>> rule for the vast majority of developers.
> 
> The Swift compiler could offer a “strict enum exhaustiveness” (bikeshedding 
> not included) switch that could be enabled by default for library targets and 
> disabled by default for “application” targets. The switch would make not 
> explicitly specifying exhaustiveness an error or warning when enabled. 
> Perhaps this could be combined with other options that would tailor the 
> development experience for library/application developers. This would help 
> avoid “zero-sum” choices between benefitting library or application 
> developers in the future.

The Swift team have fundamentally opposed such pushes for “compiler modes” for 
a long time. I don’t expect they will embrace them now, nor do I 

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> I am still unsure why we are choosing again a default that protects library 
> writers more than library users where it is reasonable to expect the former 
> to have better mastery of the language, to architect a library with some 
> scalability, and ability to add unit test to cover themselves from issues 
> than the latter.

Because protecting library owners protects library users.

If you declare it is exhaustive and it was an oversight, and then realise after 
the fact that you are wrong, you have to open it up. This will break third 
party apps. It will be disallowed by the ABI compatibility requirements.

If you declare it isn’t exhaustive due to an oversight (or perhaps you’re just 
not sure yet), and then realise after the fact it is exhaustive, you can close 
it up. This will not break third party apps. It will also be allowed for ABI 
compatibility.

This benefits everyone. Make library owners choose a guarantee, rather than be 
defaulted into it. Much like they have to declare choose to declare “final” on 
a class: you can’t retroactively reneg that promise: it will break everyone who 
assumed it to be the case!

> 
> Exhaustive and open by default with keywords to close things down if the 
> framework author wants them.
> 
> Sent from my iPhone
> 
>> On 16 Sep 2017, at 09:55, David Hart via swift-evolution 
>>  wrote:
>> 
>> I’m still very much bothered by having 2 new keywords. I would really prefer 
>> the following plan:
>> 
>> Exhaustive by default in Swift 4
>> No new keyword in Swift 4 to change that behaviour
>> Non-exhaustive by default outside the module in Swift 5
>> exhaustive keyword to change the default behaviour
>> 
>> Like that, we don’t need nonexhaustive.
>> 
>> Thoughts?
>> David.
>> 
>>> On 13 Sep 2017, at 21:16, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> Proposal updated, same URL: 
>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md.
>>> 
>>> Thanks again for all the feedback so far, everyone!
>>> Jordan
>>> 
>>> 
 On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution 
  wrote:
 
 Sorry, I got distracted by other tasks! Both the discussion here and 
 within Apple has moved towards making "non-exhaustive" the default, which, 
 to be honest, I too think is the best design. I'll update the proposal 
 today to reflect that, though I still want to keep both the 
 "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for 
 now (or whatever we end up naming them). The compatibility design is a 
 little less ambitious than Brent's; as currently proposed, Swift 4 mode 
 continues to default to 'exhaustive' all the time, even in the actual 
 Swift 5 release.
 
 I still want to respond to Brent's points directly, but I think you and 
 Vladimir have done a good job discussing them already. I'll send out the 
 updated proposal tomorrow, after I have a little more time to think about 
 #invalid.
 
 Thanks for putting time into this!
 Jordan
 
 
> On Sep 9, 2017, at 17:34, Rod Brown  wrote:
> 
> Jordan,
> 
> Do you have any other thoughts about the ongoing discussion here, 
> especially regarding Chris’ comments? As you’re the one pushing this 
> forward, I’d really like to know what your thoughts are regarding this?
> 
> - Rod
 
 ___
 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

Hi Jordan,

I think this is a great update to the proposal. The scope is small, which is 
good, and it clearly speaks about it’s reasoning about some of the concerns 
some people have.

A big thumbs up from me! 

- Rod

> On 14 Sep 2017, at 5:16 am, Jordan Rose via swift-evolution 
>  wrote:
> 
> Proposal updated, same URL: 
> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md.
> 
> Thanks again for all the feedback so far, everyone!
> Jordan
> 
> 
>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> Sorry, I got distracted by other tasks! Both the discussion here and within 
>> Apple has moved towards making "non-exhaustive" the default, which, to be 
>> honest, I too think is the best design. I'll update the proposal today to 
>> reflect that, though I still want to keep both the "nonexhaustive" and 
>> "exhaustive" keywords for Swift 4 compatibility for now (or whatever we end 
>> up naming them). The compatibility design is a little less ambitious than 
>> Brent's; as currently proposed, Swift 4 mode continues to default to 
>> 'exhaustive' all the time, even in the actual Swift 5 release.
>> 
>> I still want to respond to Brent's points directly, but I think you and 
>> Vladimir have done a good job discussing them already. I'll send out the 
>> updated proposal tomorrow, after I have a little more time to think about 
>> #invalid.
>> 
>> Thanks for putting time into this!
>> Jordan
>> 
>> 
>>> On Sep 9, 2017, at 17:34, Rod Brown  wrote:
>>> 
>>> Jordan,
>>> 
>>> Do you have any other thoughts about the ongoing discussion here, 
>>> especially regarding Chris’ comments? As you’re the one pushing this 
>>> forward, I’d really like to know what your thoughts are regarding this?
>>> 
>>> - Rod
>> 
>> ___
>> 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] Enums and Source Compatibility

[Rod Brown via swift-evolution]

Jordan,

Do you have any other thoughts about the ongoing discussion here, especially 
regarding Chris’ comments? As you’re the one pushing this forward, I’d really 
like to know what your thoughts are regarding this?

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

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 8 Sep 2017, at 2:55 am, Vladimir.S  wrote:
> 
> On 07.09.2017 18:23, Rod Brown wrote:
>> 
>> This was discussed earlier. As I mentioned, we should be realistic: it’s 
>> rarely a
>> truly fatal error when you get an unknown enum. Unless you really can’t find 
>> a
>> reasonable default, then there are almost always reasonable logical ways to 
>> handle
>> it (perhaps just breaking out?). And in cases where you really need to 
>> handle each
>> case, this would (almost?) always be an exhaustive enum. I can’t even 
>> imagine the
>> case where it would be so critical you couldn’t handle it with reasonable 
>> control
>> flow. There are always solutions like returning early, breaking out, default
>> details. I see Swift code littered with fatalError() not because its needed, 
>> but
>> because the developer often didn’t care enough to think it through.
> 
> Thank you for replies, Rod!
> 
> Thinking about this, if "in cases where you really need to handle each case, 
> this would (almost?) always be an exhaustive enum", then I tend to agree with 
> you.
> 
> So, currently my point of view is that we need to move the way suggested by 
> Chris, when we need to mark public 'closed' enum, so 'open' is default, and 
> with warning for first time and with error in next version of Swift for 
> switches on 'open' enum without 'default' case. Not the way described in the 
> proposal itself.

Agreed, though we shouldn't use “open/closed” as discussed in the proposal 
draft.

> 
>> “Future” might be a decent idea, but I think we’re overcomplicating it. Just 
>> use
>> “default” as we always have? “Future” as a word doesn’t seem to apply, as I 
>> have
>> mentioned earlier: there are cases where your framework has a private case 
>> on an
>> enum. This isn’t necessarily a future case - it could be “current”. If we 
>> were to
>> do this, it would make more sense to call this case word “other” instead. 
>> Again,
>> though, we’re adding complexity to a switch for a very rare case and a 
>> little bit
>> of developer convenience in that case.
> 
> Well... yes, seems like this. I didn't get current but private cases into 
> account. But I was more focused on Swift's enums, not on C's.
> 
> What do you(and others) think about such idea: if we have an exhaustive 
> switch on _open_ enum _without_ 'default' case, and there are *no* more known 
> available cases for this enum currently - compiler generates error/warning 
> like "you have exhaustive switch but this is an open enum new cases can be 
> added later, so add 'default' case to process them". But, if such(exhaustive 
> on _open_ enum _without_ 'default' case) switch contains not all known cases, 
> warning/error will be different like "you have not exhaustive switch on open 
> enum, add 'default' case to process all others and future cases”.

I agree. This is going to be a confusing case, especially when transitioning. 
Stating clearly why they need a default clause despite the “appearance” of 
exhaustively handling all cases should be part of the error wording.

> 
> I believe that with this accepted proposal, if you ever will need to keep 
> switch exhaustive on 'open' enum, support this code, this will be a nightmare 
> without at least such warnings, when you can comment the 'default' case in 
> switch and check(by warning/error message) if you processed all the cases or 
> missed some. Otherwise, the alternative, is to manually check one-by-one what 
> you have in your switch and what cases are in enum(in case you have new 
> version of enum's module).
> 
> Vladimir.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 8 Sep 2017, at 12:24 am, Vladimir.S  wrote:
> 
> 
> 
> On 07.09.2017 16:03, Rod Brown wrote:
>>> On 7 Sep 2017, at 9:26 pm, Vladimir.S via swift-evolution 
>>> > wrote:
>>> Just small note. As I understand, this is a source breaking suggestion, no?
>>> I mean any client code for 'public enum' coming from another module, will 
>>> have to add 'default' case in 'switch'. So, the previously correct code 
>>> will not compile. Or do you suggest to raise a warning only for the first 
>>> time and raise an error in next version of Swift?
>> Yes. By defaulting to “non fragile” we add a source incompatibility, because 
>> Swift is currently assuming fragility. In Jordan’s proposal, it is assuming 
>> fragility/exhaustive by default, and therefore would be source compatible. 
>> Good point.
>> I keep wavering back and forth on the importance of Source Compatibility 
>> with this one. Defaulting to “exhaustive” seems dangerous to me. It makes 
>> your framework (and future versions of it) fragile without ever having to 
>> think about it. At least if the keyword of “exhaustive” or “fragile” or 
>> “sealed” meant that you actively chose the fragility that will handcuff you 
>> later down the road.
> 
> Yes, probably(still thinking about this) I agree that 'open'('exhaustive') 
> enum should be the default for public enum; and only if author is really sure 
> enum will not change in future and to provide a space for compiler's 
> optimizations and suggest client to switch exhaustive, he/she can mark such 
> enum as exhaustive/fragile/sealed/closed/fixed. And seems like the right 
> direction is raise warnings fist, and errors in next version of Swift.
> 
> The only question I can't find strong answer for, what my code(as a client of 
> 'open' enum) will do in 'default' case? Will it be in 95% cases the 
> fatalError().. If so, what is the difference with current situation?
> If my switch is already exhaustive regarding some public(imported) enum, so 
> I'm processing all the possible *at the compilation time* cases - most likely 
> I'll have just fatalError() in 'default'.
> If my switch already contains 'default' - the proposed change will not affect 
> me at all…

This was discussed earlier. As I mentioned, we should be realistic: it’s rarely 
a truly fatal error when you get an unknown enum. Unless you really can’t find 
a reasonable default, then there are almost always reasonable logical ways to 
handle it (perhaps just breaking out?). And in cases where you really need to 
handle each case, this would (almost?) always be an exhaustive enum. I can’t 
even imagine the case where it would be so critical you couldn’t handle it with 
reasonable control flow. There are always solutions like returning early, 
breaking out, default details. I see Swift code littered with fatalError() not 
because its needed, but because the developer often didn’t care enough to think 
it through.

> 
> But probably it is better to have a choice what to do with future cases, than 
> have just one direction - crash at run time if new case in external enum is 
> added.
> 
> But the same I can say for proposed 'future' case : it is better to have a 
> choice what to use - 'default', if we don't need to be exhaustive on 'open' 
> enum,  or 'future', if we need to be exhaustive on 'open' enum in 
> compile-time but separately process all future cases.

“Future” might be a decent idea, but I think we’re overcomplicating it. Just 
use “default” as we always have? “Future” as a word doesn’t seem to apply, as I 
have mentioned earlier: there are cases where your framework has a private case 
on an enum. This isn’t necessarily a future case - it could be “current”. If we 
were to do this, it would make more sense to call this case word “other” 
instead. Again, though, we’re adding complexity to a switch for a very rare 
case and a little bit of developer convenience in that case.

> 
> Yes, in this case we have a problem with testability, but the same is true 
> for exhaustive switch with 'defailt' case - how this 'default' code can be 
> tested? Probably, we need to provide a solution for this in any case, not 
> because of 'future' but also for 'default' in exhaustive switch on 'open' 
> enum. (Don't know how this could be implemented, probably by somehow be able 
> to extend the imported open enum with 'fake' case when compile in special 
> mode for testing and be able to send this fake case into tested code)

Yes, testing this is a concern. I agree: have an ability to add an “other" case 
in tests.

> 
> Vladimir.
> 
>>> 
 3. fragile public enum: cases may not be added, because that would break 
 the fragility guarantee.  As such, clients within or outside of hte 
 current module may exhaustively match against the enum.
>>> 
>>> I think 'fragile' word does not reflect what is guaranteed for this enum. 
>>> The author guaranteed that this enum 

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 7 Sep 2017, at 9:26 pm, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 07.09.2017 7:33, Chris Lattner via swift-evolution wrote:
>>> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> I've taken everyone's feedback into consideration and written this up as a 
>>> proposal: 
>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md.
>>>  The next step is working on an implementation, but if people have further 
>>> pre-review comments I'd be happy to hear them.
>> Hi Jordan,
>> I apologize in advance that I haven’t followed the back and forth on this 
>> thread, so I’m sorry if these thoughts are duplicative:
>> I really would prefer to avoid introducing the notion of 
>> exhaustive/nonexhaustive enums into Swift, and would much prefer that such a 
>> thing be limited to C (which can’t express this concept already).
>> We’ve talked about enums many times across years, and it seems like the 
>> appropriate model follows the generally understood resilience model. 
>> Specifically, there should be three different kinds of enums, and the kind 
>> should affect users outside their module in different ways:
>> 1. private/fileprivate/internal enum: cases can be added freely.  All 
>> clients are in the same module, so the enum is implicitly fragile, and all 
>> switches within the current module may therefore be exhaustive.
>> 2. public enum (i.e., one that isn’t marked fragile): cases may be added 
>> freely.   Within the module that defines the enum, switches may be 
>> exhaustive.  However, because the enum is public and non-fragile, clients 
>> outside the current module must be prepared for the enum to add additional 
>> cases in future revisions of the API, and therefore they cannot exhaustively 
>> match the cases of the enum.
> 
> Just small note. As I understand, this is a source breaking suggestion, no?
> I mean any client code for 'public enum' coming from another module, will 
> have to add 'default' case in 'switch'. So, the previously correct code will 
> not compile. Or do you suggest to raise a warning only for the first time and 
> raise an error in next version of Swift?

Yes. By defaulting to “non fragile” we add a source incompatibility, because 
Swift is currently assuming fragility. In Jordan’s proposal, it is assuming 
fragility/exhaustive by default, and therefore would be source compatible. Good 
point.

I keep wavering back and forth on the importance of Source Compatibility with 
this one. Defaulting to “exhaustive” seems dangerous to me. It makes your 
framework (and future versions of it) fragile without ever having to think 
about it. At least if the keyword of “exhaustive” or “fragile” or “sealed” 
meant that you actively chose the fragility that will handcuff you later down 
the road.

> 
>> 3. fragile public enum: cases may not be added, because that would break the 
>> fragility guarantee.  As such, clients within or outside of hte current 
>> module may exhaustively match against the enum.
> 
> I think 'fragile' word does not reflect what is guaranteed for this enum. The 
> author guaranteed that this enum will not be changed, not "this enum can 
> broke your code". Can't we use 'sealed'/'closed'/'fixed' here?
> 
> Vladimir.
> 
>> This approach gives a very natural user model: app developers don’t have to 
>> care about enum resilience until they mark an enum as public, and even then 
>> they only have to care about it when/if they mark an enum as public.  This 
>> also builds on the notion of fragility - something we need for other nominal 
>> types like structs and classes - so it doesn’t introduce new language 
>> complexity.  Also such an approach is entirely source compatible with Swift 
>> 3/4, which require defaults (this isn’t an accident, it follows from the 
>> anticipated design).
>> This approach doesn’t address the problem of what to do with C though, 
>> because C doesn’t have a reasonable notion of “extensible” vs 
>> “nonextensible” enum.  As such, we definitely do need an attribute (or 
>> something) to add to Clang.  I think that your proposal for defaulting to 
>> “extensible” and using __attribute__((enum_extensibility(closed))) override 
>> this is perfectly sensible.
>> -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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 7 Sep 2017, at 2:33 pm, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> I've taken everyone's feedback into consideration and written this up as a 
>> proposal: 
>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
>>  
>> .
>>  The next step is working on an implementation, but if people have further 
>> pre-review comments I'd be happy to hear them.
> 
> Hi Jordan,
> 
> I apologize in advance that I haven’t followed the back and forth on this 
> thread, so I’m sorry if these thoughts are duplicative:
> 
> I really would prefer to avoid introducing the notion of 
> exhaustive/nonexhaustive enums into Swift, and would much prefer that such a 
> thing be limited to C (which can’t express this concept already).
> 
> We’ve talked about enums many times across years, and it seems like the 
> appropriate model follows the generally understood resilience model.  
> Specifically, there should be three different kinds of enums, and the kind 
> should affect users outside their module in different ways:
> 
> 1. private/fileprivate/internal enum: cases can be added freely.  All clients 
> are in the same module, so the enum is implicitly fragile, and all switches 
> within the current module may therefore be exhaustive.
> 
> 2. public enum (i.e., one that isn’t marked fragile): cases may be added 
> freely.  Within the module that defines the enum, switches may be exhaustive. 
>  However, because the enum is public and non-fragile, clients outside the 
> current module must be prepared for the enum to add additional cases in 
> future revisions of the API, and therefore they cannot exhaustively match the 
> cases of the enum.
> 
> 3. fragile public enum: cases may not be added, because that would break the 
> fragility guarantee.  As such, clients within or outside of hte current 
> module may exhaustively match against the enum.
> 
> 
> This approach gives a very natural user model: app developers don’t have to 
> care about enum resilience until they mark an enum as public, and even then 
> they only have to care about it when/if they mark an enum as public.  This 
> also builds on the notion of fragility - something we need for other nominal 
> types like structs and classes - so it doesn’t introduce new language 
> complexity.  Also such an approach is entirely source compatible with Swift 
> 3/4, which require defaults (this isn’t an accident, it follows from the 
> anticipated design).
> 
> This approach doesn’t address the problem of what to do with C though, 
> because C doesn’t have a reasonable notion of “extensible” vs “nonextensible” 
> enum.  As such, we definitely do need an attribute (or something) to add to 
> Clang.  I think that your proposal for defaulting to “extensible” and using 
> __attribute__((enum_extensibility(closed))) override this is perfectly 
> sensible.
> 
> -Chris
> 

Hi Chris,

I think I agree with you in general, with 1 exception:

I think the wording “fragile”, while technically correct, implies the exact 
opposite of the promise contract, namely that it will not change between 
releases of your framework. Perhaps a term like “concrete” would be more 
appropriate? It would be fragile in that it is a fragile interface, but it 
would be concrete as a promise to external dependencies. If you are 
exhaustively enumerating, you’re basing it on the notion that it won’t change, 
not that it’s "easy to break” (which fragile as a word would seem to imply).

- Rod


> 
> 
> ___
> 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] Enums and Source Compatibility

[Rod Brown via swift-evolution]

Hi Brent,

Thanks for the analysis of the issues here. I think you’re right that there are 
two major types of enums, and that there are a set developers tend to switch on 
that are usually fixed, where additional cases won’t make sense.

I think there are several issues that I see with these different ideas, and 
they stem back to a similar source:

1. They are overly complex solutions to a specific problem: inter-library 
variable enums. We would be destroying some of the awesome simplicity and 
design characteristics of enums in Swift to deal with an outlying problem.

2. Project enums should always be exhaustive. Your design introduces 
‘exhaustive’ and has an end goal of removing ‘@nonexhaustive’ but the fact is 
that keyword should be the default internal of a project. It seems an odd 
trajectory change to make purely for public enums.

It would seem much simpler to have a word that denotes that an enum is not 
considered ‘exhaustive’ in public code, or to force users to annotate their 
intention of exhaustive vs extensible when they make their enum public, and 
have intra-project enums remain exhaustive. This then requires a simple 
addition of a default argument to handle outlier cases you may encounter. Your 
solutions seem to me to require a large to deal with a relatively narrow use 
case, radically changing the enum system.

I agree that we could include something as part of @testable to add an 
additional case to test the edge case. We do have specific language elements 
for testing, why not here?

- Rod


> On 6 Sep 2017, at 10:53 pm, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> I've taken everyone's feedback into consideration and written this up as a 
>> proposal: 
>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
>>  
>> .
>>  The next step is working on an implementation, but if people have further 
>> pre-review comments I'd be happy to hear them.
> 
> I disagree with the choice of `exhaustive` and `nonexhaustive`. They are too 
> long; the more resilient keyword is longer than the more fragile one (and 
> difficult to read!); and they don't match the clang annotation. We may have 
> to compromise on one or two of these, but the combination of all three ought 
> to be considered disqualifying.
> 
> I think `final`/`nonfinal`, `total`/`partial`, `fixed`/? or `permanent`/? are 
> all better because they're shorter, although they all have problems with 
> their antonyms. `candid`/`coy` or `candid`/`shy` produce the right soft 
> default, but are kind of weirdly figurative.
> 
> But I don't think a change of keywords will fix everything here. 
> Fundamentally, I am not convinced that source compatibility of `switch` 
> statements should be weighed so heavily. Based on your survey of Foundation, 
> you suggest that the vast majority of imported enums should source-break all 
> switches in Swift 5. Why is that acceptable, but making Swift enums 
> source-breaking unacceptable?
> 
> I suspect that, in practice, `public` enums tend to fall into two categories:
> 
>   1. "Data enums" which represent important data that happens to consist 
> of a set of alternatives. Outside users will frequently need to switch over 
> these, but they are not very likely to evolve or have private cases.
> 
>   2. "Mode enums" which tweak the behavior of an API. These are very 
> likely to evolve or have private cases, but outside users are not very likely 
> to need to switch over them.
> 
> An example of a data enum would be, as you mentioned, `NSComparisonResult`. 
> People really *do* need to be able to test against it, but barring some 
> fundamental break in the nature of reality, it will only ever have those 
> three cases. So it's fine to make it exhaustive.
> 
> An example of a mode enum would be `UIViewAnimationCurve`, which tells UIKit 
> how to ease an animation. I chose that example because I actually traced a 
> bug just last week to my mistaken impression that this enum had no private 
> cases. I was mapping values of this type to their corresponding 
> `UIViewAnimationOptions` values; because there were private cases, this was 
> Objective-C code, and I didn't include sufficiently aggressive assertions, I 
> ended up reading garbage data from memory. But while debugging this, it 
> struck me that this was actually *really weird* code. How often do you, as a 
> developer outside UIKit, need to interpret the value of a type like 
> `UIViewAnimationCurve`? If the compiler suddenly changed the exhaustiveness 
> behavior of `UIViewAnimationCurve`, probably less than 1% of apps would even 
> notice—and the affected code would probably have latent 

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

>> I see the logic of this position, but it traps at cases which are unforeseen 
>> unrelated to OS releases. As this proposal notes, there are cases that Apple 
>> uses internal of their frameworks that they consider private may still be 
>> passed through your API.
>> 
>> For example, if there was a new button type, and you enumerated all public 
>> types in your method, but UIKit had a private custom button type, you 
>> couldn’t catch on it, nor would you have any idea that it existed. This 
>> isn’t related to the release cycle timing, but you’re still going to start 
>> crashing despite the fact that you believe you’ve exhaustively handled all 
>> cases.
> 
> Fully understood, though when you are in the middle of some calculation, you 
> are unlikely to do anything by fatalError in the "future" case...
> 
> Imagine e.g. your DateFormatter and you get a new Style in the formatting - 
> what do you do? Fallback on a different one? I personally would simply call 
> fatalError in the future case anyway…

I would tend to agree, which is part of why I think “future” doesn’t make sense 
and should stay in the Alternatives Considered but dropped.

I think the point of extensible/nonexhaustive enums is precisely so we think 
about what are appropriate defaults, otherwise we would just add a “fatalError” 
into the compilation of Switches when no case is caught, and that would be the 
end of this proposal.

In your example, is there a fair default fallback for this behaviour? Just 
choose a reasonable default date style and run with it as an appropriate 
fallback. 95% of the time, there are more reasonable solutions than crashing 
just because your text on screen line breaks weirdly.

Only in occasions where either a) the default case makes no sense, or b) I 
really cannot use a fair default in this calculation, would I fatalError in 
this case. This would seem to me to be far more reasonable than “I can’t hard 
code it, stop the presses, crash everything, blow up the world” for most cases. 
Additionally, it would seem wise for a framework developer to annotate why they 
marked their enum as “nonexhaustive” to give some hint as to a reasonable 
handling of these cases, where it’s not clearly evident.

> 
>> 
>> Also, we need to be thinking bigger than just the Apple Ecosystem. While 
>> Swift started on the Mac and iOS, this is hardly guaranteed, nor are release 
>> timings. Also, just because the dynamic frameworks update at regular 
>> intervals now, doesn’t mean the same will happen on Linux, where a 
>> dynamically linked framework could just update without anyone knowing. Part 
>> of the consideration of ABI stability isn’t just for Apple to ship 
>> frameworks, but for anyone to ship frameworks that are not contained within 
>> the signed bundle of the application. It is short sighted to say “well, this 
>> works for us right now” in my opinion. Part of this discussion is to mature 
>> Swift away from these kinds of assumptions (Apple, Obj-C, etc).

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

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 6 Sep 2017, at 4:35 pm, David Hart  wrote:
> 
> Hi Jordan,
> 
> I like this new direction. But I have Rod’s inverse question: have you 
> considered only having the nonexhaustive keyword? Similar to how non-final 
> doesn't exist because its opposite is the default behaviour. That would also 
> free us from searching for a good pair of keywords and only find one good 
> keyword (extensible, expandable, …) which doesn’t contain a negative.

I was thinking the same. If exhaustive is the default, and how Swift has always 
worked, then why have that keyword anyway? I like extensible/expandable but I 
worry the connotation some might come away with that you could add cases 
externally, which is not in scope.

> 
> David.
> 
>> On 6 Sep 2017, at 02:36, Jordan Rose > > wrote:
>> 
>> It's in the "Alternatives Considered" section. :-) That was my desired 
>> design when we started, but feedback convinced me that the break from Swift 
>> 4 mode would be too drastic. The same valid code would have a different 
>> meaning whether you were writing Swift 4 or Swift 5.
>> 
>> Jordan
>> 
>> 
>>> On Sep 5, 2017, at 17:30, Rod Brown >> > wrote:
>>> 
>>> Hi Jordan,
>>> 
>>> I’m not sure how much bearing on this my comment will have.
>>> 
>>> Have you considered having only “exhaustive” as a keyword, and make the 
>>> default non-exhaustive? It seems that “exhaustive" would be the rarer case, 
>>> as it promises a lot more about compatibility (much like there is no such 
>>> thing as “non-final”). Also, non exhaustive seems a massive mouthful 
>>> despite it probably being the correct term.
>>> 
>>> - Rod
>>> 
 On 6 Sep 2017, at 10:19 am, Jordan Rose > wrote:
 
 I've taken everyone's feedback into consideration and written this up as a 
 proposal: 
 https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
  
 .
  The next step is working on an implementation, but if people have further 
 pre-review comments I'd be happy to hear them.
 
 Jordan
>> 
> 

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

Re: [swift-evolution] Enums and Source Compatibility

[Rod Brown via swift-evolution]

> On 6 Sep 2017, at 2:31 pm, Charlie Monroe <char...@charliemonroe.net> wrote:
>> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> I think what you’re really asking for here is the “future” case mentioned in 
>> the Alternatives Considered section. I think that Jordan makes a good point 
>> that this would result in untestable code, which is bad practice. While the 
>> lack of clear highlighting of non-exhaustive cases is undesirable, I think 
>> untestable code is a much larger problem here.
> 
> This is generally the switch! that I've suggested listed in alternatives as 
> well - that generally brings current behavior. For a project that is 
> regularly maintained, I believe that this makes sense given that the enums 
> are only likely to change once a year at most (with new OS releases)…

I see the logic of this position, but it traps at cases which are unforeseen 
unrelated to OS releases. As this proposal notes, there are cases that Apple 
uses internal of their frameworks that they consider private may still be 
passed through your API.

For example, if there was a new button type, and you enumerated all public 
types in your method, but UIKit had a private custom button type, you couldn’t 
catch on it, nor would you have any idea that it existed. This isn’t related to 
the release cycle timing, but you’re still going to start crashing despite the 
fact that you believe you’ve exhaustively handled all cases.

Also, we need to be thinking bigger than just the Apple Ecosystem. While Swift 
started on the Mac and iOS, this is hardly guaranteed, nor are release timings. 
Also, just because the dynamic frameworks update at regular intervals now, 
doesn’t mean the same will happen on Linux, where a dynamically linked 
framework could just update without anyone knowing. Part of the consideration 
of ABI stability isn’t just for Apple to ship frameworks, but for anyone to 
ship frameworks that are not contained within the signed bundle of the 
application. It is short sighted to say “well, this works for us right now” in 
my opinion. Part of this discussion is to mature Swift away from these kinds of 
assumptions (Apple, Obj-C, etc).

> 
>> 
>> Either way we need a way to handle forward compatibility for our code when 
>> cases get added to external frameworks, that much is clear. Swift is broken 
>> in regards to this, and we need to handle it somehow. I’m hoping you’re not 
>> suggesting that we just don’t make this change at all. We need this for 
>> forward compatibility for framework development with Swift.
>> _
>> 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] Enums and Source Compatibility

[Rod Brown via swift-evolution]

Hi Jordan,

Upon further reflection, I’m going to withdraw my concerns about the defaulting 
and I think it’s the right solution after all. This is due to several thoughts 
I had rolling it around my head:

1. In a private project, you would expect all cases to be exhaustive, as this 
is guaranteed by the compiler (no compatibility concerns). Exhaustive makes 
sense here, as it has always done in Swift code, and is why it was the 
behaviour since Swift 1.
2. When we make projects public, we already need to vet them for compatibility 
concerns with final etc. This should be part of the process of making them 
public.
3. It's source compatible with libraries, as mentioned in the proposal.

I can imagine there will still be a tonne of work needed for apps compiling 
against Apple’s Obj-C SDKs when Swift 5 comes out due to this change. Almost 
all enums will become nonexhaustive, but this will then show up in 
documentation changes, header updates etc, and as you’ve mentioned, it will 
avoid confusion.

Sorry! I think I just needed some time to roll it around my head a bit haha

- Rod



> On 6 Sep 2017, at 10:47 am, Rod Brown via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Ah yes, my eye skipped that alternative for some reason! Sorry.
> 
> I’d be concerned that avoiding a default is a fix for a compatibility 
> problem, not a language design decision. If we look back in 5 years and say 
> “why do we need to keep writing nonexhaustive everywhere?”, we’ll have to say 
> “there were compatibility problems with Swift 4-to-5”. That reeks of a 
> language I just want to walk away from. Yuk.
> 
> In this case, either way, we’ll need to do some work. So why not let the 
> migrator migrate this code correctly to “exhaustive”, which is the current 
> behaviour? I think a decision where either way we break source compatibility 
> should be done in the interest of language design, not in the short term 
> interest of avoiding confusion.
> 
> But that’s just my 2c.
> 
> Thanks,
> 
> Rod
> 
>  
> 
>> On 6 Sep 2017, at 10:36 am, Jordan Rose <jordan_r...@apple.com 
>> <mailto:jordan_r...@apple.com>> wrote:
>> 
>> It's in the "Alternatives Considered" section. :-) That was my desired 
>> design when we started, but feedback convinced me that the break from Swift 
>> 4 mode would be too drastic. The same valid code would have a different 
>> meaning whether you were writing Swift 4 or Swift 5.
>> 
>> Jordan
>> 
>> 
>>> On Sep 5, 2017, at 17:30, Rod Brown <rodney.bro...@icloud.com 
>>> <mailto:rodney.bro...@icloud.com>> wrote:
>>> 
>>> Hi Jordan,
>>> 
>>> I’m not sure how much bearing on this my comment will have.
>>> 
>>> Have you considered having only “exhaustive” as a keyword, and make the 
>>> default non-exhaustive? It seems that “exhaustive" would be the rarer case, 
>>> as it promises a lot more about compatibility (much like there is no such 
>>> thing as “non-final”). Also, non exhaustive seems a massive mouthful 
>>> despite it probably being the correct term.
>>> 
>>> - Rod
>>> 
>>>> On 6 Sep 2017, at 10:19 am, Jordan Rose <jordan_r...@apple.com 
>>>> <mailto:jordan_r...@apple.com>> wrote:
>>>> 
>>>> I've taken everyone's feedback into consideration and written this up as a 
>>>> proposal: 
>>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
>>>>  
>>>> <https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md>.
>>>>  The next step is working on an implementation, but if people have further 
>>>> pre-review comments I'd be happy to hear them.
>>>> 
>>>> Jordan
>> 
> 
> ___
> 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] Enums and Source Compatibility

[Rod Brown via swift-evolution]

Ah yes, my eye skipped that alternative for some reason! Sorry.

I’d be concerned that avoiding a default is a fix for a compatibility problem, 
not a language design decision. If we look back in 5 years and say “why do we 
need to keep writing nonexhaustive everywhere?”, we’ll have to say “there were 
compatibility problems with Swift 4-to-5”. That reeks of a language I just want 
to walk away from. Yuk.

In this case, either way, we’ll need to do some work. So why not let the 
migrator migrate this code correctly to “exhaustive”, which is the current 
behaviour? I think a decision where either way we break source compatibility 
should be done in the interest of language design, not in the short term 
interest of avoiding confusion.

But that’s just my 2c.

Thanks,

Rod

 

> On 6 Sep 2017, at 10:36 am, Jordan Rose  wrote:
> 
> It's in the "Alternatives Considered" section. :-) That was my desired design 
> when we started, but feedback convinced me that the break from Swift 4 mode 
> would be too drastic. The same valid code would have a different meaning 
> whether you were writing Swift 4 or Swift 5.
> 
> Jordan
> 
> 
>> On Sep 5, 2017, at 17:30, Rod Brown > > wrote:
>> 
>> Hi Jordan,
>> 
>> I’m not sure how much bearing on this my comment will have.
>> 
>> Have you considered having only “exhaustive” as a keyword, and make the 
>> default non-exhaustive? It seems that “exhaustive" would be the rarer case, 
>> as it promises a lot more about compatibility (much like there is no such 
>> thing as “non-final”). Also, non exhaustive seems a massive mouthful despite 
>> it probably being the correct term.
>> 
>> - Rod
>> 
>>> On 6 Sep 2017, at 10:19 am, Jordan Rose >> > wrote:
>>> 
>>> I've taken everyone's feedback into consideration and written this up as a 
>>> proposal: 
>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
>>>  
>>> .
>>>  The next step is working on an implementation, but if people have further 
>>> pre-review comments I'd be happy to hear them.
>>> 
>>> Jordan
> 

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

[swift-evolution] Re: Enums and Source Compatibility

[Rod Brown via swift-evolution]

Hi Jordan,

I’m not sure how much bearing on this my comment will have.

Have you considered having only “exhaustive” as a keyword, and make the default 
non-exhaustive? It seems that “exhaustive" would be the rarer case, as it 
promises a lot more about compatibility (much like there is no such thing as 
“non-final”). Also, non exhaustive seems a massive mouthful despite it probably 
being the correct term.

- Rod

> On 6 Sep 2017, at 10:19 am, Jordan Rose  wrote:
> 
> I've taken everyone's feedback into consideration and written this up as a 
> proposal: 
> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
>  
> .
>  The next step is working on an implementation, but if people have further 
> pre-review comments I'd be happy to hear them.
> 
> Jordan
> 
> 
>> On Aug 8, 2017, at 15:27, Jordan Rose > > wrote:
>> 
>> Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an 
>> issue that's been around for a while: the source compatibility of enums. 
>> Today, it's an error to switch over an enum without handling all the cases, 
>> but this breaks down in a number of ways:
>> 
>> - A C enum may have "private cases" that aren't defined inside the original 
>> enum declaration, and there's no way to detect these in a switch without 
>> dropping down to the rawValue.
>> - For the same reason, the compiler-synthesized 'init(rawValue:)' on an 
>> imported enum never produces 'nil', because who knows how anyone's using C 
>> enums anyway?
>> - Adding a new case to a Swift enum in a library breaks any client code that 
>> was trying to switch over it.
>> 
>> (This list might sound familiar, and that's because it's from a message of 
>> mine on a thread started by Matthew Johnson back in February called "[Pitch] 
>> consistent public access modifiers". Most of the rest of this email is going 
>> to go the same way, because we still need to make progress here.)
>> 
>> At the same time, we really like our exhaustive switches, especially over 
>> enums we define ourselves. And there's a performance side to this whole 
>> thing too; if all cases of an enum are known, it can be passed around much 
>> more efficiently than if it might suddenly grow a new case containing a 
>> struct with 5000 Strings in it.
>> 
>> 
>> Behavior
>> 
>> I think there's certain behavior that is probably not terribly controversial:
>> 
>> - When enums are imported from Apple frameworks, they should always require 
>> a default case, except for a few exceptions like NSRectEdge. (It's Apple's 
>> job to handle this and get it right, but if we get it wrong with an imported 
>> enum there's still the workaround of dropping down to the raw value.)
>> - When I define Swift enums in the current framework, there's obviously no 
>> compatibility issues; we should allow exhaustive switches.
>> 
>> Everything else falls somewhere in the middle, both for enums defined in 
>> Objective-C:
>> 
>> - If I define an Objective-C enum in the current framework, should it allow 
>> exhaustive switching, because there are no compatibility issues, or not, 
>> because there could still be private cases defined in a .m file?
>> - If there's an Objective-C enum in another framework (that I built locally 
>> with Xcode, Carthage, CocoaPods, SwiftPM, etc.), should it allow exhaustive 
>> switching, because there are no binary compatibility issues, or not, because 
>> there may be source compatibility issues? We'd really like adding a new enum 
>> case to not be a breaking change even at the source level.
>> - If there's an Objective-C enum coming in through a bridging header, should 
>> it allow exhaustive switching, because I might have defined it myself, or 
>> not, because it might be non-modular content I've used the bridging header 
>> to import?
>> 
>> And in Swift:
>> 
>> - If there's a Swift enum in another framework I built locally, should it 
>> allow exhaustive switching, because there are no binary compatibility 
>> issues, or not, because there may be source compatibility issues? Again, 
>> we'd really like adding a new enum case to not be a breaking change even at 
>> the source level.
>> 
>> Let's now flip this to the other side of the equation. I've been talking 
>> about us disallowing exhaustive switching, i.e. "if the enum might grow new 
>> cases you must have a 'default' in a switch". In previous (in-person) 
>> discussions about this feature, it's been pointed out that the code in an 
>> otherwise-fully-covered switch is, by definition, unreachable, and therefore 
>> untestable. This also isn't a desirable situation to be in, but it's 
>> mitigated somewhat by the fact that there probably aren't many framework 
>> enums you should exhaustively switch over anyway. (Think about 

Re: [swift-evolution] [Concurrency] async/await + actors

[Rod Brown via swift-evolution]

> On 18 Aug 2017, at 9:56 am, Rod Brown via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> Hi Chris,
> 
> I love what I’ve read so far. I just have one curiosity from my cursory look 
> over the proposal.
> 
> It seems that in transitioning API to an Async Await system, the completion 
> handler’s type becomes the return type. How would you handle bridging in 
> Foundation API that already has a return type, eg URLSession returns you data 
> tasks, and then fires a completion handler. Perhaps I missed something. I’m 
> sure you could always form a tuple as well, just curious the thoughts on that.

Just as a follow up, thinking this through I’m not sure combining it with this 
completion handler argument tuple is helpful here, because you generally want 
access to the data task during execution for cancellation, progress handling 
etc.

The Async await system doesn’t seem to work well with handling setting 
something and allowing duplicate return types at different times like a lot of 
the foundation API is written, does it? I’m not sure how this is solved in C#.


> 
> Thanks,
> 
> Rod
> 
>> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Aug 17, 2017, at 3:24 PM, Chris Lattner <clatt...@nondot.org> wrote:
>>> 
>>> Hi all,
>>> 
>>> As Ted mentioned in his email, it is great to finally kick off discussions 
>>> for what concurrency should look like in Swift.  This will surely be an 
>>> epic multi-year journey, but it is more important to find the right design 
>>> than to get there fast.
>>> 
>>> I’ve been advocating for a specific model involving async/await and actors 
>>> for many years now.  Handwaving only goes so far, so some folks asked me to 
>>> write them down to make the discussion more helpful and concrete.  While I 
>>> hope these ideas help push the discussion on concurrency forward, this 
>>> isn’t in any way meant to cut off other directions: in fact I hope it helps 
>>> give proponents of other designs a model to follow: a discussion giving 
>>> extensive rationale, combined with the long term story arc to show that the 
>>> features fit together.
>>> 
>>> Anyway, here is the document, I hope it is useful, and I’d love to hear 
>>> comments and suggestions for improvement:
>>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
>> 
>> Oh, also, one relatively short term piece of this model is a proposal for 
>> adding an async/await model to Swift (in the form of general coroutine 
>> support).  Joe Groff and I wrote up a proposal for this, here:
>> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619
>> 
>> and I have a PR with the first half of the implementation here:
>> https://github.com/apple/swift/pull/11501
>> 
>> The piece that is missing is code generation support.
>> 
>> -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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

[Rod Brown via swift-evolution]

Hi Chris,

I love what I’ve read so far. I just have one curiosity from my cursory look 
over the proposal.

It seems that in transitioning API to an Async Await system, the completion 
handler’s type becomes the return type. How would you handle bridging in 
Foundation API that already has a return type, eg URLSession returns you data 
tasks, and then fires a completion handler. Perhaps I missed something. I’m 
sure you could always form a tuple as well, just curious the thoughts on that.

Thanks,

Rod

> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Aug 17, 2017, at 3:24 PM, Chris Lattner  wrote:
>> 
>> Hi all,
>> 
>> As Ted mentioned in his email, it is great to finally kick off discussions 
>> for what concurrency should look like in Swift.  This will surely be an epic 
>> multi-year journey, but it is more important to find the right design than 
>> to get there fast.
>> 
>> I’ve been advocating for a specific model involving async/await and actors 
>> for many years now.  Handwaving only goes so far, so some folks asked me to 
>> write them down to make the discussion more helpful and concrete.  While I 
>> hope these ideas help push the discussion on concurrency forward, this isn’t 
>> in any way meant to cut off other directions: in fact I hope it helps give 
>> proponents of other designs a model to follow: a discussion giving extensive 
>> rationale, combined with the long term story arc to show that the features 
>> fit together.
>> 
>> Anyway, here is the document, I hope it is useful, and I’d love to hear 
>> comments and suggestions for improvement:
>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
> 
> Oh, also, one relatively short term piece of this model is a proposal for 
> adding an async/await model to Swift (in the form of general coroutine 
> support).  Joe Groff and I wrote up a proposal for this, here:
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619
> 
> and I have a PR with the first half of the implementation here:
> https://github.com/apple/swift/pull/11501
> 
> The piece that is missing is code generation support.
> 
> -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

Re: [swift-evolution] Enums and Source Compatibility - defaults

[Rod Brown via swift-evolution]

Yes, I see your point, and that’s something I didn’t consider. If we allowed 
extending enums, this would then clearly indicate that “final” means something 
in the present as well - you cannot add cases.

This opens up the can of worms of extending enums, but I think it’s a fair 
point if we ever want to consider it that then “final" really would make the 
most sense.


> On 12 Aug 2017, at 8:28 am, Jordan Rose  wrote:
> 
> "final"'s on my list of possible names! But it's not quite the same as 
> 'final' for classes: "closed" only talks about what might change in the 
> future, while 'final'-on-a-class also states something about the class in the 
> present: it has no subclasses now as well as not gaining any new ones in the 
> future. Still, it could be closed enough that it ends up being the best bet.
> 
> Jordan
> 
> 
>> On Aug 10, 2017, at 22:23, Rod Brown > > wrote:
>> 
>> Hi all,
>> 
>> I thought I’d chime in with my own 2c…
>> 
>> I’d probably prefer something more like “final” and vs non-final. It’s the 
>> concept we’re dancing around - can you add something to extend it?
>> 
>> In which case, final would allow exhaustive use, and non-final would require 
>> handling the default case. Currently all Swift API would convert as “final”, 
>> and all imported Obj-C API (with perhaps exceptions) would import as is and 
>> require a default handling case. This negates the open vs public issue. But 
>> it does also mean that it would become a manual issue inside the module to 
>> mark the API as final to allow exhaustive switches, unless we say 
>> “exhaustive switches allowed on internal/fileprivate/private types”.
>> 
>> Unsure how this plays into the web of things, though…
>> 
>> Thanks,
>> 
>> Rod
>> 
>> 
>> 
>>> On 11 Aug 2017, at 9:41 am, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
 On Aug 10, 2017, at 13:00, David Hart > wrote:
 
 
 
 On 10 Aug 2017, at 19:19, Jordan Rose > wrote:
 
> 
> 
>> On Aug 9, 2017, at 22:46, David Hart > > wrote:
>> 
>> 
>>> On 10 Aug 2017, at 02:42, Jordan Rose >> > wrote:
>>> 
>>> :-) As you've all noted, there are some conflicting concerns for the 
>>> default:
>>> 
>>> - Source compatibility: the existing behavior for an unannotated enum 
>>> is "closed".
>>> - Intuition: if you show someone an enum without an explicit 
>>> annotation, they'll probably expect they can switch over it. (I'm going 
>>> to say this is why Zach calls it a "sensible default".)
>>> - Consistency: switches on an enum in the same module can always be 
>>> exhaustive, so having it be different across modules is a bit annoying. 
>>> (But 'public' already acts like this.)
>>> 
>>> vs.
>>> 
>>> - Library evolution: the default should promise less, so that you have 
>>> the opportunity to change it.
>>> - Flexibility: you can emulate an exhaustive switch with a 
>>> non-exhaustive switch using fatalError, but not the other way around.
>>> 
>>> All of this is why I suggested it be an explicit annotation in either 
>>> direction, but Matthew brought up the "keyword soup" problem—if you 
>>> have to write (say) "public finite enum" and "public infinite enum", 
>>> but would never write "private finite enum" or "private infinite enum", 
>>> something is redundant here. Still, I'm uncomfortable with the default 
>>> case being the one that constrains library authors, so at least for 
>>> binary frameworks (those compiled "with resilience") I would want that 
>>> to be explicit. That brings us to one more concern: how different 
>>> should binary frameworks be from source frameworks?
>> 
>> In terms of intuition and consistency, I think we should really try to 
>> learn from the simplicity of public/open:
>> 
>> * When internal, classes are sub-classable by default for convenience, 
>> but can be closed with the final keyword
>> * When public, classes are closed to sub-classing for safety, but can be 
>> opened up with the open keyword (which implies public).
>> 
>> If we try to mirror this behaviour (the keywords are just suggestions, 
>> not important):
>> 
>> * When internal, enums are exhaustive by default for convenience, but 
>> can be opened-up with the partial keyword
>> * When public, enums are non-exhaustive by default for safety, but can 
>> be made exhaustive with the exhaustive keyword (which implies public).
> 
> This is not a correct understanding of the internal/public distinction 

Re: [swift-evolution] [Pitch] Scoped @available

[Rod Brown via swift-evolution]

This is something I’m dealing with as a framework author as well.

I’m stumped coming up with anything better than your latter idea of “outside” 
even though I’m not really a fan.

Either way, I think that deprecating outside makes some sense from a framework 
developer’s perspective. You may need to signal an API is “not to be relied on” 
despite knowing at least temporarily you will need to keep using it, but it’s 
not recommended for outside consumption for various reasons.. I also think 
there’s a lot of general work towards handling deprecation warnings cleanly in 
Swift that hasn’t been addressed, but that’s really for another topic.

- Rod


> On 10 Jul 2017, at 5:39 pm, rintaro ishizaki via swift-evolution 
>  wrote:
> 
> 
> 
> 2017-07-10 14:05 GMT+09:00 Xiaodi Wu  >:
> This would be very useful, but the spelling needs dramatic improvement.
> 
> "Available unavailable" is already challenging to read, but at least it is 
> learnable with time. The example where "@available(*, deprecated, access: 
> internal) open" means "fileprivate" is entirely unreasonable.
> 
> 
> I agree, but I couldn't come up with a better spelling.
> 
> // "deprecated" if the access is from "outside" of "fileprivate" scope.
> @available(*, deprecated, outside: fileprivate) open
> 
> Hmm.. 樂
> 
> Any suggestions will be greatly appreciated!
> 
>  
> On Sun, Jul 9, 2017 at 22:40 rintaro ishizaki via swift-evolution 
> > wrote:
> Hi evolution community,
> 
> I would like to propose "Scoped @available" attribute.
> 
> What I want to achieve is to declare something that is publicly unavailable, 
> but still usable from narrower scope. A concrete example is IndexableBase in 
> the standard library:
> https://github.com/apple/swift/blob/master/stdlib/public/core/Collection.swift#L18-L20
>  
> 
> Workaround for this problem in stdlib is to use typealias to underscored 
> declaration. However, we can't use this technique in our module because 
> underscored declarations are still visible and usable from outside.
> 
> As a solution, I propose to add "access" parameter to @available attribute, 
> which limits the effect of @available attribute to the specified value or 
> outer.
> 
> ---
> // Module: Library
> 
> /// This protocol is available for internal, but deprecated for public.
> @available(*, deprecated, access: public, message: "it will be removed in 
> future")
> public protocol OldProtocol {
> /* ... */
> }
> 
> public Foo: OldProtocol { // No diagnostics
> }
> 
> ---
> // Module: main
> 
> import Library
> 
> public Bar: OldProtocol { // warning: 'OldProtocol' is deprecated: it will be 
> removed in future
> }
> 
> ---
> 
> I think this is useful when you want to stop exposing declarations, but want 
> to keep using them internally.
> 
> More examples:
> 
> // is `open`, going to be `filerprivate`
> @available(*, deprecated, access: internal)
> open class Foo {}
> 
> // was `internal`, now `private`
> @available(*, unavailable, access: fileprivate)
> var value: Int
> 
> // No effect (invisible from public anyway): emit a warning
> @available(*, unavailable, access: public)
> internal struct Foo {}
> 
> What do you think?
> ___
> 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] Setting expectations on when we move to Discourse

[Rod Brown via swift-evolution]

Perhaps there’s just a lot of work to do at the moment that has a higher 
priority than getting an improved Swift Community Comms method. I can scarcely 
fathom the amount of work within Apple being done to make sure Swift 4, iOS 11, 
macOS High Sierra, Xcode 9, and all the other great projects all get out 
sometime within the next few months.

My expectation is that once we move past the hard deadlines of these releases, 
there would be time to start performing this move. The issue isn’t just setting 
up a server. There are a lot of other issues beyond the actual implementation 
(legal, setting the conversations up right, scale, security, simple 
prioritisation of resources to *do* the albeit relatively small amount of work).

> On 21 Jul 2017, at 2:20 am, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> Moving to Discourse (from the mailing lists) is something that is being 
>> scoped out, but I wanted to lay some expectations that the move will not be 
>> immediate.
> 
> I can comprehend that hard problems like ABI-stability take a while, but imho 
> it's no good sign that a (a least from a technical standpoint) simple task 
> like setting up a server needs so much time.
> 
> That status update is quite old now, and I guess many have been disappointed 
> that the switch wasn't finished until or during the last WWDC…
> Is the move still on the agenda, or did the decision die silently in the last 
> months? (or did I just break my spamfilter and I'm already receiving messages 
> from Discourses' mail gateway? ;-)
> 
> 
> ___
> 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] Enforce non-nil assignment to an implicitly unwrapped optional property?

[Rod Brown via swift-evolution]

Implicitly unwrapped optionals are often used when the optional system is a 
little complicated around one of your variables.

Some of those times are variables that are nil-resettable (where you set nil, 
and it internally does something to use that as a reset case) or initialisation 
issues where you can’t know a variable at prior to the initialisation, but can 
get it out. But these are just two examples.

I think trying to work more on tying people’s hands with this attribute 
specifically designed to handle edge cases seems a little… concerning.

It might make more sense to use a computed property covering the internal 
property completely if you need this behaviour? 

> On 19 Jul 2017, at 3:31 pm, Glen Huang via swift-evolution 
>  wrote:
> 
> Anyone has any thoughts on this?
> 
>> On 16 Jul 2017, at 3:46 PM, Glen Huang via swift-evolution 
>>  wrote:
>> 
>> I want to define a property for a struct/class that is nil after 
>> initialization, but later is guaranteed to have a value after I manually 
>> assign to it. I think implicitly unwrapped optional property is designed 
>> specifically for that.
>> 
>> However, the problem arises when it comes to how do I enforce that I never 
>> mistakenly assign nil to this property?
>> 
>> struct Foo {
>>   var name: String!
>> }
>> var foo = Foo()
>> 
>> I can do foo.name = nil and it will compile just fine.
>> 
>> I guess I could do a run-time check with something like:
>> 
>> struct Foo {
>>   var name: String! {
>>   willSet {
>>   if newValue == nil {
>>   fatalError("nil isn't allowed")
>>   }
>>   }
>>   }
>> }
>> 
>> But it feels ugly, and seems to be something checkable at compile time.
>> 
>> I could define a new setter method:
>> 
>> struct Foo {
>>   private(set) var name: String!
>>   mutating func setName(_ name: String) {
>>   self.name = name
>>   }
>> }
>> 
>> But it feel tedious. Enforcing non-nil assignment probably fits 90% of the 
>> use cases of IUOs, since that’s basically their definition. Having to 
>> deviate from direct assignment syntax in usage and also define a new setter 
>> method for the majority cases seems unfortunate.
>> 
>> I wonder if it’s desirable to define an attribute or something to ask the 
>> compiler to only allow non-optionals to be assigned to IUO properties?
>> ___
>> 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] Change default compiler fix for not-unwrapped Optional from ! To ?

[Rod Brown via swift-evolution]

> On 15 Jul 2017, at 9:54 am, Robert Bennett via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> For expressions whose type is definitely non-optional, it makes sense to 
> verbally suggest both ! and ?? (and/or !! – was that accepted?), and it’s 
> probably best to insert ! when the fixit is accepted. For expressions whose 
> type is undetermined, but which need some form of Optional handling, it would 
> be best for the compiler to assume the type is meant to be optional and 
> insert a ?.

I think its fair that where the context can be optional, the default fixit 
should be optional. I’ve seen this issue myself from junior swift devs where 
they apply a fixit.

e.g.:

let optionalReturnedValue = item.optionalValue.optionalValue2?.item

And the fixit Xcode recommends on optionalValue is “!"…

let optionalReturnedValue = item.optionalValue!.optionalValue2?.item

It seems wiser in these cases if the compiler is smart enough for the default 
fixit to be “?”. I’m not sure if the compiler is able to do that or is in 
scope, that’s for smarter people than I to say.

In cases where the compiler, due to the context, requires the value to be 
non-optional, for a “!”, “??”, or the proposed “!!” makes sense.

“If let”, “guard let” etc all very much butcher the code at the callsite. They 
fundamentally change the control flow, and I could imagine many of the times 
its suggestions really won’t make sense for the given situation. How smart 
should we make the compiler before we’re practically making it rewrite all your 
code anyway? In this case, I’d rather there be no fixit at all, and just let 
the developer actually understand and restructure their code to correctly 
handle the optional case.

- Rod


> 
> On Jul 14, 2017, at 2:41 PM, Erica Sadun via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Jul 14, 2017, at 2:11 AM, Víctor Pimentel via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> On 14 Jul 2017, at 08:05, Rod Brown via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 14 Jul 2017, at 2:36 pm, Robert Bennett via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> When writing Swift code, it is not uncommon to forget to unwrap 
>>>>> optionals. The compiler will offer a fixit, telling you you must insert 
>>>>> either a ? or a !. However, when you accept the fixit, ! is inserted (at 
>>>>> least, it is for me in Xcode 8.3).
>>>> When you treat an optional as non-optional, the compiler has no way to do 
>>>> a fixit that would appropriately handle the optional. Felix made a good 
>>>> example. The only direct fixit would be a force unwrap. If you used “?” 
>>>> then your non-optional use would turn into an optional and your parameter 
>>>> would generally be non-optional. The fixit is just explicitly doing what 
>>>> you implicitly expected it to do.
>>>> 
>>>>> 
>>>>> Ideally the fixit would default to ? because this is the preferred 
>>>>> option; ! is often a sign of non-Swifty code and does not interact well 
>>>>> with idiomatic Swift constructs such as if-let-(as?), 
>>>>> guard-let-(as?)-else, etc. Also I think it’s safe to say that fixits 
>>>>> should not err on the side of crashing at runtime.
>>>> 
>>>> " ! is often a sign of non-Swifty code “
>>>> I would strongly challenge this assumption. Many core team members have 
>>>> commented about appropriate uses of the ! operator. It shouldn’t be used 
>>>> lightly, but it’s there for a reason and it most definitely isn’t 
>>>> “non-swifty”.
>>> 
>>> I think it's not a farfetched assumption to imply that if the compiler 
>>> encounters that code, the programmer didn't realize or remember that they 
>>> were dealing with optionals.
>>> 
>>> If the compiler suggests to force unwrap that expression, it is also fair 
>>> to assume that most inexperience programmers will just apply that fix it. A 
>>> more experience programmer can decide whether to force unwrap it or to 
>>> handle the nil case in any other way, depending on the context and code 
>>> style.
>>> 
>>> Personally, I'd prefer that the compiler didn't encourage so much to use 
>>> force unwra

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Rod Brown via swift-evolution]

Thanks Erica. That looks great.

As a side-note, one of the sentences in “The Black Swan Deployment” references 
a “Mackintosh” - I believe this was supposed to be “Hackintosh”.


> On 30 Jun 2017, at 3:20 am, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 29, 2017, at 9:13 AM, Dave DeLong > > wrote:
>> 
>> My usage of “!!” generally falls in to two big buckets:
>> 
> 
> I've incorporated all the feedback to date and updated the gist:
> 
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
> 
> 
> -- E
> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Rod Brown via swift-evolution]

> On 29 Jun 2017, at 11:18 am, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> In the initial example, repeated here in largely identical form, the desired 
>> comment is "array must be non-empty." In what way does that provide more 
>> information than a bare `!`?
>> 
> 
> By the same token, why does precondition have an optional string? Why would 
> you ever want to write more than:
> 
> precondition(!array.isEmpty)
> 
> It’s self evident – the array must not be empty! Why the second argument? 
> 
> Because you might want a meaningful string to be output when the app traps. 
> And it gives you somewhere to document why it mustn’t be empty – the 
> explanation for the precondition rather than the precondition itself. 
> Similarly, when your app traps because of an unwrapped nil, it’s desirable to 
> get some output in your debug console telling you why straight away, rather 
> than have to hunt down the code, read the line that failed, then read the 
> context around the line, to understand the reason. This is even more 
> important if you didn’t write this code yourself.
> 
> Finally, there’s a woolier justification: there’s an often-touted 
> misconception out there that force unwraps are bad, that they were only 
> created to accommodate legacy apps, and that force-unwrapping is always bad 
> and you should never do it. This isn’t true – there are many good reasons to 
> use force unwrap (though if you reaching for it constantly it’s a bad sign). 
> Force-unwrapping is often better than just whacking in a default value or 
> optional chaining when the presence of nil would indicate a serious failure. 
> Introduction of the `!!` operator could help endorse/encourage the use of 
> “thoughtful” force-unwrapping, which often comes with a comment of the 
> reasoning why it’s safe (of why the array can’t be empty at this point, not 
> just that it is empty). And if you’re going to write a comment, why not make 
> that comment useful for debugging at the same time.

I’m so glad the above has been stated outright here. It’s a bugbear of mine 
hearing people preach that the ! operator is always wrong.

> 
> In cases where it’s really not necessary, ! would remain just like, when 
> you’re not really too fussed, you can leave off the string from a 
> precondition.
> 
> 
> ___
> 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] Yet another fixed-size array spitball session

[Rod Brown via swift-evolution]

While I can’t comment about the technical details, I have to say, this looks 
really “unswifty” to my eye. I’d probably expect something more along the lines 
of:

let x: FixedArray = [1, 2, 3]

or:

let y: StaticArray = [1, 2, 3]
  


> On 29 May 2017, at 4:37 pm, Daryle Walker via swift-evolution 
>  wrote:
> 
> Static-Sized Arrays
> This is a new proposed syntax for handling array types whose size is fixed at 
> compile time. This is a classic kind of type that's still missing in Swift.
> 
> Like the built-in processor numeric types are mapped to special struct types, 
> any built-in vector types should be mapped to special array types. There 
> should be some sort of construct to allow parallel visitation of elements.
> 
> For a given array type A with an element type B, we have strideof(A) == COUNT 
> * strideof(B), where COUNT is the number of elements in the array, which is 
> the product of the lengths along each dimension. (A zero-dimension array has 
> an element count of one.)
> 
> New Keywords
> array
> of
> These keywords should be conditional if possible. The of shouldn't appear 
> without following an array, so of should be easy to make conditional.
> 
> Immediate Arrays
> Immediate arrays are a new kind of compound type. They have value semantics.
> 
> let x: array 3 of Int = [1, 2, 3]
> var y: array 2 of array 5 of Double
> Hopefully, this is simpler than my last proposal. I'm thinking that "array" 
> is like a verb here.
> 
> The element type is at the end, so no parentheses (or similar) are needed. 
> The syntax is easy to expand for nested array types. Here, the extents go 
> from the widest span to the narrowest, like nested arrays in C. The inner 
> element type is at the end instead of the start.
> 
> assert(x.0 == 1)
> x.3 = 3  // ERROR!
> y.1.3 = 3
> y.0 = [-3, -2, -1, 0, +1]
> Elements are addressed just like in tuples.
> 
> Nominal Arrays
> Nominal arrays are a new kind of named type. They have value semantics.
> 
> array MyArray: (0..<6) of Int {
> /* ... */
> }
> I'm thinking "array" is like an adjective (or noun) here. The 
> base-and-protocol list must have a shape specifier as its first item.
> 
> shape-specifier → ( extents-list_opt ) of type
> 
> extents-list → extent
> 
> extents-list → extent , extents-list
> 
> extent → type storage-rank_opt
> 
> extent → expression ..< expression storage-rank_opt
> 
> extent → expression ... expression storage-rank_opt
> 
> storage-rank → : expression
> A type used for an extent:
> 
> Must be a raw-value enumeration type.
> The raw-value type must be one of the default integer types.
> There must be at least one case, and all the cases must form a contiguous 
> range of values.
> A range used for an extent:
> 
> Must use for its boundary type either:
> a default integer type, or
> an enumeration type that could qualify as an extent type.
> Must be a valid range with at least one element.
> The expression for a storage rank must evaluate to a compile-time integer 
> value that is at least zero and less than the number of extents. An extent 
> without an explicit storage rank gets one equal to the smallest valid value 
> yet unused. (Multiple extents without explicit ranks are finalized in lexical 
> order.)
> 
> The extent with the largest storage rank has elements with adjacent indexes 
> (assuming all other extents use fixed indexes) placed adjacent in memory. The 
> extent with storage rank 0 have elements with adjacent indexes (assuming all 
> other extents use fixed indexes) the furthest span apart in memory.
> 
> The total number of elements for the array is the product of the lengths of 
> the extents. A zero-dimension array has a singular element.
> 
> A nominal array type can have type-level members and computed instance-level 
> properties, just like the other named types. The initial set of members, if 
> not overridden, are:
> 
> A type-alias Element that refers to the element type.
> A type-alias Index that refers to a tuple composed of the extent types. For a 
> range-based extent, the corresponding type is its boundary type.
> If the element type is default-initializable, a default initializer.
> An initializer that takes as its only parameter an Element, which is copied 
> to each element.
> An initializer that takes as its only parameter a closure that takes as its 
> only parameter an Index and returns the value the corresponding element 
> starts with.
> An initializer similar to the previous, but the closure takes the index 
> tuple's parameters separately.
> Two subscript members, with get and set modes, to handle dereferencing. One 
> member takes an Index, the other an exploded index list. It's an error to 
> refer to an invalid index location.
> Flexible Array Reference
> To not have to fix a function for each extent shape, something similar to the 
> old T[] array segment idea from C(++) is needed:
> 
> func foo(x: array of Int) -> Int
> func bar(y: array of 

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Rod Brown via swift-evolution]

> On 2 May 2017, at 2:33 pm, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Mon, May 1, 2017 at 11:22 PM, T.J. Usiyan  > wrote:
> Xi: "Does this gain something by being part of the standard library?"
> Me: "This gains discoverability and standardization by being part of the 
> standard library."
> Xi: "By definition, if it's in the standard library, it becomes standardized 
> and discoverable."
> 
> We're in agreement, then?
> 
> No, you're missing the point entirely. Again, _anything_ gains 
> "discoverability and standardization" by being included as part of the 
> standard library. However, the standard library is deliberately small and is 
> intended to stay that way. So, what should be in and what should be out? The 
> question is: does this feature gain something by being part of the standard 
> library which other features that are deliberately excluded (like left pad) 
> do not?

I’m going to back Xiaodi on this one. The standard library is the standard for 
the language, by definition. That comes with some great things, and some 
concerning things.

If we decided anything that was generic and useful as a basis for programming 
got in, we wouldn’t call it the “Standard Library” - it would be the Kitchen 
Sink Library. It would be huge. The bar has to be set higher for the library.

Why is the current repeat functionality in there? Because Strings use it. Why 
is it public? Because, like you, people noticed it and said “That’s great 
generic functionality, why not expose it, and let everyone use it?” But that 
isn’t the bar for adding things: the bar is far higher for them to be added. 
Especially now as we’re trying to mature Swift from it’s immature fast-moving 
state. This may be the bar for *exposing* generic things, but the higher bar of 
“is this core?” may not be met with this proposal.

Don’t get me wrong, I think it’s a great idea. I just am not sure it meets the 
bar of “core”.

> 
> Repeating a collection endlessly is a useful ability.
> 
> I don't doubt it. Is your argument that any useful and commonly used feature 
> should be part of the standard library? That's simply not the stated criteria 
> for inclusion in the standard library. Hence, why Foundation exists outside 
> of it. There's no point in debating these criteria, as (afaict) that's not up 
> for debate. Again, I don't make the rules. I'm just saying they exist, and 
> I'm arguing that we should abide by them.
>  
> Yes, it can be written on top of the standard library. It would be generally 
> nice not to require that *especially* when we can repeat single elements 
> without similar effort. The asymmetry is awkward to remember for newbies and 
> awkward to explain away  with "we want a focused library so… the Thing A 
> stays but this logically related Thing B can't be in even though showing you 
> the ability to do A does tend to lead you to ask after Thing B."
> 
> 
> On Mon, May 1, 2017 at 11:55 PM, Xiaodi Wu  > wrote:
> That's a tautological argument, though. By definition, if it's in the 
> standard library, it becomes standardized and discoverable. This isn't at all 
> a limiting principle for what goes into the library and what doesn't.
> 
> And as I said, there are many commonly useful facilities that aren't part of 
> the standard library, by design and not by oversight. Left pad is one of them.
> 
> I'm trying to tease out whether this particular proposal meets the current 
> bar for inclusion. If you believe left pad should be included, your beef is 
> with the deliberate choice to have a small standard library, which as far as 
> I know is not up for reconsideration.
> 
> On Mon, May 1, 2017 at 22:41 T.J. Usiyan  > wrote:
> This gains discoverability and standardization by being part of the standard 
> library. New folks would not have to import some library or roll their own to 
> get this reasonable to expect/hope or hope for functionality. Perhaps 
> removing the old function isn't going to work but repeating collections is 
> definitely something useful.
> 
> Left padding for strings would be nice as well, but that is neither here nor 
> there. 
> 
> On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  > wrote:
> 
> > On 2 May 2017, at 04:44, Xiaodi Wu  > > wrote:
> >
> > Does this gain something by being part of the standard library as opposed 
> > to being built on top of it?
> 
> Well, somebody thought repeatElement was general enough to make part of 
> the standard library. If we’re going to allow repeating a single item as a 
> Collection, we might as well allow generalise it to repeating any 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Rod Brown via swift-evolution]

> On 2 May 2017, at 2:34 am, John McCall <rjmcc...@apple.com> wrote:
> 
>> 
>> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> I agree that the key problem with the current architecture that you're 
>> alluding to is it can't be easily stored and transferred. Swift errors are 
>> great for live action but holding and passing after the throwing event is 
>> problematic, and this is an elegant solution. The storage issue is when 
>> holding it as a property, and the transferring issue is when passing it to a 
>> closure as a results of an asynchronous operation etc. These are both 
>> definitely cases where storage of the type-or-error makes perfect sense.
>> 
>> I think the key problem getting this accepted by the Swift Team will be that 
>> it doesn't currently have any specific use in the standard library. As a low 
>> level set of types, errors are generated by the lower levels but rarely 
>> stored, so the Standard library doesn't need the storage. Generally the only 
>> place we have to do that is in end user code. And currently the standard 
>> library doesn't have to support asynchronous operations natively, so there's 
>> nothing inside the kit that would require it to do completion handlers with 
>> errors.
> 
> We've definitely considered including a Result type, but our sense was that 
> in an ideal world almost no code would be using it.  It's hard to imagine an 
> ordinary API that ought to be returning a Result rather than throwing, and 
> once you've defined that away, the major remaining use case is just to shift 
> computation around, like with a completion handler.  That explicit 
> computation-shifting pattern is something we're hoping to largely define away 
> with something like C#'s async/await, which would leave Result as mostly just 
> an implementation detail of such APIs.  We didn't want to spend a great deal 
> of time designing a type that would end up being so marginal, especially if 
> the changing role would lead us into different directions on the design 
> itself.  We also didn't want to design a type that would become an obstacle 
> to potential future language changes like, say, typed throws.
> 
> The downside, of course, is that as long as we lack that async/await design, 
> computation-shifting isn't real great.
> 
> John.

This makes sense and is sensible. I’m curious how such an API would play with 
the existing NSURLSession completion handlers and the like, but I’m sure the 
community can design something appropriate.

I think the only remaining case is simply storing a result-or-error for later 
handling, storage to disk, etc. I agree with your contention that the vast 
majority of the use case for this type is for computation shifting. I think it 
would and should be rare that we would want to “store” as a variable the 
“result-or-error” type. Errors should be handled at runtime in the vast 
majority of cases, presented to the user or otherwise handled, and then moved 
on from, with the reason no longer being relevant.

As you say, in the meantime, it does leave computation-shifting a bit ad-hoc 
and convoluted, but I think the community has standardized on the Result 
temporary solution.

> 
>> 
>> This would therefore be an element in the standard library purely so we 
>> don't have 50,000 different libraries with 50,000 different result types. 
>> I'd love to see this standardised so frameworks were more compatible. I'm 
>> just not sure whether the Core Team would see it as pressing to try and 
>> officiate a certain type that they themselves don't use.

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

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Rod Brown via swift-evolution]

> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan  wrote:
> 
> Yeah, you’re absolutely right. the “value-or-nil” and 
> “value-or-reason-why-not-value” are two different things and the former is 
> used too liberally in place of the latter because of lack of support.
> In that case, the Result type should not replace the error handling, but 
> augment it. The error handling mechanism is extremely well though-out and 
> convenient for its purpose, but it makes it difficult to capture and store a 
> union of (value; flying error).

I agree that the key problem with the current architecture that you're alluding 
to is it can't be easily stored and transferred. Swift errors are great for 
live action but holding and passing after the throwing event is problematic, 
and this is an elegant solution. The storage issue is when holding it as a 
property, and the transferring issue is when passing it to a closure as a 
results of an asynchronous operation etc. These are both definitely cases where 
storage of the type-or-error makes perfect sense.

I think the key problem getting this accepted by the Swift Team will be that it 
doesn't currently have any specific use in the standard library. As a low level 
set of types, errors are generated by the lower levels but rarely stored, so 
the Standard library doesn't need the storage. Generally the only place we have 
to do that is in end user code. And currently the standard library doesn't have 
to support asynchronous operations natively, so there's nothing inside the kit 
that would require it to do completion handlers with errors.

This would therefore be an element in the standard library purely so we don't 
have 50,000 different libraries with 50,000 different result types. I'd love to 
see this standardised so frameworks were more compatible. I'm just not sure 
whether the Core Team would see it as pressing to try and officiate a certain 
type that they themselves don't use.


> A built-in Failable enum with syntactic support to losslessly catch it from a 
> throwing expression and unpack it into a throwing scope would be a very 
> useful feature.
> Optionals are extremely convenient, but in cases where the Optional is used 
> as “value-or-error” rather then “value-or-nil” it falls a bit short and the 
> programmer has to choose between extreme convenience of Optionals with the 
> downside of lack of error information or the expressive power of throwing an 
> error with the downside of a lot of boilerpate and poor integration with 
> generics.
> Here’s an example pseudo-swift that illustrates this:
> 
> enum Failable {
>   
>   case success(Wrapped)
> 
>   case failure(Error)
> 
> }
> 
> func foo() throws -> Int {
>   guard myCondition else {
>   throw EmbarressingError.oops
>   }
>   return 42
> }
> 
> let failable = catch foo() // Failable
> 
> func bar() throws -> Int {
>   throw failable
> 
> 
> 
>> On May 1, 2017, at 11:17 AM, Rod Brown  wrote:
>> 
>> The problem I see with your argument is that the core reason why the 
>> optional cast failed is actually there: It was an optional value, and you 
>> forced it to unwrap without checking. This is a correct description of the 
>> error.
>> 
>> If we plumbed our code with a tonne of errors saying “why this is optional, 
>> and why it is null” then we are practically making every optional an error 
>> in the case of nil, which is completely illogical considering that nil could 
>> be a completely legitimate case (especially in the case of 
>> not-implicitly-unwrapped optionals).
>> 
>> Optional is a wrapper for "value-or-null", not "value-or-reason-not-value".
>> 
>> The type you are talking about is a result/sum type as has been mentioned, 
>> which is fine, and is completely valid (I use them a lot too) but they are 
>> definitely not the same thing as an optional, and I think you’re conflating 
>> the two ideas.
>> 
>> - Rod
>> 
>> 
>>> On 1 May 2017, at 5:58 pm, Gor Gyolchanyan via swift-evolution 
>>>  wrote:
>>> 
>>> I have read those documents before, but It’s worth re-reading them to see 
>>> if I missed something, but I’l still explain my motivation and seek 
>>> arguments against the postulated problem (rather then a specific solution).
>>> 
>>> (a) There are different types of error.
>>> 
>>> Yes, there are different types of error in Swift, which require different 
>>> reactions from the programmer.
>>> If I’m not missing something, the three main types of error in Swift are:
>>>  - Simple encapsulatable errors that are expected to be treated as normal 
>>> values until the time comes for someone to take care of them by unpacking 
>>> the content.
>>>  - Automatic propagatable errors that require the programmer to either 
>>> handle the error immediately or propagate it by delegating to its own 
>>> caller.
>>> - Fatal errors, which represent logic errors and broken invariants and 
>>> 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Rod Brown via swift-evolution]

The problem I see with your argument is that the core reason why the optional 
cast failed is actually there: It was an optional value, and you forced it to 
unwrap without checking. This is a correct description of the error.

If we plumbed our code with a tonne of errors saying “why this is optional, and 
why it is null” then we are practically making every optional an error in the 
case of nil, which is completely illogical considering that nil could be a 
completely legitimate case (especially in the case of not-implicitly-unwrapped 
optionals).

Optional is a wrapper for "value-or-null", not "value-or-reason-not-value".

The type you are talking about is a result/sum type as has been mentioned, 
which is fine, and is completely valid (I use them a lot too) but they are 
definitely not the same thing as an optional, and I think you’re conflating the 
two ideas.

- Rod


> On 1 May 2017, at 5:58 pm, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> I have read those documents before, but It’s worth re-reading them to see if 
> I missed something, but I’l still explain my motivation and seek arguments 
> against the postulated problem (rather then a specific solution).
> 
> (a) There are different types of error.
> 
> Yes, there are different types of error in Swift, which require different 
> reactions from the programmer.
> If I’m not missing something, the three main types of error in Swift are:
>  - Simple encapsulatable errors that are expected to be treated as normal 
> values until the time comes for someone to take care of them by unpacking the 
> content.
>  - Automatic propagatable errors that require the programmer to either handle 
> the error immediately or propagate it by delegating to its own caller.
> - Fatal errors, which represent logic errors and broken invariants and 
> preconditions, which are purely a programmer error and should not be dealt 
> with dynamically, hence the terminated process with a message.
> 
> (b) The programmer is expected to react differently to different types of 
> error.
> 
> Yes, and the three main ways a programmer is expected to react to the an 
> error are:
>  - If it’s an optional, they’re encouraged to store and pass it around freely 
> until someone down the line decides to unpack it and deal with the 
> possibility that it isn’t there.
>  - If it’s an error, they’re encouraged to either handle it on the spot or 
> declare themselves throwing and delegate the responsibility to the caller.
>  - Look at the standard output and figure out why the fatal error occurred, 
> perhaps with the help of the debugger.
> 
> (c) The language is a tool to help the programmer react.
> 
> Yes, that comes in the form of three language constructs:
>  - Optionals, which allow storing a union of a value and its absence (for an 
> undefined and hopefully obvious reason).
>  - Throwing functions, which allow making sure that the error will be handled 
> as soon as possible.
>  - Fatal errors, which allow the programmer to mark points in code which 
> should never be reached in a correct system in order to keep the logic from 
> going AWOL in case the programmer screwed up somewhere.
> 
> (d) Optionals and errors are not unified, and unification is a non-goal, 
> because they are designed to help the programmer react differently to 
> different types of error.
> 
> Yes, and those different types of error with different reactions are all 
> valid and shouldn’t be unified.
> My point is that the language should make it easy for a programmer to 
> transition from one type of error to another, because the same error has 
> different severity in different contexts.
> For instance, a “file not found” error when trying to open a file handler is 
> not critical at all in the context of the file opening function, because it’s 
> a perfectly expected outcome of the operation.
> However, for a module that handles loading critical data from disk (like 
> encryption keys needed to decrypt the manipulated content) it is a critical 
> error that cannot be dealt with.
> In this case it deserves to be a fatal error, because the programmer didn’t 
> bother to implement a logic for creating the missing file or properly 
> notifying the user of the lacking permissions to do so.
> Conversely, some errors start as being urgent (like a JSON parser that throws 
> an error when it encounters invalid syntax), but become less urgent for the 
> client (a JSON editor that simply displays the error message).
> 
> As for my use case:
> 
> I have a JSON parser that may throw, and I have a a JSON Editor class that 
> allows editing JSON files as well as displaying the parsing errors.
> I have a malformed JSON file that I open in the editor. The JSON parser 
> throws an error, which should be caught and stored somewhere for the editor 
> to display.
> I have file reader that reads a file in some encoding and returns an optional 
> string with the file contents (nil means file 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Rod Brown via swift-evolution]

> On 8 Apr 2017, at 2:34 pm, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.

With this being the case, I want to revise my response to +1. It allows the 
flexibility required for the extension-rich architecture Swift open adopts with 
protocol conformance and I think that’s a good thing, personally.

> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> extension, it means "available in this file" i.e. the same as 'fileprivate'
>> 
>> So if we're worried that this proposal makes the meaning of 'private' 
>> unclear - it already is unclear. Wouldn't it be much more clear if private 
>> global variables, functions and classes were required to use the access 
>> level that means "available in this file", since that's how they actually 
>> work? 

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Rod Brown via swift-evolution]

> On 7 Apr 2017, at 9:10 am, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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?
It pains me to say this: -1. I think this is a bandaid solution.

Swift had a simple module based access control. Was it the right one? 
Debatable. But at least the story was consistent and it worked. Then Scoped 
access came along rather than trying to really flesh out the problem of access 
control, and for some stupid reason, we chose to make private scoped and 
introduce a terrible access modifier for what was "private" before.

We don't have submodules yet. When they come, we need to flesh this stuff out, 
and deal with concepts like "protected" ect rather than ignoring them like we 
seem to be doing.

I think reverting the behaviour (in the previous proposal) was right short 
term, but not long term, and created unnecessary churn. But the fight for Swift 
source stability needs to take a back seat to getting this right in the Swift 5 
timeline and we need to accept that some level of pain will come because we 
need to rework this stuff to get it right for the future.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. We need to sort out access control. The current solution seems ill 
equipped for the future.

> Does this proposal fit well with the feel and direction of Swift?
No. It is a bandaid solution which confuses the point of 'private'. Is it 
scoped, or a weird mid-way between a scoped and fileprivate?

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Some with access control, and our system seems broken.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Quick reading.

> 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 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] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

[Rod Brown via swift-evolution]

> On 6 Apr 2017, at 4:39 am, John McCall via swift-evolution 
>  wrote:
> 
> Hello, Swift community!
> 
> The review of "SE-163: String Revision: Collection Conformance, C Interop, 
> Transcoding" begins now and runs through next Tuesday, April 11th. The 
> proposal is available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.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/0155-normalize-enum-case-representation.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?

+1. (If I could +100, I would). Great start to the string overhaul.


>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
Yes. Aligns the string model much closer to the mental model we manipulate 
strings with.

>   • Does this proposal fit well with the feel and direction of Swift?
Yes. Its a tidier and more consistent implementation of what ultimately ends up 
being a convoluted collection of characters.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
Some experience with C++ and lots of experience with Swift 1, 2 and Obj-C 
Strings. This brings Swift String back to the consistent logical clarity it had 
in Swift 1.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
Quick reading, following Swift String discussions, etc.

> 
> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> John McCall
> 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

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

[Rod Brown via swift-evolution]

Hi Rob,

I think we could actually do that (and cause the same bug) with the derived 
classes Anton mentioned, which means the behaviour is inconsistent, despite the 
perhaps safety.

- Rod

> On 11 Mar 2017, at 6:32 am, Rob Mayoff <may...@dqd.com> wrote:
> 
>> On Fri, Mar 10, 2017 at 6:08 AM, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> Hi everyone. I found something odd that seems baked into how Cocoa Touch 
>> does protocols, but Swift cannot model it:
>> 
>> 
>> @interface UIScrollView: UIView
>> 
>> @property (weak, nonatomic) id  delegate;
>> 
>> @end
>> 
>> @interface UITableView: UIScrollView
>> 
>> @property (weak, nonatomic) id  delegate;
>> 
>> @end
>> 
>> @protocol UITableViewDelegate: UIScrollViewDelegate
>> ...
>> @end
> 
> The problem here is that `UITableView`'s redefinition of `delegate` is not 
> type-safe. By casting a `UITableView` reference to a `UIScrollView`, you set 
> the `delegate` to something that doesn't conform to `UITableView`:
> 
> @interface ViewController () 
> @end
> 
> @implementation ViewController
> 
> - (void)viewDidLoad {
> [super viewDidLoad];
> 
> UITableView *tableView = [[UITableView alloc] init];
> 
> // This line correctly generates a warning, because self isn't a 
> UITableViewDelegate:
> tableView.delegate = self;
> 
> // This line generates no warning:
> ((UIScrollView *)tableView).delegate = self;
> }
> 
> @end
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Specified Protocol Conformances in Subclasses

[Rod Brown via swift-evolution]

Hi everyone. I found something odd that seems baked into how Cocoa Touch does 
protocols, but Swift cannot model it:


@interface UIScrollView: UIView

@property (weak, nonatomic) id  delegate;

@end

@interface UITableView: UIScrollView

@property (weak, nonatomic) id  delegate;

@end

@protocol UITableViewDelegate: UIScrollViewDelegate
...
@end



Subclasses can further specify the conformance of a property’s 
protocol-conforming object to state a further type on that property. I tried to 
do something extremely similar today in Swift, and it failed, saying the 
protocols were different:


class SourceBar: UIScrollView {

override var delegate: SourceBarDelegate? {
get { return super.delegate as? SourceBarDelegate }
set { super.delegate = newValue }
}

} 


@objc protocol SourceBarDelegate: UIScrollViewDelegate {
func foo()
}


Considering the fact that the protocol SourceBarDelegate conforms to 
UIScrollViewDelegate, I can’t see why this override should fail. Can anyone 
enlighten me as to why this is a limitation in the language?

Thanks,

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

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

[Rod Brown via swift-evolution]

There has been a lot of discussion around this design decision. Personally, I’m 
with you: this should be allowed. Protocol extensions should be defaults, 
nothing more.

The rationale mentioned in Swift Evolution for discouraging this behaviour 
tends to be that if you conform to the protocol, you should conform and adhere 
to all its extensions as well, and that not doing so in the same way will be 
inconsistent.

I personally think this comes to the Type-first vs Protocol-first approach and 
I think instances of types should have the final say in the behaviour of the 
operation. While this would perform slightly worse, and could potentially be 
unsafe, I think it is consistent with the fact that not all implementers of a 
protocol behave exactly the same; indeed, if they did, we’d only have one type 
per protocol, in which case, what is the point of a protocol at all? Just do it 
with types.

I love POP and protocol extensions but I’m tempered by the fact that not all 
types implement protocols in the same ways, and we can’t predict ahead of time 
where those differences will be needed.


> On 10 Mar 2017, at 12:48 am, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> My question is why cannot the Base type override the default implementation? 
> I might want to override it, by calling the default implementation and 
> modifying the result for my needs.
> 
> Something like that:
> 
> protocol P {
> func foo() -> Int
> }
> 
> extension P {
> func foo() -> Int {
> return 42
> }
> }
> 
> class Base : P {
> override func foo() -> {
>  
> return default.foo() * 100
> }
> }
> The example is kept simple.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution 
>> > wrote:
>> 
>>> I think the fact that the type checker permits ‘final’ to appear inside 
>>> protocol extensions is an oversight and this probably does not even warrant 
>>> a proposal. I don’t think allowing this was ever part of the conceptual 
>>> model of protocol extensions at any point in time (if you recall they were 
>>> introduced ‘recently’, in Swift 2). If someone put together a PR which 
>>> makes ‘final’ in protocol extensions an error in Swift 4 mode (and a 
>>> warning in 3), I would merge it.
>>> 
>>> FWIW that there is one restriction around the direct dispatch here we want 
>>> to lift, but it’s not related to this proposal.
>>> 
>>> If you have a base class conforming to a protocol using default 
>>> requirements, eg
>>> 
>>>   protocol Proto { func f() }
>>>   extension Proto { func f() { } }
>>> 
>>>   class Base : Proto {}
>>> 
>>> Currently the witness table for Base : Proto directly references the 
>>> extension method Proto.f.
>>> 
>>> We want to allow this, at least inside the module:
>>> 
>>> class Derived {
>>>   override func f() {} // does not work currently
>>> }
>>> 
>>> This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing 
>>> at the extension method. The conformance will dispatch through the vtable 
>>> instead of directly calling the extension method.
>> 
>> Would this allow the override to call `Proto.f` through super?
>> 
>>> 
>>> Slava
>>> 
 On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution 
 > wrote:
 
 Hey Folks, This draft proposal addresses starter bug SR-1762. I believe 
 this is in scope for Swift 4 since it impacts source compatibility. It's 
 not a very exciting proposal, but I think it will help make Swift a little 
 more consistent.
 
 https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7 
 
 https://bugs.swift.org/browse/SR-1762 
 
 
 Thanks
 
 Brian
 Introduction
 
 This proposal suggests removing support for the final keyword when 
 declaring a function in a protocol extension. The presence of the final 
 keyword does not currently generate an error message, and it does not 
 actually modify the dispatch behavior in any way.
 
  
 Motivation
 
 In the original protocol model of Swift, a developer could use the final 
 keyword when declaring a function in a protocol extension to ensure the 
 function could not be overridden. This keyword has no use in Swift's 
 current protocol model, since functions in protocol extensions can not be 
 overridden and will always use direct dispatch.
 
  
 

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

[Rod Brown via swift-evolution]

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

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

[Rod Brown via swift-evolution]

I agree with your assessment that KVO may not be the right tool for this 
because the binding doesn't allow you to declare which thread you'd like the 
observation posted on. I suspect this design was supposed to be inline with the 
patterns of Cocoa, despite the fact that the realities of multi-thread access 
make its use as such somewhat more limited.

Apple themselves seemed to find a workaround by making UIProgressViews on iOS 
themselves responsibility for handling the KVO and threading considerations. It 
seems a rather ad hoc solution that shows a distinct issue with the API, and 
I'm curious why the update wasn't carried to NSProgressIndicator, but it works.

I think the bigger issue is: we have Progress now, and a complicated workaround 
for a different type of NSProgress replacement has two problems:

1. The optimisations won't carry across to Obj-C code.

2. It seems any update we make to Progress in the way you have would be 
somewhat hacky, and we would have a very difficult time explaining to users. 
This doesn't seem like a first class solution, no matter how creative it is. 
The value/copy semantics make the Struct Variants in the Foundation Overlay 
clean, but the fact this API is based on identity and encapsulation of state 
would make this a messy solution.

While KVO is perhaps not the best tool for this, it is the one that exists. 
Perhaps it's better to work on fixing NSProgress's flaws so everyone can 
benefit? Adding granularity controls and perhaps(?) a block/closure based 
callback option might fix the majority of the issues, and have the added 
benefit of paying dividends to everyone.

Rod

> On 23 Feb 2017, at 7:39 am, Charles Srstka  wrote:
> 
>> On Feb 22, 2017, at 2:05 PM, Rod Brown  wrote:
>> 
>> I think the big argument from you, Charles, is that the progress can become 
>> arbitrarily badly performing, depending on its use, and that could have 
>> untold effects up the chain with KVO notifications firing for minor elements 
>> of work?
>> 
>> I think this is a fair observation that the responsibility of a reporter 
>> shouldn’t be to rate limit the reporting rate for performance reasons. 
>> Rather, the observer should be able to adjust the reporting rate to 
>> something that is appropriate for the updates they wish to perform. A 50 
>> pixel progress bar only theoretically needs reporting every adjustment of 
>> 1/50 of the total work, and other reporting and updating is superfluous and 
>> simply a performance problem. But why is a data task responsible for knowing 
>> that? It seems backwards.
> 
> Very much so. It has been my opinion for a long time that the back-end code 
> is *not* the appropriate place for this stuff to be.
> 
>> Perhaps we need to examine the problem here, and how to solve that, rather 
>> than the cause? Because I agree with Tony - replacing every use of KVO on a 
>> performance basis isn’t a scalable solution.
> 
> 
> Again, I am not advocating for replacing every use of KVO. For many cases, 
> KVO is conceptually a great solution (even if I hate its implementation). For 
> binding values in the UI to properties in your view controller? It’s great. 
> For populating table views with arrays of values, or doing pretty much 
> anything Core Data-related? It’s a godsend. However, for the specific task of 
> progress reporting, IMO, it is Considered Harmful. We cannot reap the 
> benefits of it, because of the threading issue.
> 
> Can we bind our UI elements to it to avoid glue code? No, because it might be 
> updated on a background thread.
> 
> Okay, can we just be sure to wrap all updates on the main dispatch queue? No, 
> because if we add any sub-progresses to the tree that are managed by opaque 
> library code, we can’t know that the library will follow the same pattern. 
> Also: without some kind of coalescing mechanism, we’ll end up with a crazy 
> number of operations flooding the queue.
> 
> Can we fix KVO to make it fire on the main thread? No, because KVO is 
> extensively used all over the Objective-C frameworks, and making such a large 
> change to it is bound to break binary compatibility all over the place. 
> Also, the need for the -willChangeValueForKey: method to complete before 
> changing the property really hamstrings any attempts to make KVO thread-safe 
> in a sane way.
> 
> Can we add some Swift-native KVO equivalent, and have that work the way we 
> want it to? Yes, and this would be fantastic! But with Progress/NSProgress 
> being the same class instead of a custom Swift class, we’d need to keep the 
> Objective-C KVO system in place for compatibility with Objective-C code, 
> which means we’ll still have the performance drawbacks of having 
> -willChangeValueForKey: and -didChangeValueForKey: called every time we 
> update it.
> 
> Can we just write our own KVO observer, observe the progress, and forward 
> things to the main queue from there? Of course. But the UI for 

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

[Rod Brown via swift-evolution]

Charles and Tony,

Would it be more appropriate to consider suggesting that the Foundation team to 
consider adding a method of choosing their “notification granularity”, and 
avoid KVO notifications until it meets the granularity requirement, or some 
other way of minimising the reporting period of the Progress?

I think the big argument from you, Charles, is that the progress can become 
arbitrarily badly performing, depending on its use, and that could have untold 
effects up the chain with KVO notifications firing for minor elements of work?

I think this is a fair observation that the responsibility of a reporter 
shouldn’t be to rate limit the reporting rate for performance reasons. Rather, 
the observer should be able to adjust the reporting rate to something that is 
appropriate for the updates they wish to perform. A 50 pixel progress bar only 
theoretically needs reporting every adjustment of 1/50 of the total work, and 
other reporting and updating is superfluous and simply a performance problem. 
But why is a data task responsible for knowing that? It seems backwards.

Perhaps we need to examine the problem here, and how to solve that, rather than 
the cause? Because I agree with Tony - replacing every use of KVO on a 
performance basis isn’t a scalable solution.

There are also a few comments inline.

-Rod


> On 23 Feb 2017, at 6:41 am, Charles Srstka  wrote:
> 
>> On Feb 22, 2017, at 12:52 PM, Tony Parker > > wrote:
>> 
>> 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.
> 
> I am not proposing, and would never propose, replacing all KVO in the entire 
> SDK. I do, however, believe that KVO is not the correct mechanism to use for 
> progress reporting, a use case which incurs all of KVO’s drawbacks, while 
> taking advantage of none of its benefits. The main advantage of KVO is in 
> reducing glue code, allowing you to bind UI elements directly to your model 
> in IB without having to set up the connections manually. Unfortunately, since 
> UI elements must be updated from the main thread, and NSProgress is likely to 
> be used on secondary threads to avoid blocking the UI, this advantage is 
> nullified, since custom code must be written to receive KVO notifications and 
> do work on the main thread. In fact, NSProgress’s use of KVO requires you to 
> write much *more* glue code than otherwise, since the code needed to observe 
> a KVO property manually is much longer, uglier, more error-prone, and 
> generally more painful than a simple closure-based notification. Therefore, 
> the use of KVO in NSProgress strikes me as akin to using a hammer to drive in 
> a screw. There are better tools for this particular task.

I think the argument for KVO is more that this is the convention for binding UI 
to data in Obj-C and Cocoa, which would seem consistent. The question is can we 
find a way to improve this? Is that replacement, or evolution of the API?


>> 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.
> 
> It does not use KVO to update the parent, but it does cause its parent, and 
> its grandparent, and its great-grandparent, etc. all to post KVO 
> notifications going all the way back up to the root of the tree. That is a 
> lot of notifications.
> 
>> * 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.
> 
> I also agree; unfortunately, the explicit API as it currently exists is not 
> ideal for procedural tasks (see below).
> 
>> * 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) // 

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

[Rod Brown via swift-evolution]

It's an interesting implementation, from my cursory look. Inspired by the 
bridging wrappers that the rest of the Swift Overlay uses, and with a massive 
performance win in Swift-only uses. Awesome!

It still holds the fundamental oddities of NSProgress that I find weird. Like 
"current progress" always strikes me as very odd concept.

I'd be interested to see what Tony Parker and the Core Team think!

On 22 Feb 2017, at 8:22 am, Charles Srstka  wrote:

>> On Feb 21, 2017, at 2:52 PM, Rod Brown  wrote:
>> 
>> Ah sorry! To be honest, I didn't see the part about your interoperability 
>> with NSProgress trees!
>> 
>> That said, it does seem to be a hacky solution. A better solution would be a 
>> backing NSProgress that is linked and lazily created when casts occur, 
>> perhaps? This would map far cleaner to current bridging techniques in the 
>> Swift Overlay?
>> 
>> Sorry, I haven't looked at how your internal implementation is done. I'm 
>> just going off the description in your email. I'm curious to get involved in 
>> creating a better progress API if we can find a way that is superior and 
>> still cleanly interoperates.
> 
> Agreed that it’s hacky, which is why I tried to do my best to separate the 
> Objective-C compatibility crud from the rest of the code, so it can be easily 
> yanked and replaced with something better if we think of one.
> 
> With that said, the way I’m currently doing it is inspired by the way the 
> Data<->NSData bridging works. My class, CSProgress, has a “backing” property. 
> This property stores an enum with two cases, one for Swift, and one for 
> Objective-C. The Swift backing contains the basic implementation, and the 
> Objective-C one wraps an NSProgress, forwarding all changes to it and 
> registering for KVO notifications on it for the purpose of keeping its own 
> clients notified. Each case contains an associated type that handles all the 
> primitives. There’s also a private NSProgress subclass (unimaginatively named 
> “BridgedNSProgress”) that wraps a CSProgress, and forwards NSProgress changes 
> to it.
> 
> What you get if you:
> 
> - create a CSProgress from scratch, or from another CSProgress: A CSProgress, 
> with the Swift backing.
> 
> - bridge an NSProgress to a CSProgress: If the NSProgress was a 
> BridgedNSProgress, you get the CSProgress it was wrapping. Otherwise, you get 
> a CSProgress with the Objective-C backing.
> 
> - bridge a CSProgress to an NSProgress: If the CSProgress uses the 
> Objective-C backing, you get the NSProgress it was wrapping. Otherwise, you 
> get a BridgedNSProgress wrapping the CSProgress.
> 
> If no bridging occurs and you’re using CSProgress all the way down, no 
> NSProgress objects get involved.
> 
> Charles
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

Ah sorry! To be honest, I didn't see the part about your interoperability with 
NSProgress trees!

That said, it does seem to be a hacky solution. A better solution would be a 
backing NSProgress that is linked and lazily created when casts occur, perhaps? 
This would map far cleaner to current bridging techniques in the Swift Overlay?

Sorry, I haven't looked at how your internal implementation is done. I'm just 
going off the description in your email. I'm curious to get involved in 
creating a better progress API if we can find a way that is superior and still 
cleanly interoperates.

Rod

> On 22 Feb 2017, at 7:43 am, Rod Brown via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> My concern regarding a new class in the overlay is interoperability.
> 
> With a lot of things in the Swift Overlay, identity isn't relevant. For 
> example, we turn a lot of Objective-C classes into structs because their 
> identity is not relevant, and they should be copied anyway, so it makes sense 
> to let the Swift world be different.
> 
> Progress however has innate identity for tracking purposes. Separate 
> Progresses for Swift and Obj-C causes problems. If I want to pass my progress 
> to an Obj-C API, I can't hand it my Swift progress, I must hand it an Obj-C 
> one.
> 
> I can't foresee how a new Progress will integrate cleanly with existing 
> NSProgress API. Is it worthwhile creating a separate class that is 
> incompatible with Obj-C Foundation?
> 
>> On 22 Feb 2017, at 1:40 am, Charles Srstka <cocoa...@charlessoft.com> wrote:
>> 
>>> On Feb 21, 2017, at 5:24 AM, Rod Brown <rodney.bro...@icloud.com> wrote:
>>> 
>>> I applaud the idea. I too find the (NS)Progress API to be very low quality. 
>>> It seems a vestige of an earlier time when Cocoa was young and APIs that 
>>> seem like they should be simple, just... aren't. I would love to see a much 
>>> better API developed.
>>> 
>>> I'm curious how this idea of developing something from the ground up works 
>>> with Apple's preferred idea of using Swift to bring Foundation forward.
>> 
>> There are several ground-up replacements in the Swift overlay already, if 
>> you look at the various value types that have been introduced to replace 
>> various NS classes (granted, some of them call through to the underlying 
>> Foundation API for their implementation, but others don’t). As long as we 
>> eventually end up supporting NSProgress’s interface, something like this 
>> should be possible to drop in as long as we do it before the ABI stability 
>> lockdown.
>> 
>> In any event, I BSD-licensed the code, so it’s free to use whether or not 
>> Apple ends up using it, so feel free to give it a try (for performance 
>> testing, be sure to compile in Release mode, as it does much better with the 
>> optimizations on). If you find any bugs or problems, please let me know.
>> 
>> Thanks,
>> 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: Much better-performing, Swift-native Progress replacement

[Rod Brown via swift-evolution]

My concern regarding a new class in the overlay is interoperability.

With a lot of things in the Swift Overlay, identity isn't relevant. For 
example, we turn a lot of Objective-C classes into structs because their 
identity is not relevant, and they should be copied anyway, so it makes sense 
to let the Swift world be different.

Progress however has innate identity for tracking purposes. Separate Progresses 
for Swift and Obj-C causes problems. If I want to pass my progress to an Obj-C 
API, I can't hand it my Swift progress, I must hand it an Obj-C one.

I can't foresee how a new Progress will integrate cleanly with existing 
NSProgress API. Is it worthwhile creating a separate class that is incompatible 
with Obj-C Foundation?

>> On 22 Feb 2017, at 1:40 am, Charles Srstka  wrote:
>> On Feb 21, 2017, at 5:24 AM, Rod Brown  wrote:
>> 
>> I applaud the idea. I too find the (NS)Progress API to be very low quality. 
>> It seems a vestige of an earlier time when Cocoa was young and APIs that 
>> seem like they should be simple, just... aren't. I would love to see a much 
>> better API developed.
>> 
>> I'm curious how this idea of developing something from the ground up works 
>> with Apple's preferred idea of using Swift to bring Foundation forward.
> 
> There are several ground-up replacements in the Swift overlay already, if you 
> look at the various value types that have been introduced to replace various 
> NS classes (granted, some of them call through to the underlying Foundation 
> API for their implementation, but others don’t). As long as we eventually end 
> up supporting NSProgress’s interface, something like this should be possible 
> to drop in as long as we do it before the ABI stability lockdown.
> 
> In any event, I BSD-licensed the code, so it’s free to use whether or not 
> Apple ends up using it, so feel free to give it a try (for performance 
> testing, be sure to compile in Release mode, as it does much better with the 
> optimizations on). If you find any bugs or problems, please let me know.
> 
> Thanks,
> Charles
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

I applaud the idea. I too find the (NS)Progress API to be very low quality. It 
seems a vestige of an earlier time when Cocoa was young and APIs that seem like 
they should be simple, just... aren't. I would love to see a much better API 
developed.

I'm curious how this idea of developing something from the ground up works with 
Apple's preferred idea of using Swift to bring Foundation forward.

-Rod

> On 18 Feb 2017, at 6:48 am, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Feb 17, 2017, at 1:42 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> - Much better performance. In my testing, updating the 
>> completedUnitProperty, with something observing it, takes 1.04 seconds on my 
>> 2013 Retinabook, compared with NSProgress’s 52.91 seconds (58.53 seconds if 
>> an autorelease pool is used). This frees back-end code from the 
>> responsibility of being adulterated with what is effectively UI code in 
>> order to determine when the progress object should be updated.
> 
> This should have said “updating the completedUnitProperty one million times, 
> with something observing it.” I eagerly await the implementation of our new 
> forum, hopefully with an edit feature, with bated breath.
> 
> 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] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[Rod Brown via swift-evolution]

> What is your evaluation of the proposal?
It’s clearly a concern and one that should be addressed.

A lot of people have bought up the didSet {} property observers are not called 
when things are set here, either. This is true, but unlike property observers, 
these are attributes, and I don’t know of anywhere else where an @attribute 
works in some cases and not in another. It is understandable that people think 
@NSCopying is implemented with compiler magic that should work everywhere, 
rather than built as part of the setter as it currently is, and thus causes 
confusion.

Like others have commented, I am concerned about how our solution works with 
future plans about making NSCopying a property behaviour. Doug Gregor has 
commented that he believes it should be compiler magic, and I respect that 
opinion. I would like the Core Team to ensure that they believe it is entirely 
compatible and in the spirit of Property Behaviours before the compiler magic 
is added, though, if Property Behaviours are still seriously on the cards for 
the future.

If compiler magic is decided against, I think this is a clear spot where there 
should be a warning, and a proposed fixit.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. This is a confusing and easily missed part of the language. While it is 
currently understood that didSet and willSet are not called, it is not clear to 
developers that @NSCopying falls into that same group, and have not noticed it 
anywhere in documentation.

> Does this proposal fit well with the feel and direction of Swift?
I think adding compiler magic is somewhat in opposition to the general trend to 
reduce said magic, but a solution here seems necessary as the current lack of 
clarity is against the 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?
N/A

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading of the proposal, and involved in the initial discussions 
surrounding this issue.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Rod Brown via swift-evolution]

My 2c:

+1 to reverting private to the Swift 2 meaning and deprecating or using 
fileprivate as an alias for private.

As a framework developer I am constantly deciding backward and forwards to go 
private only to realise that my embracing extensions makes it impossible to 
allow internal properties in private as we don't support stored properties in 
extensions. And, without it, I think private is overly hamstrung when defining 
classes and types with extensions. There is no difference to the compilation 
beyond a rule that the compiler enforces, but can optimise anyway. In which 
case, it is purely communicative, and is therefore practically useless because 
I can't declare the property the method uses in that extension anyway. And 
littering my code with the ugly fileprivate marker is just an annoying 
inconvenience.

+1 also to add in something like 'protected'. It's a hole in the language where 
subclasses may have reasons to access but other types have no business touching.

> On 18 Feb 2017, at 2:38 pm, Jonathan Hull via swift-evolution 
>  wrote:
> 
> My ideal scenario:
> 
> 1) Go back to Swift 2 meaning of private
> 
> 2) Add the ‘hidden’ axis I talked about in another thread.  
> 
> This will provide the capabilities of protected + friend (and allow 
> extensions organized across files) using a consistent file-based approach 
> that is easy to reason about.  It also neatly avoids the issues mentioned in 
> the blog post.
> 
> Thanks,
> Jon
> 
>> On Feb 16, 2017, at 10:47 PM, Jose Cheyo Jimenez via swift-evolution 
>>  wrote:
>> 
>> https://developer.apple.com/swift/blog/?id=11
>> 
>> 
>> 
>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
>>>  wrote:
>>> 
>>> How about removing fileprivate, getting Swift 2 meaning of private (as most 
>>> people here now suggest) and add additional @protected annotation for those 
>>> who want a more fine-grained solution:
>>> 
>>> @protected private - members accessable only from the class/struct/enum/... 
>>> and their extensions within the file
>>> 
>>> @protected internal - again, but you can access it even from extensions and 
>>> subclasses outside of the file within the entire module.
>>> 
>>> @protected public/open - the same as above, but outside the modules.
>>> 
>>> To me, this way most people here will be happy:
>>> 
>>> - those wishing the access control gets simplified - it in fact does, you 
>>> don't need to use @protected, if you don't want to/need to.
>>> - those who need a fine-grained solution, here it is.
>>> 
>>> 
>>> 
 On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
  wrote:
 
 
 
 Sent from my iPad
 
>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> 
>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> While we’re bikeshedding, I’m going to add my two cents. Hold on to your 
>> hat because this might be controversial here.
>> 
>> I think both ‘private’ and ‘fileprivate’ are unnecessary complications 
>> that only serve to clutter the language.
>> 
>> It would make a lot more sense to just have internal and public only. No 
>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Eh, I've used `private` to keep myself honest in terms of going through 
> some book-keeping functions instead of directly accessing a property.
 
 This is exactly the kind of thing I like it for and why I hope we might be 
 able to keep scoped access even if it gets a new name that ends up as 
 awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
 
> 
> - Dave Sweeris
> ___
> 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
> 
> ___
> 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] Bridging nil to Objective-C Primitives

[Rod Brown via swift-evolution]

I think the biggest problem we're going to face with this one is changes to 
Objective-C are out of scope for Swift Evolution. Apple tend to be the ones in 
control of the development of new Objective-C features and compatibility 
because they control the compiler.

That said, as a request to Apple for this change, I think it's a reasonable 
idea for Ints, but I'm not sure of its feasibility for other types. Could the 
API be descriptive enough to cover enough types? (Eg CGRectNull)


> On 14 Feb 2017, at 2:33 pm, Jeff Kelley via swift-evolution 
>  wrote:
> 
> Hi all,
> 
>   I don’t have a formal proposal written up yet, but in my continued 
> quest to make better-annotated Objective-C code, I had an idea for bridging 
> nil with primitives. Since in Objective-C we often use constant values to 
> represent invalid values or nil, the most obvious being NSNotFound, could we 
> use that as a shorthand for nil? Something like this for NSArray:
> 
> - (NSUInteger NS_SWIFT_NIL(NSNotFound))indexOfObject:(ObjectType)anObject;
> 
>   This is a little verbose, so it could also work with a typedef:
> 
> typedef NSUInteger NS_SWIFT_NIL(NSNotFound) NSArrayIndex;
> - (NSArrayIndex)indexOfObject:(ObjectType)anObject;
> 
>   This would change the existing Swift interface to return an Int? 
> instead of an Int. I see this as working both ways—converting these values to 
> nil when returning from Objective-C to Swift, and sending these values 
> instead of nil when Swift calls into Objective-C code.
> 
>   Is this worth writing up a proposal for? Is another, better method 
> already in someone’s mind?
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
> ___
> 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] Overriding protocol default implementation

[Rod Brown via swift-evolution]

I see your point. I think the core issue here is customizability vs safety.

Allowing users to perform actions in these functions that change the behaviour 
of a protocol is potentially dangerous, and therefore Swift as a safe language 
disallows it.

This comes at the cost of being able to override the function dynamically and 
provide a different implementation that is perhaps more appropriate. This 
limits Swift flexibility.

Depending on where you come down on this, it may be "too conservative". Things 
can only be safe to a certain level and if we keep optimising for safety over 
functionality, perhaps we'll restrict Swift too much for it to be a useful 
language. Or perhaps it's a good trade. The decision regarding "closed by 
default" also had considerations like retrospectively "finalising" or "opening" 
APIs that made those decisions a little easier.

> On 11 Feb 2017, at 3:32 pm, Xiaodi Wu  wrote:
> 
>> On Fri, Feb 10, 2017 at 9:54 PM, Rod Brown  wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 11 Feb 2017, at 2:20 pm, Xiaodi Wu  wrote:
>>> 
 On Fri, Feb 10, 2017 at 6:59 PM, Rod Brown  
 wrote:
 I don't believe these two worlds are in conflict at all.
 
 We currently have the default only state (without overrides), plus a 
 conflict. We would simply be adding "override" functionality in part to 
 clear the conflict.
 
 With POP the idea is that the protocol, in knowing about how it is 
 constituted, has a clear pattern for how it implements its behaviours. 
 Therefore you can leverage the protocol to bear the brunt of the work, 
 just as we do now.
 
 The additional tweak to the design of protocols is to allow a user to 
 define their own implementation where the default is not appropriate, or 
 is incomplete for the use case.
>>> 
>>> I think I've written a poor explanation of my point. In Swift, it is the 
>>> library _author_, not the _user_, who gets the final say as to the upper 
>>> limits on what users can do with the author's types, by using modifiers 
>>> such as `final` and `open` (or the lack thereof). This has been the subject 
>>> of vehement opposition but, nonetheless, it is a clear and opinionated 
>>> decision on the part of the language. What you are critiquing as a bug is 
>>> regarded as a feature. That is to say, it is a way for the author of a 
>>> protocol extension method to deny to the user a customization point (in 
>>> other words, to disallow the outright overriding of the "default" behavior).
>>>  
 This doesn't work against POP - it simply observes that implementations at 
 times may need to be customised to the use case, and allows that, as an 
 optional override.
>>> 
>>> Again, the status quo in Swift is that it is up to the protocol's author to 
>>> determine which methods are overridable by the user and which are not. The 
>>> idea is that protocol extension methods that are not protocol requirements 
>>> are the intended way for disallowing such overriding.
>>> 
>>> As to its practical use: this guarantees that if protocol `P` has a method 
>>> `foo()`, it is possible to invoke `foo()` on an instance of existential 
>>> type `P` knowing that you will invoke the intended method. A concrete type 
>>> `T` that conforms to `P` may have its own `foo()` with totally different 
>>> semantics. After all, if `foo()` is not a protocol requirement, then 
>>> conforming types can have their own `foo()` do anything at all, with the 
>>> collision in name being mere coincidence and no guarantee of similar 
>>> semantics. And, with extensions, some third party can implement such a 
>>> `foo()` on `T` that the library author has no way of reasoning about. By 
>>> having a "shadowing" feature for `foo()`, I can know that no matter how 
>>> anyone in the future extends type `T`, I will invoke the intended `foo()` 
>>> with the right semantics on an instance of existential type `P`.
>>>  
 It's clear people are trying to do this already because they already have 
 overrides that are causing this conflict, and thus we are having the 
 discussion.
>>> 
>>> It sounds like what you are saying is that users of libraries are trying to 
>>> "override" protocol extension methods that authors of libraries have 
>>> designed not to be overridden. That this causes problems is, afaict, the 
>>> intended consequence of this feature and not an overlooked bug. For maximum 
>>> flexibility, however, Swift allows you to "shadow" the non-overridable 
>>> method with an identically named method of your own design that can have 
>>> different semantics.
>> 
>> If the intent is to restrict users and to provide the power to the author of 
>> the protocol, it appears not just opinionated, but arrogant.
>> 
>> As software developers, we need to work together to provide solutions to use 
>> cases. This includes not 

Re: [swift-evolution] Overriding protocol default implementation

[Rod Brown via swift-evolution]

Sent from my iPhone

> On 11 Feb 2017, at 2:20 pm, Xiaodi Wu  wrote:
> 
>> On Fri, Feb 10, 2017 at 6:59 PM, Rod Brown  wrote:
>> I don't believe these two worlds are in conflict at all.
>> 
>> We currently have the default only state (without overrides), plus a 
>> conflict. We would simply be adding "override" functionality in part to 
>> clear the conflict.
>> 
>> With POP the idea is that the protocol, in knowing about how it is 
>> constituted, has a clear pattern for how it implements its behaviours. 
>> Therefore you can leverage the protocol to bear the brunt of the work, just 
>> as we do now.
>> 
>> The additional tweak to the design of protocols is to allow a user to define 
>> their own implementation where the default is not appropriate, or is 
>> incomplete for the use case.
> 
> I think I've written a poor explanation of my point. In Swift, it is the 
> library _author_, not the _user_, who gets the final say as to the upper 
> limits on what users can do with the author's types, by using modifiers such 
> as `final` and `open` (or the lack thereof). This has been the subject of 
> vehement opposition but, nonetheless, it is a clear and opinionated decision 
> on the part of the language. What you are critiquing as a bug is regarded as 
> a feature. That is to say, it is a way for the author of a protocol extension 
> method to deny to the user a customization point (in other words, to disallow 
> the outright overriding of the "default" behavior).
>  
>> This doesn't work against POP - it simply observes that implementations at 
>> times may need to be customised to the use case, and allows that, as an 
>> optional override.
> 
> Again, the status quo in Swift is that it is up to the protocol's author to 
> determine which methods are overridable by the user and which are not. The 
> idea is that protocol extension methods that are not protocol requirements 
> are the intended way for disallowing such overriding.
> 
> As to its practical use: this guarantees that if protocol `P` has a method 
> `foo()`, it is possible to invoke `foo()` on an instance of existential type 
> `P` knowing that you will invoke the intended method. A concrete type `T` 
> that conforms to `P` may have its own `foo()` with totally different 
> semantics. After all, if `foo()` is not a protocol requirement, then 
> conforming types can have their own `foo()` do anything at all, with the 
> collision in name being mere coincidence and no guarantee of similar 
> semantics. And, with extensions, some third party can implement such a 
> `foo()` on `T` that the library author has no way of reasoning about. By 
> having a "shadowing" feature for `foo()`, I can know that no matter how 
> anyone in the future extends type `T`, I will invoke the intended `foo()` 
> with the right semantics on an instance of existential type `P`.
>  
>> It's clear people are trying to do this already because they already have 
>> overrides that are causing this conflict, and thus we are having the 
>> discussion.
> 
> It sounds like what you are saying is that users of libraries are trying to 
> "override" protocol extension methods that authors of libraries have designed 
> not to be overridden. That this causes problems is, afaict, the intended 
> consequence of this feature and not an overlooked bug. For maximum 
> flexibility, however, Swift allows you to "shadow" the non-overridable method 
> with an identically named method of your own design that can have different 
> semantics.

If the intent is to restrict users and to provide the power to the author of 
the protocol, it appears not just opinionated, but arrogant.

As software developers, we need to work together to provide solutions to use 
cases. This includes not understanding what some use case may be. But instead, 
the consistent argument here has been that software should be as it is 
designed, to hell with the users of the frameworks who may have an unknown use 
case.

This therefore has created the shadow problem, where people implementing a 
protocol end up colliding with the same name, and must make casts back.

Why can't we make an adjustment and allow protocol implementers to define the 
cases where the protocol action is inappropriate.

I believe this argument stems back to the closed-by-default argument on classes 
with "public" and shows a concerning trend in how Swift is being developed. We 
cannot look at Swift purely from the perspective of the Standard Library, or 
one framework, or one implementer. It is how we coordinate between framework 
authors that we end up creating a unified system.

It should never be a feature to make users of frameworks fight with writers of 
frameworks. That's just absurd.

>  
>> In this case, I don't see overriding the protocol "default" as working 
>> against this world - I think it clarifies it.
>> 
>> Rod
> 
___
swift-evolution mailing list

Re: [swift-evolution] Overriding protocol default implementation

[Rod Brown via swift-evolution]

I don't believe these two worlds are in conflict at all.

We currently have the default only state (without overrides), plus a conflict. 
We would simply be adding "override" functionality in part to clear the 
conflict.

With POP the idea is that the protocol, in knowing about how it is constituted, 
has a clear pattern for how it implements its behaviours. Therefore you can 
leverage the protocol to bear the brunt of the work, just as we do now.

The additional tweak to the design of protocols is to allow a user to define 
their own implementation where the default is not appropriate, or is incomplete 
for the use case. This doesn't work against POP - it simply observes that 
implementations at times may need to be customised to the use case, and allows 
that, as an optional override. It's clear people are trying to do this already 
because they already have overrides that are causing this conflict, and thus we 
are having the discussion.

In this case, I don't see overriding the protocol "default" as working against 
this world - I think it clarifies it.

Rod

> On 11 Feb 2017, at 11:39 am, Xiaodi Wu  wrote:
> 
> In a vacuum I'd have thought your idea to be superior in terms of consistency 
> and user-friendliness. In that world, protocols are strictly a list of 
> requirements and (optionally) defaults for those requirements.
> 
> In _this_ world, I think the idea is that protocols provide both behaviors 
> and customization points; not all customization points have default 
> behaviors, of course, but also not all behaviors are customizable defaults 
> (what we're discussing here). I can see how that's more sophisticated but 
> also more tricky. I don't see how such a model can be rolled back now that we 
> already have it, though.
>> On Fri, Feb 10, 2017 at 17:50 Rod Brown  wrote:
>> I agree this is a very... tricky part of Swift, and that many have stated it 
>> is expected behaviour.
>> 
>> I think this is fundamentally incorrect from a design standpoint with the 
>> concept of a protocol as an agreed interface, rather than an agreed 
>> implementation. By adding a Protocol Extensions, we have started to mix 
>> implementation with interface, which is understandable as those with the 
>> same interface often conform to the same behaviour.
>> 
>> That said, I think if my conforming to the protocol means I need to do extra 
>> work for my specific implementation case, then letting someone circumvent 
>> that by simply referring to me as the protocol is both dangerous and lets 
>> the protocol's extension implementation have mixed priority. My unique use 
>> case should be more important than the implementation that makes sense for 
>> the generic case.
>> 
>> My view is protocol extensions should a "default", nothing more. If you 
>> implement, you override. This behaviour preserves protocols as an agreed 
>> interface with additional default logic rather than a conflicting set of 
>> implementations.
>> 
>> I think I've stated this view before and been shot down, but I'm not sure.
>> 
>> Rod
>> 
>>> On 11 Feb 2017, at 9:54 am, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Robert, this is a tricky part of Swift. I raised the same point in my very 
>>> first email to this list a year and a half ago, and the response was that 
>>> no default/implement/override keyword was desired and that this behavior is 
>>> intentional. It has since been raised multiple times on this list to the 
>>> same conclusion.
>>> 
>>> The idea here is that protocol extension methods that are not protocol 
>>> requirements are statically dispatched and can be shadowed but not 
>>> overridden. If you read through some of the Swift-Evolution proposals, 
>>> you'll see that there are several designs that actually seek to take 
>>> advantage of this behavior. I can't recall which of these were actually 
>>> implemented in that way, but it does indeed show that the behavior has its 
>>> uses.
>>> 
>>> Many have suggested some sort of keyword to distinguish overriding and 
>>> shadowing. However, every such proposed design thus far breaks retroactive 
>>> conformance in some subtle way. It's hard to search the archives, but there 
>>> are hundreds of emails on this topic.
>>> 
>>> 
>>> On Fri, Feb 10, 2017 at 15:57 Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> I remain very unconvinced that type casting should change code being 
>>> executed...
>>> 
>>> Sent from my iPhone
>>> 
 On 10 Feb 2017, at 21:04, David Waite via swift-evolution 
  wrote:
 
 
>> On Feb 10, 2017, at 12:41 PM, Robert Ryan via swift-evolution 
>>  wrote:
> 
> I’m hard pressed to think of a situation where you’d want the current 
> Swift 3 behavior of the first example (where you can override a protocol 
> default implementation but you only want that 

Re: [swift-evolution] Overriding protocol default implementation

[Rod Brown via swift-evolution]

I agree this is a very... tricky part of Swift, and that many have stated it is 
expected behaviour.

I think this is fundamentally incorrect from a design standpoint with the 
concept of a protocol as an agreed interface, rather than an agreed 
implementation. By adding a Protocol Extensions, we have started to mix 
implementation with interface, which is understandable as those with the same 
interface often conform to the same behaviour.

That said, I think if my conforming to the protocol means I need to do extra 
work for my specific implementation case, then letting someone circumvent that 
by simply referring to me as the protocol is both dangerous and lets the 
protocol's extension implementation have mixed priority. My unique use case 
should be more important than the implementation that makes sense for the 
generic case.

My view is protocol extensions should a "default", nothing more. If you 
implement, you override. This behaviour preserves protocols as an agreed 
interface with additional default logic rather than a conflicting set of 
implementations.

I think I've stated this view before and been shot down, but I'm not sure.

Rod

> On 11 Feb 2017, at 9:54 am, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Robert, this is a tricky part of Swift. I raised the same point in my very 
> first email to this list a year and a half ago, and the response was that no 
> default/implement/override keyword was desired and that this behavior is 
> intentional. It has since been raised multiple times on this list to the same 
> conclusion.
> 
> The idea here is that protocol extension methods that are not protocol 
> requirements are statically dispatched and can be shadowed but not 
> overridden. If you read through some of the Swift-Evolution proposals, you'll 
> see that there are several designs that actually seek to take advantage of 
> this behavior. I can't recall which of these were actually implemented in 
> that way, but it does indeed show that the behavior has its uses.
> 
> Many have suggested some sort of keyword to distinguish overriding and 
> shadowing. However, every such proposed design thus far breaks retroactive 
> conformance in some subtle way. It's hard to search the archives, but there 
> are hundreds of emails on this topic.
> 
> 
> On Fri, Feb 10, 2017 at 15:57 Goffredo Marocchi via swift-evolution 
>  wrote:
> I remain very unconvinced that type casting should change code being 
> executed...
> 
> Sent from my iPhone
> 
>> On 10 Feb 2017, at 21:04, David Waite via swift-evolution 
>>  wrote:
>> 
>> 
 On Feb 10, 2017, at 12:41 PM, Robert Ryan via swift-evolution 
  wrote:
>>> 
>>> I’m hard pressed to think of a situation where you’d want the current Swift 
>>> 3 behavior of the first example (where you can override a protocol default 
>>> implementation but you only want that override used when you reference the 
>>> class itself, but not when you reference the protocol as a type).
>> 
>> Thats easy - the extension methods are not related to protocol conformance. 
>> The type implementing the protocol may not even know there *is* an extension 
>> method, or that method could be added either later or by yet other third 
>> party code. 
>> 
>> As such, the type may not be overriding the extension method at all - the 
>> protocol-implementing types may have their own method with a conflicting 
>> name doing similar (or not) logic. It would not be appropriate for someone 
>> calling the protocol extension method to get different behavior simply 
>> because a type declared a similar named method.
>> 
>> In other words, without the method being declared on the protocol, override 
>> behavior between an extension and type would be similar to unsafe “duck” 
>> typing. There is no agreement by the type that they are conforming to 
>> extension behavior, only to the protocol’s behavior.
>> 
>> IMHO the issue actually goes the other way
>>  - there is no way to indicate that an extension method to a protocol is 
>> meant to declare ‘default’ behavior, e.g. represents a partial 
>> implementation for types conforming to the protocol.
>>  - there is no way to indicate that a type property/method ‘implements’ the 
>> functionality of a protocol. 
>> 
>> The lack of a distinction between extensions declaring random methods and 
>> declaring default implementation behavior is obviously an element of 
>> confusion. Both points become an issue if the protocol method signatures 
>> ever changes - the extension could no longer be providing a default 
>> implementation, or a type may silently switch from their own implementation 
>> to the default implementation provided by the extension.
>> 
>> -DW
>> 
>>> If there are such examples, then add a “build setting” to allow you to turn 
>>> off this warning, or add some keyword to the declaration of the default 
>>> implementation that 

Re: [swift-evolution] Initializers

[Rod Brown via swift-evolution]

Dependency Injection does sort out this case, you're right.

One case it doesn't fix is where your initialised value depends on something 
within your superclass to be created first to derive your initialising value.

class MyBaseClass {
let myStateManager: StateManager

init() {
// sets up stateManager
}
}

class MySubclass: MyBaseClass {
 var myStateDerivedProperty: Int!

 override init() {
 super.init()

 myStateDerivedProperty = // derive state from myStateManager
 }
}

In this case, the writer cannot initialise their state derived properties until 
the superclass has completed its initialization because it is waiting on the 
stateManager to derive its initial state.

This is a somewhat contrived example but I've actually found myself with 
similar patterns where I use other frameworks, where the default is either not 
defined in documentation or the object I require as part of initialising the 
property does not exist until after the initialisation.

Rod

> On 5 Feb 2017, at 4:04 am, Jean-Daniel <mail...@xenonium.com> wrote:
> 
> 
>> Le 4 févr. 2017 à 16:52, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org> a écrit :
>> 
>> Hi Joe,
>> 
>> I think this comes back to the idea that a lot of people in the wider Swift 
>> community hold that Implicitly Unwrapped Optionals are “bad” and 
>> “discouraged", and therefore shouldn’t be used. There seems to have been 
>> much pushback on Implicitly Unwrapped Optionals in the Swift 3 timeframe, to 
>> try and remove them as much as possible.
>> 
>> I definitely see this as a valuable use for them. While an integer is an 
>> extremely lightweight example of this, when it could include creating entire 
>> object graphs multiple times due to initialiser behaviour, or because you 
>> won’t know the correct state of a variable until *after* initialisation has 
>> occurred on the superclass, this is a valuable example where IUOs are really 
>> the only alternative for performance or correctness reasons.
> 
> IUO are useful to workaround poorly designed class. As already said, you 
> example could be rewrite like follow to avoid any useless computation
> 
> class A {
>   let x: Int
>   init(_ x: Int = 3) {
>   self.x = x
>   }
> }
> 
> class B : A {
>   override init() {
>   …
>   super.init(1)
>   }
> }
> 
> No useless initialization of x, and no need to use IUO. Is it a suffisent 
> reason to keep them in the language ? Anyway, as long as we need them to 
> usefully use IBOutlet, I’m pretty sure they are not going anywhere.
> 
> 
>> 
>> Perhaps this is an area where the Swift Core Team could provide guidance to 
>> the community? Do the Core Team see IUOs as “bad” outright, and destined to 
>> go away when possible, or are they a tool with specific uses that look to be 
>> supported into the future?
>> 
>> - Rod
>> 
>> 
>> 
>>>> On 4 Feb 2017, at 5:40 am, Joe Groff via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 
>>>> On Jan 31, 2017, at 3:52 AM, Victor Petrescu via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 4. Joe Groff says there is already a backdoor of sorts ("There already is 
>>>> a backdoor of sorts. This is one of the intended use cases for 
>>>> implicitly-unwrapped optionals. If you don't want to be hassled by DI, 
>>>> declare a property as T! type, and it will be implicitly initialized to 
>>>> nil, and trap if you try to use it as an unwrapped T without initializing 
>>>> it first."): I'm assuming by T you mean generics. If that is true that may 
>>>> already solve the problem but... generics are a new concept for me (first 
>>>> time I really encountered and used them is now, in swift) but to my 
>>>> understanding their role is to deal with cases you don't know the type. 
>>>> Can you please show how to use this to work around the posted issue?
>>>> 
>>>> Sidenote: There may be another workaround using optionals (Joe Groff 
>>>> answer made it pop in my mind) but... I know the type and value for the 
>>>> variable, it is not optional or nil. Unwrapping each time someone needs it 
>>>> does not look like the best solution to me.
>>> 
>>> You don't need to understand generics to use implicitly-unwrapped 
>>> optionals. By `T!` I was referring to the syntax used to represent them; 
>>> you would write Int! or Strin

Re: [swift-evolution] Initializers

[Rod Brown via swift-evolution]

Hi Joe,

I think this comes back to the idea that a lot of people in the wider Swift 
community hold that Implicitly Unwrapped Optionals are “bad” and “discouraged", 
and therefore shouldn’t be used. There seems to have been much pushback on 
Implicitly Unwrapped Optionals in the Swift 3 timeframe, to try and remove them 
as much as possible.

I definitely see this as a valuable use for them. While an integer is an 
extremely lightweight example of this, when it could include creating entire 
object graphs multiple times due to initialiser behaviour, or because you won’t 
know the correct state of a variable until *after* initialisation has occurred 
on the superclass, this is a valuable example where IUOs are really the only 
alternative for performance or correctness reasons.

Perhaps this is an area where the Swift Core Team could provide guidance to the 
community? Do the Core Team see IUOs as “bad” outright, and destined to go away 
when possible, or are they a tool with specific uses that look to be supported 
into the future?

- Rod



> On 4 Feb 2017, at 5:40 am, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jan 31, 2017, at 3:52 AM, Victor Petrescu via swift-evolution 
>> > wrote:
>> 
>> 4. Joe Groff says there is already a backdoor of sorts ("There already is a 
>> backdoor of sorts. This is one of the intended use cases for 
>> implicitly-unwrapped optionals. If you don't want to be hassled by DI, 
>> declare a property as T! type, and it will be implicitly initialized to nil, 
>> and trap if you try to use it as an unwrapped T without initializing it 
>> first."): I'm assuming by T you mean generics. If that is true that may 
>> already solve the problem but... generics are a new concept for me (first 
>> time I really encountered and used them is now, in swift) but to my 
>> understanding their role is to deal with cases you don't know the type. Can 
>> you please show how to use this to work around the posted issue?
>> 
>> Sidenote: There may be another workaround using optionals (Joe Groff answer 
>> made it pop in my mind) but... I know the type and value for the variable, 
>> it is not optional or nil. Unwrapping each time someone needs it does not 
>> look like the best solution to me.
> 
> You don't need to understand generics to use implicitly-unwrapped optionals. 
> By `T!` I was referring to the syntax used to represent them; you would write 
> Int! or String! or whatever in your code. For your example, this would let 
> you avoid having to invoke super.init() before resetting `x`:
> 
> class A {
>  var x:Int! // Int! is nil by default
> }
> 
> class B : A {
> override init() {
>  x = 2 // So we can set it here w/o super.init first
> }
> }
> 
> print(B().x + 1) // and we don't need to explicitly unwrap it to use it, 
> unlike `Int?`
> 
> You're giving up the static guarantee that `x` has a value, so you'll get a 
> runtime error if you try to use it before it's initialized, but that's the 
> same situation you have in Java, where dereferencing an uninitialized object 
> reference gives an NPE. Whether you want the hard guarantee that `x` is never 
> optional from the compiler, or the convenience of leaving that up to runtime 
> checks, is a call you have to make; Swift defaults to the strong guarantee, 
> but implicitly-unwrapped optional types like Int! are intended to give you an 
> out if the static model is too strict or inefficient.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] @NSCopying currently does not affect initializers

[Rod Brown via swift-evolution]

I agree that there is an issue here.

While I understand that the initialiser avoids the full setter for direct 
access, I would expect the attribute to mean that the substituted direct access 
still applied the attribute you marked the API with. I would consider the fact 
that it doesn't work as a dangerous gap in the API.

It is also concerning if we consider how this will work with Property 
Behaviours that are planned for Swift in the future. If we made NSCopying a 
property behaviour, the direct access would mean it too would not be invoked at 
initial access so I'm not sure how the best way to get around this is - should 
we do compiler magic to copy in the initialiser, or should we warn if we don't 
detect a call to copy() or copy(with:) in the initialiser?

I think we at least need to do something here. It's a very convoluted piece of 
logic to say the @NSCopying attribute doesn't work in an initialiser and it's 
hardly intuitive despite the fair reasoning.

Rod

> On 29 Jan 2017, at 4:47 pm, Torin Kwok via swift-evolution 
>  wrote:
> 
> Yep, I also admit the design of forbidding calling a setter before full
> class initialization is reasonable and what's really annoying is the
> inconsistency.
> 
> However, making @NSCopying attribute not subjects to the fact that
> setters would not be invoked in initializers perhaps is viable too. In
> the other words, assigning a value to a property whether or not by
> calling a setter has no influence on whether @NSCopying semantic'd work:
> copying should always take place after a property has been declared as
> @NSCopying.
> 
> Jean-Daniel writes:
> 
>>> Le 28 janv. 2017 à 05:34, Torin Kwok via swift-evolution 
>>>  a écrit :
>>> 
>>> Hello guys,
>>> 
>>> Note: This issue has been originally presented inswift-usersmailling list 
>>> .
>>>  And then I post it again here at the suggestion 
>>> 
>>>  of Jordan Rose:
>>> 
>>> It might be reasonable to change this behavior, but it probably deserves a 
>>> bit of discussion on swift-evolution; it's not 100%, for-sure a bug.
>>> --- the original content follows this line ---
>>> 
>>> I encountered a strange behavior when I declared a property with the 
>>> @NSCopying attribute:
>>> 
>>> // `Person` class inherits from `NSObject` class and conforms to 
>>> `NSCopying` protocol
>>> @NSCopying var employee: Person
>>> and then assigned an external instance of Person class protocol to this 
>>> property within the designated init methods:
>>> 
>>> // Designated initializer of `Department` class
>>> init( employee externalEmployee: Person ) {
>>> self.employee = externalEmployee
>>> super.init()
>>> 
>>> // Assertion would fail since Swift do not actually copy the value assigned 
>>> to this property 
>>> // even though `self.employee` has been marked as `@NSCoyping`
>>> // assert( self.employee !== externalEmployee )
>>> }
>>> If I indeed require the deep copying behavior during the init process, 
>>> instead of taking advantage of @NSCopying attribute, I would have to invoke 
>>> the copy() method manually:
>>> 
>>> init( employee externalEmployee: Person ) {
>>> // ...
>>> self.employee = externalEmployee.copy() as! Person  
>>> // ...
>>> }
>>> In fact, what really makes me confusing is that @NSCopying semantic does 
>>> work properly within the other parts of the class definition such as normal 
>>> instance methods, or external scope. For instance, if we're assigning an 
>>> external instance of Person to the self.employee proper of Department 
>>> directly through setter rather than initializer:
>>> 
>>> department.employee = johnAppleseed
>>> then self.employee property and johnAppleseed variable will no longer share 
>>> the same underlying object now. In the other words, @NSCopying attribute 
>>> makes sense.
>>> 
>>> After I looked through a great deal of results given by Google, and 
>>> dicussions on StackOverflow, I finally end up with nothing helpful — the 
>>> vast majority of articles, documentations as well as issues talking about 
>>> this similar topics only focus on the basic concepts and effects of 
>>> @NSCopying itself but do not mentioned this strange behavior at all — 
>>> besides one radar descriping the same problem (rdar://21383959 
>>> ) and a final conclusion mentioned in a guy's Gist 
>>> comment: ... values set during initialization are not cloned ...
>>> 
>>> That is, @NSCopying semantic has no effect in initializers.
>>> 
>>> Then, what I want to figure out is the reason why @NSCopying semantic will 
>>> become effectless implicitly whithin initializers of a class, and the 
>>> special considerations behind this behavior, if any.
>>> 
>>> --- END ---
>>> 
>>> Jordan:
>>> 
>>> Your observation is correct: @NSCopying currently does not affect 
>>> initializers. This 

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Rod Brown via swift-evolution]

Apart from your seeming distain for Swift, this proposal seems misguided to me, 
and to ignore some of the recent discussion around named parameters on tuples 
(which are currently in flux).

Each of the types you mention each have clear, specific meanings.

The following two are basic type system representations:
1. Classes - Reference, inheritance based items.
2. Structs  - Formal Value based items with storage (as opposed to enums which 
generally aren’t designed for storage).

The following two are collection types you’ve arbitrarily attacked for no 
reason. There are plenty of examples where each of these makes sense and is 
relevant within the language:
3. Arrays - Lists of items.
4. Dictionarys - Key value pair collections.

The final one is a separate basic type system representation:
5. Tuple. “Multiple values grouped together for a single compound value” (from 
Swift Programming Language Guide 3.0.1).

This type is to group related items together informally. That is, not as a 
wider type that is commonly used, but as an ad-hoc solution in cases where 
defining a type is neither required nor desirable. Say if I want to pass a 
return value of an item, and an associated description string for one method 
only, should I go and create a struct and all the boilerplate for that? This is 
an ad-hoc solution. That is in opposition to your example, which most 
definitely makes sense as a struct, and there already is one: CGPoint. Tuples 
themselves are actually a major part of how the language is built under the 
covers, and removing them for no reason is part of taking the guts out of 
Swift, for no reason.

I definitely agree there needs to be discussions regarding improving the 
situation for named parameters in tuples.

Accessing items: Each accessor is based on the one appropriate for the type. 
Unifying all member syntax purely for the sake of unifying it is a non-goal. We 
need to work out what is best for each case independently: properties vs 
subscripts. Rather than finding one obscure case where you used all of them and 
put them side by side, each should be assessed individually on their own merits.


> On 8 Jan 2017, at 1:17 pm, Freak Show via swift-evolution 
>  wrote:
> 
> FWIW, I searched the previous proposals for any kind of mention of tuple and 
> found nothing so forgive me if this has been discussed before.  
> 
> Swift currently has 5 ways to represent multi-values.
> 
> Classes, structs, arrays, dictionaries, and tuples.
> 
> Of these, classes are well established and unique in that they support 
> inheritance and often have identity.  
> 
> The others, however, are primarily used as value types in their immutable 
> incarnations.  Consider a desire to pass around a cartesian coordinate.  The 
> following representations are available:
> 
> let x = "x"
> let y = "y"
> 
> struct XY { var x: Int; var y: Int }
> 
> var txy = (x: 1, y: 2)   // (.0 1,.1 2)
> var sxy = XY(x: 1, y: 2 )// XY
> var dxy = [ x: 1, y: 2]  // ["y": 2, "x": 1]
> var axy = [ 1, 2 ] // [1,2]
> var taxy = ( 1, 2 ) // (.0 1,.1 2)
> 
> Their print strings are in the comment to the right - that could be a source 
> of a whole other proposal. 
> 
> A developer might choose from any one of these to represent a Point.  They 
> all represent the same information.  Yet the syntax required to make use of 
> them is annoyingly different.
> 
> Consider the tuple with named fields which is being used as a sort of 
> anonymous ad hoc struct:
> 
> txy.x // 1
> txy.0 // 1
> txy[x] // error
> txy[0] // error
> 
> vs the declared struct
> 
> sxy.x
> sxy.0  //error
> sxy[x]  //error
> sxy[0]  //error
> 
> vs the dictionary
> 
> dxy.x // error
> dxy.0 // error
> dxy[x] // 1
> dxy[0] // error
> 
> and then we have the tuple with unnamed fields
> 
> taxy.0 // 1
> taxy[0] // error
> 
> vs the array
> axy.0  // error
> axy[0] // 1
> 
> It is worth observing that, to the programmer the variable sxy is 
> indistinguishable from txy.  They represent the same informtion, they are 
> accessed in the exactly the same way.  They are completely equivalent.  
> However this fails:
> 
> sxy = txy // error
> 
> this succeeds (which may or may not be good depending on context and 
> coincidence):
> 
> var txy = (x: 1, y: 2)
> var txy2 = ( x: 2, y: 3)
> txy = txy2 // OK
> 
> but this fails (which I think is a good thing)
> 
> struct XY { var x: Int; var y: Int }
> struct XY2 { var x: Int; var y: Int }
> 
> var sxy2 = XY2(x: 2, y: 3)
> var sxy = XY(x: 1, y: 2 )
> 
> sxy=sxy2 // error
> 
> The point of this comparison is to point out that the anonymous type 
> generating tuple is a) superfluous and b) a source of confusion and 
> gratuitous complexity.  It assumes the role at times of immutable arrays, 
> anonymous structs, and immutable dictionaries depending on context and we 
> already have all of those things.  
> 
> Proposal:
> 
> 1) Eliminate the tuple as a first level concept.
> 2) Replace tuples that have 

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

[Rod Brown via swift-evolution]

-1.

Your proposal seems to confuse something we already have in the language to 
handle unwrapping and guarding, to only proceed if the item is non-null: Guard.

We already have a keyword and behaviour that you specify in the “guard” 
behaviour.

Additionally, changing “guard” to be “obtain” would require “obtain” to be 
signficantly better than the “guard” wording - instead, it is significantly 
worse.



> On 8 Jan 2017, at 1:46 pm, Carlos García via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a draft proposal to change if let construction for obtain let. 
> Proposal is at:
> https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/-Use-obtain-let-instead-if-let-constructions.md
>  
> 
> 
> I would like to see what you think and get help with "Effect on ABI 
> stability" and "Effect on API resilience" points
> 
> Carlos
> 
> ___
> 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 draft] Limiting @objc inference

[Rod Brown via swift-evolution]

> On 5 Jan 2017, at 11:50 am, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a draft proposal to limit inference of @objc to only those places 
> where we need it for consistency of the semantic model. It’s in the realm of 
> things that isn’t *needed* for ABI stability, but if we’re going to make the 
> source-breaking change here we’d much rather do it in the Swift 4 time-frame 
> than later. Proposal is at:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/-objc-inference.md
>  
> 
> 
> Introduction
> 
> One can explicitly write @objc on any Swift declaration that can be expressed 
> in Objective-C. As a convenience, Swift also infers @objc in a number of 
> places to improve interoperability with Objective-C and eliminate 
> boilerplate. This proposal scales back the inference of @objc to only those 
> cases where the declaration must be available to Objective-C to maintain 
> semantic coherence of the model, e.g., when overriding an @objc method or 
> implementing a requirement of an @objcprotocol. Other cases currently 
> supported (e.g., a method declared in a subclass of NSObject) would no longer 
> infer @objc, but one could continue to write it explicitly to produce 
> Objective-C entry points.
> 
> Swift-evolution thread: here 
> 
>  
> Motivation
> 
> There are several observations motivating this proposal. The first is that 
> Swift's rules for inference of @objc are fairly baroque, and it is often 
> unclear to users when @objc will be inferred. This proposal seeks to make the 
> inference rules more straightforward. The second observation is that it is 
> fairly easy to write Swift classes that inadvertently cause Objective-C 
> selector collisions due to overloading, e.g.,
> 
> class MyNumber : NSObject {
>   init(_ int: Int) { }
>   init(_ double: Double) { } // error: initializer 'init' with Objective-C 
> selector 'init:' 
>   // conflicts with previous declaration with the same Objective-C 
> selector
> }
> The example above also illustrates the third observation, which is that code 
> following the Swift API Design Guidelines 
>  will use Swift names 
> that often translate into very poor Objective-C names that violate the 
> Objective-C Coding Guidelines for Cocoa 
> .
>  Specifically, the Objective-C selectors for the initializers above should 
> include a noun describing the first argument, e.g., initWithInteger: and 
> initWithDouble:, which requires explicit @objc annotations anyway:
> 
> class MyNumber : NSObject {
>   @objc(initWithInteger:) init(_ int: Int) { }
>   @objc(initWithDouble:) init(_ double: Double) { }
> }
> The final observation is that there is a cost for each Objective-C entry 
> point, because the Swift compiler must create a "thunk" method that maps from 
> the Objective-C calling convention to the Swift calling convention and is 
> recorded within Objective-C metadata. This increases the size of the binary 
> (preliminary tests on some Cocoa[Touch] apps found that 6-8% of binary size 
> was in these thunks alone, some of which are undoubtedly unused), and can 
> have some impact on load time (the dynamic linker has to sort through the 
> Objective-C metadata for these thunks).
> 
>  
> Proposed
>  solution
> 
> The proposed solution is to limit the inference of @objc to only those places 
> where it is required for semantic consistency of the programming model. 
> 
>  
> Constructs
>  that (still) infer @objc
> 
> Specifically, @objc will continue to be inferred for a declaration when:
> 
> The declaration is an override of an @objc declaration, e.g.,
> 
> class Super {
>   @objc func foo() { }
> }
> 
> class Sub : Super {
>   /* inferred @objc */
>   override func foo() { }
> }
> This inference is required so that Objective-C callers to the method 
> Super.foo() will appropriately invoke the overriding method Sub.foo().
> 
> The declaration satisfies a requirement of an @objc protocol, e.g.,
> 
> @objc protocol MyDelegate {
>   func bar()
> }
> 
> class MyClass : MyDelegate {
>   /* inferred @objc */
>   func bar() { }
> }
> This inference is required because anyone calling MyDelegate.bar(), whether 
> from Objective-C or Swift, will do so via an Objective-C message send, so 
> conforming to the protocol requires an Objective-C entry point.
> 
> The 

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

[Rod Brown via swift-evolution]

I'm not part of the core team, of course, but I like this change in principle.

My one concern in this case would be choosing a naming convention for the back 
port that makes sense both ways. The naming convention you propose ( 
EnumName_EnumCase) seems inconsistent with the current import of strings from 
Obj-C to Swift. Could we find a way to unify them?

> On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution 
>  wrote:
> 
> I'm trying to revive an old thread. I'd like to hear from the community.
> 
> Can we make a swift enum string interoperable with Objective-C?
> 
> Currently NS_STRING_ENUM ports from objective-c to swift but not the other 
> way around.
> 
> I feel that if you can go one direction you should be able to go back.
> 
> @objc
> enum City: String {
> case NewYork = "New York"
> } 
> 
> Make this available as a global string in objective -c ?
>> On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:
>> I think enum strings should gain better interoperability with swift. 
>> Something like this:
>> 
>> enum City: String {
>>case NewYork = "New York"
>> } 
>> 
>> This can be ported over to Objective-c like this:
>> 
>> typedef NSString * City;
>> static City const City_NewYork = @"New York";
> ___
> 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] Enhanced Existentials

[Rod Brown via swift-evolution]

> On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution 
>  wrote:
> 
> Hello Mailing-list,
> 
> I remember we discussed enhanced existentials heavily during the Swift 3 
> timeframe but postponed it. I was wondering if we need to bring back for 
> discussion during Phase 1 or Phase 2? For reference, here is the proposal 
> which Austin Zhend wrote which represented the culmination of the discussions:
> 
> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential
> 
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I'm a big proponent of this - it's a limitation that is actually more capable 
in Obj-C than it is in Swift, and considering Swift's increased focus on 
Protocols, this seems rather baffling!

Would love to see this come forward into discussion.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

[Rod Brown via swift-evolution]

> On 30 Dec 2016, at 10:50 am, Freak Show <freaksho...@mac.com> wrote:
> 
> 
>> On Dec 29, 2016, at 13:28, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> I’m in agreement that ‘dynamic’ is probably not what you want without a 
>> declaration.
> 
> I hold a completely opposite viewpoint.  Dynamic is always what I want and 
> table based is premature optimization.  Late binding is important.  I found 
> far too often when working in C++ (yes I am really flipping old) I would come 
> across code where a developer hadn't chosen to make a method virtual and I 
> found myself just up a creek with regards to extending that code.  Ditto 
> people declaring stuff final in Java for no good reason.
> 
> The important thing to consider is that the future is generally unknowable 
> and if you don't know the future you cannot make good choices about what 
> should and should not be dynamic.  So the conservative thing is to make 
> everything dynamic until you cannot afford it - which...is usually never.

Then that’s great. If you’d prefer to work with a more open, overridable and 
intercetable platform which is dynamic by default, Apple has your back: Obj-C. 
It’s not deprecated. It’s actually the language they’re still writing iOS, OS 
X, tvOS and watchOS higher level frameworks in still, so you’re covered. Who is 
forcing you to use Swift, a language where compiler optimisations like this a 
stated goal?

> 
>> The only difference between table and method dispatch is the Objective-C 
>> message dispatch system. Unless users want to work around things by manually 
>> handling with some of the complex machinery in Obj-C, which is rare, then 
>> there is no reason behind doing so, and all it comes down to is a relatively 
>> large performance hit for nothing. And to be honest, with very few 
>> exceptions, if you’re using that ultra-dynamic machinery, you’re probably 
>> Doing It Wrong in the first place.
> 
> I do this sort of thing routinely and I assure you I am not Doing It Wrong.

Ok, so you do it a lot. That means definitively it’s the best way?

Obj-C was designed to constantly be interfering with method dispatch? You can 
do it, it’s there, message forwarding, those types of mechanisms, but if you’re 
relying on that for your day-to-day work, you’re in for a load of trouble, and 
you’re hacking around frameworks using the language rather than working with 
the frameworks. Apple don’t design their frameworks first and foremost for us 
to get in there and start using method swizzling or the like - in fact they 
specifically discourage it. Just because you do it and you think you’re smart 
doesn’t make it good design.

There are rare instances where frameworks and implementations use some of the 
really dynamic stuff, like CoreData, or KVO. That’s great. I’m not arguing 
there isn’t a use for it. I’m saying you pay a massive hit, 90% of the time for 
no reason.

> 
> I don't get why there is so much emphasis on performance in this day and age. 
>  I haven't run into a performance problem I could trace to speed of 
> ObjectiveC's method dispatching since the early 90’s.

Do a time profile of a modern Obj-C application. You’ll find that 15% of the 
time the application is running, it’s stuck in the middle of objc_msgSend. 
That’s a massive overhead in anyone’s books. Why is this important?

1. More CPU use equals more battery drain. Considering the vast majority of 
Apple’s platforms and the direction of computing as a whole is dependent on 
batteries rather than plugs in walls, this is important.

2. Moore’s Law won’t continue. We’re getting to the end of the road in what CPU 
advances have given us, and all those core multiplications just ends in more 
locks - we need to be more efficient because in 40 years of computing, we 
haven’t worried about making our software better, we just waited for CPU’s to 
catch up. News Flash: They won’t. Time for us to stop justifying ourselves and 
do something about making ourselves better at using the processing power we 
have.

3. Swift wasn’t designed just to replace Obj-C, a relatively high level 
language. It was designed to scale from system programming to the higher levels 
as well. Obj-C is good for basic UI development because you rarely tax the 
limits and are rarely worried about getting performance out of it.

4. Because performance in the language and its frameworks benefits everyone by 
giving more flexibility to their users.

> 
> Second - I have quite a lot of code that relies on this sort of dynamism. 
> I've been a very serious C++ developer and a very serious Smalltalk 
> programmer at various times in my career and I value the flexibility of late 
> binding far above performance.
> 
>> If you need this functionality, dynamic still exists. But Swi

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

[Rod Brown via swift-evolution]

I’m in agreement that ‘dynamic’ is probably not what you want without a 
declaration.

There are currently some bugs in how dispatch works for overrides in Swift 
extensions, and I’d like to see any methods that conform to an @objc protocol 
being given an implicit @objc, but true dynamic? No.

The only difference between table and method dispatch is the Objective-C 
message dispatch system. Unless users want to work around things by manually 
handling with some of the complex machinery in Obj-C, which is rare, then there 
is no reason behind doing so, and all it comes down to is a relatively large 
performance hit for nothing. And to be honest, with very few exceptions, if 
you’re using that ultra-dynamic machinery, you’re probably Doing It Wrong in 
the first place. If you need this functionality, dynamic still exists. But 
Swift is Table Dispatch by default for a reason: you’re paying a massive 
penalty for something you’ll rarely if ever use, and it should be opt in.


> On 15 Dec 2016, at 10:15 am, Brian King via swift-evolution 
>  wrote:
> 
> I wanted to follow up to a blog post I wrote about Message Dispatch in
> Swift — https://www.raizlabs.com/dev/2016/12/swift-method-dispatch. I
> mentioned some changes to NSObject that didn’t result in any
> objections, so I thought it was time to see what the SE mailing list
> thought.
> 
> I’ve read a few conversations on SE mailing list that have morphed
> into abstract conversations about dynamic vs static dispatch. I want
> to focus specifically on how Swift NSObject subclasses behave.
> 
> I think that there are 2 changes that will result in fewer bugs and
> will not have a substantial impact on performance:
> 
> 
> ## Remove Table Dispatch from NSObject
> 
> NSObject subclasses use table dispatch for the initial class
> declaration block. I think that using message dispatch for NSObject
> subclasses everywhere will result in a much more consistent developer
> experience.
> 
> ## Block NSObject Visibility Optimizations
> 
> Swift upgrades method dispatch to final when the compiler can prove
> that the method is not subclassed. I would like to see Swift be more
> careful about the impact of these optimizations on message dispatch,
> and consider message dispatch non-upgradable.
> 
> 
> I thought it would help to frame this choice as a trade-off between
> Swift’s goals of safe, fast, and expressive.
> 
> ## Safe
> 
> Always using message dispatch for NSObject subclasses will fix a class
> of runtime errors in framework features that are designed around
> message passing (e.g. KVO). Arguments against using dynamic features
> like this are valid, but Cocoa frameworks still use dynamic features
> and the above behaviors result in actual bugs. As a bonus, this will
> resolve SR-584, where a table-dispatched method that is overridden by
> a message dispatch method doesn’t behave correctly.
> 
> ## Fast
> 
> The above changes will result in slower dispatch in NSObject
> subclasses. However, I don't think that these dispatch changes
> actually have a tangible impact on performance. Most NSObject
> subclasses sit on top of a lot of `objc_msgSend`, and if there is a
> specific hot spot, it would still be optimizable via the final
> keyword.
> 
> ## Expressive
> 
> Using table dispatch for NSObject without any source indication or
> library documentation is not very expressive. I think it’s important
> to weigh table dispatch behavior against all of the framework
> documentation and developer experience that assume message dispatch.
> This will also eliminate the need for a lot of `@objc` and `dynamic`
> annotations that are often inconsistently applied depending on if they
> are needed in the scope they are defined in (e.g. class vs extension).
> 
> 
> If this idea shows promise, I’d be glad to formalize a Swift Evolution
> Proposal and explore syntactic details. I think being able to flag a
> class with `dynamic` and applying this flag to `NSObject` may be the
> only syntactic change needed. However, it would be good to debate the
> merit of the behavior change before the syntax.
> 
> 
> Thanks!
> 
> 
> Brian King
> ___
> 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] Move placement of 'throws' statement

[Rod Brown via swift-evolution]

I have rarely caught up into these situations - if I end up with multiple types 
of error, I generally create a wrapper error type. For example, my networking 
code includes a NetworkError type which encompasses all the errors that can 
happen within Foundation or my own code.

Could we not then in this way limit it to one declared type, to simplify the 
system? And then if you really don’t want to document type type, you either put:
> func myMethod(args:[String:Any]) throws Error { … }

Or:
> func myMethod(args:[String:Any]) throws { … }

As we currently do anyway?

How can giving more information at least optionally for safer and more correct 
code be a bad thing?

- Rod


> On 27 Dec 2016, at 11:21 pm, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution 
>> > wrote:
>> 
>> Daniel Leping, I am unfamiliar with java. Do you have any resources that 
>> describe the nightmare in detail?
> 
> I think the problem really comes down to the inflexibility of it; if you 
> specify X, Y, and Z as throwable types, then all code calling that method 
> must handle those types in some way.
> 
> Thing is, I wonder if this would be as much of a problem for Swift? We have 
> the try! and try? variations which make it very easy to ignore/simplify error 
> handling if we don't expect any to occur at all, or it doesn't matter if they 
> do, and we have the same basic means of handling generic unknown (or 
> unhandled) error types, plus throws and rethrows.
> 
> Part of the problem is that Java only ever treats the specified types as 
> mandatory (you *must* handle them somehow); I think a more elegant solution 
> could be if we could somehow mark them as optional, for example:
> 
>   func myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? 
> { … }
> 
> Here myMethod can throw two error types, IOError and IllegalArgumentError, 
> but while the first *must* be handled somehow, the latter is only optional as 
> a well formed args dictionary cannot possibly produce an error, i.e- it's an 
> error you might only want to check if the args dictionary was built 
> dynamically.
> 
> Basically in this case not handling an IOError would be an error, while not 
> handling IllegalArgumentError would be a warning (with some way to suppress 
> it). This means that APIs could even add new error types so long as they are 
> optional, though it's not advisable.
> 
> In addition to this we might introduce some mechanism for specifying *some* 
> of a method's error types, for example:
> 
>   func myMethod() throws IOError… { … }
> 
> Here myMethod specifies an explicit IOError that *must* be handled, but also 
> indicates that there are other, optional, types that don't need to be handled 
> explicitly. The idea here is that you specify only the most important types, 
> but can still indicate that there are other possible types (but maybe they're 
> rare, or only occur in very unusual circumstances described in 
> documentation), or you just want to leave the definition open-ended.
> 
> So yeah; personally I'm a supporter of being *able* to specify thrown types, 
> but do think it needs to be more flexible in what and how we specify them, to 
> avoid falling into the same pitfalls as Java. I definitely think that being 
> able to specify types that *must* be handled is useful, though we'd need to 
> make clear best practice (i.e- mandatory type handling should be reserved for 
> more serious errors in most cases).
> 
> Other things to consider are wether explicit thrown types could be marked as 
> handle immediately (i.e- throwing the error up the chain is a warning), and 
> whether non-explicit throws/rethrows could be automatically computed. For 
> example, if I have a method that has a plain throws, and handles three 
> methods, throwing errors of A, B? and C… respectively, with the first called 
> via try?, then my method's throwable types are B?, C…
> 
> 
> To conclude; while I like Swift's error handling as-is it's mostly because I 
> tend to use try! and try?, but when it comes to an actual try/catch I do like 
> Java's compiler supported enforcement making sure that I'm aware of which 
> types I'm supposed to do something with.
> ___
> 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] Move placement of 'throws' statement

[Rod Brown via swift-evolution]

I think the clear middle ground is an approach where you *can* document the 
type, but let it not be required.

Additionally, we can treat that at the calling end as a built time assurance of 
the type for error that is passed into the standard “catch { }”, and the 
compiler can also check that all of your catch let … casts actually are 
possible, and so catching becomes like a switch. I don’t see this as changing 
anything we currently do, except giving us the option to declare more than the 
current: Currently “throws” means “throws Error”. Why can’t we allow more 
information to be passed?

I think the compiler needs to remove the overhead of specified error types. 
Just like Java may be seen as a nightmare, it’s clear here that the fact we can 
specify different error types means *guessing* the error types is just as much 
of a nightmare. It makes sense, even if only for documentation reasons, to 
allow a declarable way of denoting your error type, and feeding that 
information to the compiler for built time checks.

> On 27 Dec 2016, at 10:20 pm, Charlie Monroe via swift-evolution 
>  wrote:
> 
> For me, handling Swift errors is a nightmare. You have no idea what to expect 
> to be thrown. Some developers use NSError for use with Cocoa/UIKit (usually 
> errors meant for user interaction), but some use enums that even can have a 
> payload (extra info about the error). And you need to rely on the 
> documentation, which can be nonexistent or inaccurate. Not to mention, within 
> that call, another throwing method can be called, which may not be mentioned 
> in the docs, which may result in other error types being thrown.
> 
> And mainly, when the docs mention that only MyErrorEnum can be thrown, you 
> have a catch branch for MyErrorEnum, but the compiler will complain that not 
> all cases are handled. So you either need to catch a generic Error and 
> force-cast it, or add another catch _ branch calling fatalError - unhandled 
> error. Either way, not a pretty solution.
> 
> While I always hated Java's approach of listing all exceptions that can be 
> thrown, I equally hate current state of Swift, where you have no idea what's 
> comming at ya. In ObjC, you knew it was NSError. Yes, you still can bridge 
> any Error to NSError, but you loose a lot of potentially useful information 
> about the error.
> 
> 
>> On Dec 27, 2016, at 10:57 AM, Daniel Leping via swift-evolution 
>> > wrote:
>> 
>> -1 for specifying errors for throws. Please don't. Proven by practice in 
>> java it's a nightmare.
>> 
>> On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution 
>> > wrote:
>> I like the idea of "throw" having information about what might be thrown.
>> 
>> Maybe you have an enum of errors that may be thrown. How would the 
>> programmer know what might get thrown if they don't know the implementation 
>> details?
>> 
>> While adding the throwing info in the comments is good, we might be better 
>> off adding an attribute 
>> 
>> @throws(Error_Enum, Specific_error, ...)
>> 
>> Where the stuff in parenthesis is a comma separated list of possible errors. 
>> Maybe it's all the cases in enum are possible or maybe only a specific few 
>> are used...
>> 
>> Then we can do something like this
>> 
>> @throws(MyErrorEnum)
>> func foo() {
>> 
>> throw MyErrorEnum.firstError
>> 
>> }
>> 
>> With this info we can properly catch all error cases
>> 
>> do {
>> try foo()
>> } catch MyErrorEnum.firstError {
>> 
>> } catch {
>> }
>> 
>> As for blocks that throw we could probably add it in the same place where 
>> @escaping is.
>> On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution 
>> > wrote:
>> Maybe we can let the compiler use documentation comments for type-checking. 
>> Currently you can do:
>> 
>> /// does something
>> ///
>> /// - returns: Something cool
>> ///
>> /// - throws:
>> ///- `MyError.Something` if a certain thing happens
>> ///- `POSIXError` if something goes horribly wrong
>> ///
>> func doSomething() throws -> Int
>> 
>> I would prefer if we found some way to integrate that stuff in to the 
>> compiler. I mean, you would probably want to document why the errors get 
>> thrown anyway, and it’s better than clobbering up the function signature.
>> 
>> Maybe it seems weird to have the compiler look inside comments (especially 
>> if the set of thrown errors becomes a resilience-breaking part of the 
>> function), but why not? Swift’s documentation comments are just another 
>> source of structured data, and the compiler already understands them at a 
>> superficial level.
>> 
>> Just saying, there are options.
>> 
>>> On 27 Dec 2016, at 07:55, Tony Allevato >> > wrote:
>>> 
>>> One thing to keep in mind is that, if I 

Re: [swift-evolution] Type-annotated throws

[Rod Brown via swift-evolution]

>> 
>> On Fri, Aug 26, 2016 at 5:43 PM, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> (resent for Swift Evolution)
>> 
>> I’m a big fan of this idea. Currently “throws” seems like a very limited API 
>> - you know it’s throwing out something, but you can only hope to guess what 
>> that is or create fallbacks. Definitely a big +1 from me. A fallback for 
>> compatibility could be “throws” assumes “throws Any” and can be a warning?
> 
> I’d suggest a bare `throws` = `throws ErrorType` (you can only throw 
> ErrorType, right?) and be valid, I don’t see any reason to make it a warning 
> (plus that keeps source compatibility). 


*hits head on desk*

How could I miss that?  `throws` = `throws ErrorType` makes perfect sense. It 
also means we can get some type safety, but it’s not lock in.

Thanks :)

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

Re: [swift-evolution] Type-annotated throws

[Rod Brown via swift-evolution]

(resent for Swift Evolution)

I’m a big fan of this idea. Currently “throws” seems like a very limited API - 
you know it’s throwing out something, but you can only hope to guess what that 
is or create fallbacks. Definitely a big +1 from me. A fallback for 
compatibility could be “throws” assumes “throws Any” and can be a warning?

While I am not deeply familiar with the implications, I do like think your line 
of reasoning has merit, and think this makes sense for Phase 1 of Swift 4. 

- Rod


> On 27 Aug 2016, at 1:39 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Currently, a function that throws is assumed to throw anything. There was a 
> proposal draft last December to restrict that. The general idea was that 
> you'd write, for instance:
> 
>> enum Foo: ErrorProtocol {
>> case bar
>> case baz
>> }
>> 
>> func frob() throws Foo {
>> throw Foo.bar // throw .bar?
>> }
> 
> If you `catch Foo` (or every case of Foo), now that the compiler can verify 
> that your catch is exhaustive, you no longer have to have a catch-all block 
> at the end of the sequence.
> 
> This impacts the metadata format and has implications on resilience, which 
> leads me to believe that the discussion could qualify for the phase 1 of 
> Swift 4. If this is the case, I'd be interested in pulling out the old 
> discussions and seeing where we left that at.
> 
> Félix
> 
> ___
> 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-0137: Avoiding Lock-In to Legacy Protocol Designs

[Rod Brown via swift-evolution]

>   * What is your evaluation of the proposal?
+1. Agree we should deprecate legacy features that we don’t intend to support, 
to make future transitions easier for users.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
Yes.

>   * Does this proposal fit well with the feel and direction of Swift?
Yes. Consistency and clarity going forward, and clearly documenting the 
features Swift will not support is important.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
N/A

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick Read

> On 11 Aug 2016, at 7:03 AM, John McCall via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0137: Avoiding Lock-In to Legacy Protocol Designs" begins 
> now and runs through August 14. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.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 contribute to 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,
> 
> John McCall
> 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

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

[Rod Brown via swift-evolution]

This makes perfect sense why it would perform worse, and I agree this seems 
like a legitimate place for a special case.

> On 29 Jul 2016, at 3:01 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jul 28, 2016, at 6:38 AM, Paulo Faria via swift-evolution 
>>  wrote:
 I doubt there would be a performance difference between adding `func 
 joined() { return joined(separator: "") }` and changing the parameter to 
 `separator: String = "”`.
>>> 
>>> I’ll let a stdlib guru comment on this :-)
>> 
>> I’m very curious about this. Default parameters are really slower?
> 
> The version that takes an arbitrary separator as a parameter (defaulted or 
> not) does twice as many appends unless it specifically recognizes the empty 
> separator as a special case.
> 
> That said, I'm not sure it shouldn't try to recognize the empty separator as 
> a special case.
> 
> John.
> ___
> 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] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Rod Brown via swift-evolution]

   * What is your evaluation of the proposal?
+1. It's consistent with the new language guidelines, and though 'flatten' 
seemed a term-of-art there are multiple arguments here that would clear up 
things, like the string combination.

   * Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes.

   * Does this proposal fit well with the feel and direction of Swift?
Yes. It is consistent with the direction of things, and streamlines APIs.

   * If you have used other languages or libraries with a similar feature, how 
do you feel that this proposal compares to those?
N/A

   * How much effort did you put into your review? A glance, a quick reading, 
or an in-depth study?
A quick reading.

> On 25 Jul. 2016, at 4:10 pm, Chris Lattner via swift-evolution 
>  wrote:
> 
>* 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?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Rod Brown via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md

- What is your evaluation of the proposal?

+1 to the second proposal, if we were to drop the concept of a final class. I 
feel like by blocking subclasses in preference to extensions, we would need to 
be 100% sure we could add stored properties in extensions, otherwise adding a 
stored property would require a subclass. I think that final fully on a class 
tends to be superfluous if we have final and/or open on methods. This would 
allow for composition with little penalty for optimisations.

If we have final classes as a whole, I recommend we go with option 1.

I personally prefer Option #2. I think that a lot of us are going “that’s not 
swifty” and using that as a justification. Lets be honest, we’re deliberately 
limiting ourselves here against composition via subclassing, without writing 
lots of frameworks and libraries where this would directly impact us and we’d 
learn our lessons. Why block composition via subclassing? Opinion, based on 
“this can all be done by extensions and that feels swifty”. Well it currently 
can’t be done via extensions. Perhaps we should be more open about this and 
allow users to choose their composition methodology… I feel like we’re blocking 
something unnecessarily.

Blocking all the members of a class can still be done, but we could 
theoretically allow composition on classes that are otherwise final or sealed. 
Why not?

I love the concept of clear subclassing with “Open” as an extension of the 
access level, showing public *and* subclassable. This is actually how I assumed 
this would work in the first place.

- Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes

- Does this proposal fit well with the feel and direction of Swift?
Yes. I think Option 2 however slightly changes that direction, and I think 
that’s a good thing.

- If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
N/A

- How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
Continued interest in the discussion. Thorough read.


-Rod



> On 22 Jul 2016, at 1:33 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The third review of "SE-0117: Allow distinguishing between public access and 
> public overridability" begins now and runs through July 25. 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
> 
>   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 contribute to 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,
> 
> -Chris Lattner
> 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

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

Review link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md


* What is your evaluation of the proposal?
+1 for the implementation. +0.5 for the concept. I think this is a clean interface for 
what open should be, and am glad at the simplification. This seems very 
"Swifty", and much better than the first proposal. I'm concerned that this may 
be over-limiting developers, and while everything looks great in theory, I am concerned 
that this may not be a good decision for real-world development. That said, I also think 
there are real wins in the ability to at a later date finalise a class for performance 
reasons, and provides clear structure for how a subclass is designed be used.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
I think that sorting out our inheritance story for public frameworks is 
important if we are going to start seeing public Swift Frameworks in the wild 
more often.

* Does this proposal fit well with the feel and direction of Swift?
Yes.

* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I haven't. I've used Obj-C a lot. The ability to fix some issues with patching 
leads me to be concerned that we are overly restricting things here.

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I've been following the threads since this discussion started months back, in 
discussions recently over it, and have read thoroughly both reviews.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

I think you missed that I actually agree with all your points.

My point was merely regarding “pre-breaking” which I thought wasn’t a relevant 
term. I think a far more appropriate term is “overly limiting”. We are 
discussing semantics, nonetheless.

I actually support the idea that you should be able to subclass classes by 
default, with some form of acknowledgement that “I know this wasn’t meant to be 
subclassed, but I’m going to anyway.” This frees framework developers from the 
idea that it was “promised” to be able to work, and also frees a developer from 
the chains of an overly constrained development environment.

- Rod


> On 12 Jul 2016, at 9:00 AM, Jonathan Hull  wrote:
> 
>> 
>> On Jul 10, 2016, at 7:48 PM, Rod Brown  wrote:
>> 
>>> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  wrote:
>>> 
>>> It is pre-breaking in that it is the exact same code that doesn’t work in 
>>> both cases (only in the pre-breaking case, a bunch of other code also 
>>> doesn’t work).  I know it feels different because it “was never possible” 
>>> vs our change being the cause, but it is one of those things like me giving 
>>> you $5 or giving you $10 and later taking back $5.  As humans we are loss 
>>> averse so we devise strategies to hide the loss from ourselves.
>> 
>> I completely disagree with this.
>> 
>> Not providing someone something due to risk of breakage is not the same 
>> thing as “giving it and taking it away”. We don’t build bridges out of spare 
>> parts and tell people “We build it but we expect it to break at some stage, 
>> so use with caution.” You either build it correctly, or you don’t let people 
>> cross the bridge. At All.
>> 
>> This isn’t about “loss averse”. This is about risk management.
>> 
>> Where does the line lie on risk? That’s ultimately something the core team 
>> will have to decide.
> 
> My point is that you are completely ignoring an entire class of risk that has 
> a real-world $$$ cost.  Every time I have to use a framework under this 
> proposal, I am now completely at the mercy of the author.  In the case of 
> open source frameworks I can at least make a fork, but for closed source 
> frameworks (often from large companies where us using their framework has 
> been negotiated by the bosses) you have now just added weeks to my 
> development cycle while I wait for 
> big-company-who-doesn’t-really-care-that-much to update their stuff. (sure I 
> can work on other things during that time, but delaying a launch isn’t free)
> 
> Are you offering to explain to my boss/client why I can’t add the feature in 
> a reasonable timeframe like I can with Objective C frameworks?  That it may 
> not even be possible now in Swift even though the Android guy just did it in 
> a few hours?  
> 
> Do you know what I am going to tell my boss/client?  "Don’t use Swift for 
> frameworks” and “Try to avoid partnering with companies that have Swift 
> frameworks”.  "It is too much of a risk".  "We are giving them too much 
> control over the future of our product…"  I mean, it even affects the prices 
> that companies can charge for crappy frameworks. If I am asking for a bunch 
> of features that I NEED them to add to provide a basic feature, that affects 
> negotiations/price (vs a world where I can add it myself if needed).  
> Sealed-by-default gives them leverage.
> 
> To use your bridge analogy, which is better in the case that you haven’t 
> provided a bridge for me:
> 1) I build my own bridge knowing that I will need to maintain it periodically 
> (usually on a predictable schedule)
> 2) Have everyone wait for 6 months (loosing $ the whole time) while I plead 
> with you to build the bridge for me.
> 
> By definition, the least thought through frameworks are the ones most likely 
> to need workarounds, but under this proposal, they are also the ones we will 
> be unable to fix.  I think some people think that this proposal will make 
> them fix those frameworks or make them disappear… but they are often from big 
> brand name companies, who don’t care that much because tech isn’t their main 
> business.  In my experience, we can get the changes we need, but it takes 
> anywhere from 2 months to a year.  Being able to patch in a stop-gap while we 
> are waiting is very important for the health of the business.
> 
> For example, I had a recent client that called me in a panic (unfortunately I 
> have somehow gotten a reputation as someone to call for impossible tasks) 
> because they had a demo they needed to show for a potential multimillion 
> dollar deal and it just wasn’t working.  The tech they had used as a base 
> wasn’t doing what it was supposed to… and the fixes were 3-6 months away (the 
> demo was a week and a half away).  I would call the support guy for the tech, 
> and they would tell me “that isn’t possible yet. Just wait for the update”.  
> I would call them back a couple of hours later saying “If someone else 

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[Rod Brown via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
 


>   * What is your evaluation of the proposal?
-1. Extensions appear to me to follow the access control of the rest of Swift: 
Implicit to the type you are extending, and you can either / both declare as 
part of the extension declaration or on the method. I don’t see how this is 
confusing, and I expect people will be more confused that extensions don’t 
follow the convention of the rest of Swift for Access Control.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
I don’t think this warrants a change.

>   * Does this proposal fit well with the feel and direction of Swift?
No. This seems to go against the 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?
No.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
A reading of the proposal.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[Rod Brown via swift-evolution]

Sent from my iPhone
On 12 Jul. 2016, at 6:19 pm, Goffredo Marocchi <pana...@gmail.com> wrote:

>> After all… you clearly don’t know about your current state, so how can you 
>> know how to correctly recover from it?
> 
> This a bit of a stretch, it is often the case but  not a necessary 
> conclusion. Both C++ and Java have a model where it is not uncommon to 
> recover from exceptions instead of crashing. You might know enough about your 
> context to be able to go back to a safe point in time/app lifecycle and 
> resume from there. 

I was not meaning to state that as an absolute, but as a generalisation. As I 
mentioned later, I do have cases where it's appropriate to use an ifExists 
subscript.

That said, Swift's safety isn't generally built around "safe from crashes". 
After all, unwrapping an optional in Swift is a fatal error, and sending a 
message to nil in Obj-C is a no-op! So Obj-C is safer! ... um... no. It's safer 
in that it forces you to reason about your code rather than letting nil be 
no-op. That sounds remarkably similar to making someone reason about accessing 
an array and crashing, rather than just letting it be a no-op.

You'll also notice that Swift doesn't have the exception handling that C++ and 
Java do, as you referenced. Again, this appears to be in the same train of 
thought: if you've met an exception, you didn't reason about your code, and the 
safest thing to do is quit. Swift does have error handling, on the other hand, 
understanding that errors can occur that are not related to inconsistent 
reasoning about your code.

Are there ways you could recover? Sure, in some circumstances. I could say the 
same thing about incorrectly unwrapping nil, or any other error of logic. I 
think Swift comes down hard on the side of "if there are errors in logic, just 
crash now, it's the best overall choice."

Do I agree with it? Personally, I do, as I think it's a pragmatic decision 
overall. I can definitely see why others may disagree, and please feel free to 
add ifExists subscript in your projects like I have.

> 
> Also, the more scenarios we want to code in pure Swift in the more cases in 
> which other languages offer features we do not want in Swift now we are going 
> to encounter. The pragmatic voice in engineers will start asking "why do I 
> need to jump through hoops for purity's sake"? 

I don't think this is a purity issue. It seems pragmatic to crash as it's 
almost always a programmer error that would cause this situation. A simple 
check on count would fix this in any other cases. Encouraging people to Handle 
programmer errors rather than simply Fix them seems rather odd to me.

> 
> Sent from my iPhone
> 
>> On 12 Jul 2016, at 09:10, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> After all… you clearly don’t know about your current state, so how can you 
>> know how to correctly recover from it?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

Resent for Swift Evolution:

With the existence of Swift on the server, dynamically linked, independently 
distributed frameworks will not be an Apple-only issue - this extends beyond 
Apple's OS X-based platforms towards how dynamic frameworks link against each 
other as if they are to be distributed separately.

It is short sighted to suggest that all Swift deployments will be under Apple's 
control.

On 11 Jul. 2016, at 3:43 pm, Tino Heth <2...@gmx.de> wrote:

>> It is *not* the case with a framework. Dynamically linked frameworks can be 
>> changed without the app even being changed. Imagine if Apple changed UIKit 
>> and make UINavigationController final retroactively. 
> Your argument is true, and you choose a good example — but it's actually the 
> only one that exists at all:
> There are no other parties that ship frameworks that way, and I don't think 
> this should change.
> 
> So the benefits of this proposal would exist for Apple alone, and I can 
> understand why sealed is convenient for an UIKit-engineer.
> It is tempting to aim for the easiest solution, but it is smarter to take the 
> route that's better for the customer (and we happen to be the customers).
> And, as others pointed out before, Cupertino is free to diverge from the 
> defaults in either direction, so it is only a little effort to have "sealed 
> by default" without the bad side effects.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  wrote:
> 
> It is pre-breaking in that it is the exact same code that doesn’t work in 
> both cases (only in the pre-breaking case, a bunch of other code also doesn’t 
> work).  I know it feels different because it “was never possible” vs our 
> change being the cause, but it is one of those things like me giving you $5 
> or giving you $10 and later taking back $5.  As humans we are loss averse so 
> we devise strategies to hide the loss from ourselves.

I completely disagree with this.

 Not providing someone something due to risk of breakage is not the same thing 
as “giving it and taking it away”. We don’t build bridges out of spare parts 
and tell people “We build it but we expect it to break at some stage, so use 
with caution.” You either build it correctly, or you don’t let people cross the 
bridge. At All.

This isn’t about “loss averse”. This is about risk management.

Where does the line lie on risk? That’s ultimately something the core team will 
have to decide.




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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

@Jonathan

I don’t think that "pre-breaking code" is a good description. You are not 
breaking anything - you’re just not allowing something that *could* become 
unsafe. It’s safety first, at the cost of the library user’s flexibility.

That said, I actually think you have a good point however that “sealed” should 
be able to be overridden, either in a patch capacity or an “unsafe” capacity. 
Should this become final at a later point, you have acknowledged you know this 
will be unsafe and are willing to take this risk to get the job done. This is 
opt-in risk.

Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just have 
a keyword for “Open” as an access level, and if you subclass or override things 
that are not “open” from other modules, you must mark unsafe.

I think this is a decent compromise: We allow potential to patch, but 
discourage without acknowledgement of the risk. Allow Final and Open to be 
declarative.

- Rod



> On 11 Jul 2016, at 11:05 AM, Jonathan Hull  wrote:
> 
> @Rod:  Thank you for actually replying to the content of my post.  Much 
> appreciated.
> 
> It is a trolly problem.  You are arguing that pre-breaking everyone's code is 
> better (even if causes way more trouble overall) than taking an action that 
> breaks a few people’s code later (and thus feeling responsible).  There are 
> other options. I grew up watching enough Star Trek that I don’t believe in no 
> win scenarios.
> 
> I still think my compromise is the best solution.  3 levels: Open, Sealed, 
> Final.  The difference is that sealed can be overridden with a compiler 
> warning and use of “unsafe” keyword, but final can’t be overridden.  That way 
> the user is acknowledging that they are doing something which isn’t supported 
> in the context which they are doing it… but it doesn’t completely prevent it 
> by default.  Opt-out safety.  (Yes you lose some compiler optimizations in 
> the default case, but that was premature optimization anyway).
> 
> As for the interaction with public/internal/etc… that should be explicit.  
> This proposal confuses and intermingles them.  You should just be able to say 
> ‘public final internal(open)’ or some other syntax which lets you express the 
> same sentiment.  (The above says the class/method is public and final, but 
> internally it is open.)
> 
> I am not saying that we shouldn’t solve these issues.  I am saying this 
> proposal:
> 1) Isn’t easily discoverable.
> 2) Requires communication between different parties (author and user) which 
> slows iteration cycles to weeks or months (vs the usual minutes)
> 3) Conflates/mixes the ideas of access level and subclass-ability
> 4) Makes way too many separate changes in a single proposal: New idea of 
> “sealed”, new default, replaces ‘public’ in some cases but not others, new 
> keywords (which everyone wants to change), etc…
> 5) Has structural problems which mean that it won’t actually increase 
> thoughtfulness
> 6) Makes app developers extremely dependent on framework authors (and those 
> author’s schedules)
> 7) Will require us to patch/fix it later, but that will be difficult due to 
> optimizations/assumptions of finality.
> 8) Will cause unnecessary pain for both framework authors and users of 
> frameworks
> 
> We would be foolish to accept this proposal without planning for the 
> inevitable escape hatch.  We will need it, and if we don’t plan for it, it 
> will break everything when we are forced to fix it in Swift 4/5.  Anything 
> else is idealistic to the point of ignoring real-world use/behavior.
> 
> As I said before, this type of thinking: “If we just make things more 
> difficult, it will encourage awareness” is what leads to the DMV, TSA, and 
> Java.  The problem is, the brain doesn’t work that way, and it ultimately 
> just adds pain without being effective.  You can add forcing functions (like 
> optional unwrapping), which are annoying, but effective… but as I also 
> mentioned before this proposal doesn’t do that.  It is structurally 
> different.  It will not do what you think it does.
> 
> Thanks,
> Jon
> 
> P.S.  There is also a dangerous difference between helping the programmer 
> catch mistakes (e.g. don’t accidentally subclass the wrong method) and trying 
> to prevent them from coding in a style you disagree with.  I have been seeing 
> far to many proposals of the second variety of late.
> 
> 
>> On Jul 10, 2016, at 2:58 PM, Rod Brown > > wrote:
>> 
>> I personally agree with most of your assessments. It's why I pushed so hard 
>> for "allow subclassing my default" in the first discussion of this point.
>> 
>> The problem with this is simple: you cannot retroactively "close up" an API. 
>> I cannot add final to a class I have previously declared as non-final. I 
>> also can seal a class which has previously been open to subclassing.
>> 
>> Consider: someone builds against my framework and I do 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

This is the case with a library.

It is *not* the case with a framework. Dynamically linked frameworks can be 
changed without the app even being changed. Imagine if Apple changed UIKit and 
make UINavigationController final retroactively. UIKit internally would 
therefore call directly to the UINavigationController methods statically, and 
bypass any subclass’s methods, thereby breaking applications. Should app apps 
have to be rebuilt to work with iOS 12 simply because Apple shipped a new 
version of UIKit? This is illogical. You will *break* things by finalising 
after the fact. Swift, being about safety, needs to deal with this safely.


> On 11 Jul 2016, at 9:13 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> The problem with this is simple: you cannot retroactively "close up" an API. 
>> I cannot add final to a class I have previously declared as non-final. I 
>> also can seal a class which has previously been open to subclassing.
> Of course you can do both — it may make users angry, but so what?
> The essence of this way of thinking is "I fear the reaction of my users when 
> I take something away from them… so I have to deny them those options right 
> from start".
> 
> I've no statistics (there's a general lack of facts all over the place…), but 
> I don't thing the majority of todays and future libraries are build with a 
> strictly planned top-down approach and guarantees about API-stability. 
> Nowadays things are much more spontaneous, and the strict rules and limits 
> some people here want to force upon others would most likely decrease the joy 
> in playing with the language and start experiments in it.
> 
> There is only a very small number of Swift-developers writing frameworks that 
> are used on a large scale basis, and even if many people in this group vote 
> for limiting defaults, the focus should be on the majority:
> When I come to the conclusion that a set of classes in a project could be 
> useful somewhere else, my problem is not fear of future API changes — it is 
> the daunting task of having to sprinkle "public" all over the place.
> Sealing classes makes proper code reuse a more tedious job, and I want Swift 
> to stay fun rather than become a playground for sticklers for order.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

I personally agree with most of your assessments. It's why I pushed so hard for 
"allow subclassing my default" in the first discussion of this point.

The problem with this is simple: you cannot retroactively "close up" an API. I 
cannot add final to a class I have previously declared as non-final. I also can 
seal a class which has previously been open to subclassing.

Consider: someone builds against my framework and I do nothing, and they 
subclass my classes. Then later I come through and mark the classes as 
"Sealed". What should we do with those classes that are subclassing my classes? 
Nothing. I can't. I permitted access and now I'm beholden to that access level.

On the other hand, opening up access levels gradually has no such issues. Users 
of my class can't subclass, and then they can. They just have another tool in 
the bag now.

If you want a default, it should be one you can reverse later. Your default 
should not be the most restrictive.

Whilst I agree with most of your points, this core concept seems to trump them 
to my mind.

- Rod

> On 10 Jul. 2016, at 5:51 am, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Please stop saying that this proposal will bring more consideration to the 
> design of libraries.  It isn’t true.  I haven’t even seen an argument for why 
> it would be true, it is just taken for granted that it is true.
> 
> As I mentioned in another post, this is structurally very different from 
> things like ‘if-let’ and optionals.  Optionals force the user to consider 
> their decision in the context it is being used (i.e. as you use the 
> optional/value).  This proposal, however, does the opposite.  The effect of 
> your actions appear in the context of a completely different user.  It is 
> like sitting in a room, flipping a light switch wondering “I wonder what this 
> does?”… meanwhile the people downstairs are wondering why their lights keep 
> turning off and on”.  
> 
> You can try to test for this, but by definition library authors can only test 
> for scenarios that they have thought of.  I have often found people surprise 
> me with their use-cases.  Relying on the diligence of other programmers is 
> what leads to things like: "You always need to remember to test for zero 
> before using a pointer".  Literally the opposite of optionals!  It sounds 
> good, but at the end of the day, people are human and they WILL make 
> mistakes.  Best to either catch those mistakes in the context where they 
> happen or to mitigate the effect of it.  This proposal basically forces you 
> to feel the full effect of other people's mistakes (thinking that it will 
> discourage them from making them in the first place).
> 
> Your only real mechanism for feedback is when users of your library complain 
> to you that something that they need isn’t subclass-able.  This is the point 
> where most framework authors will actually learn that this feature/default 
> exists.  Users of a framework will learn of it slightly earlier, when they 
> find they need to subclass something, and it just isn’t possible.
> 
> 
> I would much prefer adding a ‘sealed’ keyword which library authors could use 
> to annotate things which they do not want subclassed outside of the module.  
> Or preferably, as others have suggested, allow augmentation of ‘final’ with 
> ‘public(final)' or ‘internal(final)’.
> 
> The only case where I would support ‘sealed’ by default is if there are 3 
> levels: open, sealed, final.  Final would allow 'public(final)' and 
> 'internal(final)’ to allow private subclassing inside the file/module.  
> Sealed would be the same, except it would allow the user to subclass by 
> explicitly acknowledging the risk using ‘unsafe’:  “unsafe class 
> MySubclass:SealedSuper“ and  “unsafe override func”.  Final would not allow 
> the override.
> 
> That is the case where ‘sealed’ makes sense as a default…
> 
> Thanks,
> Jon
> 
> P.S. The current proposal will only cause massive problems down the line, 
> IMHO.  We will find an escape hatch is needed, but we will have made 
> optimizations based on assumptions of finality which prevent us from easily 
> adding one.
> ___
> 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] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

[Rod Brown via swift-evolution]

I only had a passing glance but I'm a fan.

> On 11 Jul. 2016, at 6:33 am, Jasdev Singh via swift-evolution 
>  wrote:
> 
> Hey Swift Evolution!
> 
> Drafted up a small proposal that harmonizes the use of static functions and 
> static function properties in appropriate protocol conformance scenarios:
> 
> https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/-static-func-and-static-var-func-protocol-conformance.md
> 
> Would love any feedback or edge cases I may have missed!
> -- 
> @jasdev
> ___
> 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-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

* What is your evaluation of this proposal?

A reluctant +1. I’m reluctant because I actually do love the flexibility in 
Obj-C to subclass where I feel appropriate, and feel the limitations of this 
are going to be difficult to get used to.

From what I see, however, “final” as a concept makes this more compelling. 
Being able to retroactively add final to a class is a great benefit for 
libraries, and this won’t be possible if we allow subclassing by default. 
Additionally, designing for subclassing is important and really should be 
considered at design time. I also think we need to flesh out the subclassing in 
this proposal where there are requirements to the override etc, but I agree in 
general with this concept.


* Is the problem being addressed significant enough to warrant a change to 
Swift?

There are multiple problems that this addresses. A change is definitely needed 
here to resolve them, whatever the form these changes take.


* Does this proposal fit well with the feel and direction of Swift?

Clarity at requirements for subclassing, and being more specific, seems in the 
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?

I’ve used plenty of languages with subclassing, focusing most on Obj-C. I love 
the freedom to subclass in this language, but it’s fair that this is not the 
safest practice. Obj-C seems to be the wild west for subclassing.


* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

I’ve read the proposal, followed the conversation, and was involved in the 
first discussions about this earlier in the year.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

[Rod Brown via swift-evolution]

Comments inline (resent to swift evolution)

> On 7 Jul. 2016, at 4:28 am, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Hi there
> 
> From the perspective from many active programmers
> that use Swift (not objective C anymore) I am  not
> very happy by having to change
> program source all the time:   
> 
> Therefore after Swift 3.0 is released I’d recommend kindly:
> 
> 
> Freeze Swift For Some Time! 
> Do Not Change AnyThing For At Least 2 Years.
> (Yes you’ve read that correctly: two years.)

Freezing seems antithetical to the evolution of new features. Avoiding 
source-breaking changes is reasonable, and I believe this is plan going 
forward. Even then, making this a hard rule still ends up with the same issue: 
the more we delay changes, the more we just push out the inevitable and drag 
the pain out longer.

> 
> Still there? OK, read on:
> 
> In the mean time, you’ll have the great opportunity
> to fine-tune compiler and run time systems, to eliminate
> the few bugs there and make it blazingly fast!

This discounts the fact that a lot of the speed improvements don't simply come 
from a smarter compiler. Many improvements in speed and compilation are held 
back by a lack of guarantees that the compiler can rely on due to the 
language's limitations. Swift's efficiency and performance comes from the 
language-specific guarantees that the compiler can leverage. While there are 
some guarantees that aren't currently leveraged in the compiler, this statement 
appears to some extent contradictory. "Make it faster, but don't change 
anything!”

> In two (or more) years,  there are enough Real Users (programmers) 
> that by then will have enough practical experience with Swift, which
> might play a more solid role in improving Swift, and of course,
> are extremely happy with Swift, and that it is not changed
> all the time, So that they can concentrate on writing cool,
> reliable and decent programs, instead of revising it all
> the time! 

So we wait to get a larger user base so we hurt *more* people when we do this? 
Why?

> 
> After such time, and much more intensive and practical usage, 
> it becomes clear, what is good in Swift and what is not. 

Because the current team don't have enough experience with swift to work it 
out, but a year or two more of doing the same thing without any changes will 
somehow give them that experience?

> What happens now, for instance, is that some base their “statistics” of which 
> language elements etc. are frequently used or not, merely upon scanning 
> a codebase of the relatively few (compared with e.g. ObjC, Java or C#) 
> programmers
> that use Swift now

Statistics aren't everything. Focusing on a few language elements at the 
neglect of the rest is ill-advised. Do you build a house but only focus on 
building a foundation well only in the rooms you expect people to walk in?

> 
> Imho, Swift has not yet been in use long enough. It needs a prolonged time 
> because now, most users have relatively little experience using Swift, 
> thus the way they program now is not really representative with what one 
> really can do
> with this powerful language, compared to experienced (years, not months) 
> programmers in other languages. 
> Still a lot has to be discovered, has to settle and form good mental pictures 
> in 
> programmer’s minds. It is all going a bit too fast, I think.
> 
> 
> Please (if you did’t already) realize that already many source
> code all over the world is written in Swift therefore it is very, very
> important that backwards compatibility should be preserved as much 
> as possible. because  backwards-breaking-changes are a disaster
> to companies/individuals that have already hundreds or thousands
> of programs written in Swift.

I think everyone is aware there are commercial and logistical issues with 
continuing to change Swift. That's why there was such a rush to bake every 
source-breaking change into Swift 3. There will have to be a very good 
justification going forward for source breaking changes.

> 
> For comparison, until recently I did also programming projects on IBM
> mainframes for banks, insurance companies etc. The systems they use consists
> (per company) of literally thousands of Cobol and/or PL/1 programs written
> in all the years from ca 1970 until now. Still, one can take a program written
> in 1970 which compiles and runs flawlessly without any modification!
> All is backward compatible. If you would break backward
> compatibility in this domain you would probably be kicked of the planet..

If we went by this reasoning they should never have changed anything since 
Swift 1. If backwards compatibility and guaranteed compilation is a 
requirement, nothing would ever improve.

> 
> But even if we remain in macOS or iOS development, a huge amount of source
> code has been written in Objective C. Everyone would scream hell if you took
> out or change language elements.. 
> So please don’t. 

Re: [swift-evolution] Class mutation model and value-constrained protocols

[Rod Brown via swift-evolution]

I definitely see Dave’s point here.

It seems to me we can only get generic to the point at which the semantics 
change. So methods that don’t have any mutating consequences can be applied to 
any value such as Structs and Classes, but when the semantic relates to 
mutation, we can only apply that to “All structs” or “all classes” as the 
behaviour changes dramatically how we deal with it. I can’t see any way around 
that, but I’d love to see any ideas how we could avoid it.

I think this is definitely somewhere we need a way to declare a protocol can 
only be implemented on a value type, much like we can say that protocol is only 
available on classes today.

- Rod


> On 6 Jul 2016, at 7:11 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Jul 05 2016, Jonathan Hull  > wrote:
> 
>> Comments inline
>>> A “mutating” keyword on a protocol method is only useful if
>>> you can reason about the mutation in generic code.  
>>> 
>>>  protocol P {
>>>mutating func changeMe()
>>>func noChange() -> Int
>>>  }
>>> 
>>> In other words, given x of some type conforming to P, it should be
>>> meaningful that this is an error:
>>> 
>>>  func f(x: T) {
>>>immutable.changeMe() // can't mutate a "let" binding
>>>  }
>> 
>> Agreed.
>> 
>>> which means that you shouldn't be able to get around that meaning by
>>> writing:
>>> 
>>>  func g(x: T) {
>>>var mutable = x
>>>mutable.changeMe() // OK
>>>  }
>> Now I am confused.  Why should this be illegal?  Doesn’t this work with 
>> structs right now? (you are working on a mutable copy)
> 
> What I meant by “you shouldn't be able get around that” was that the
> code shouldn't change the value of x.
> 
>>> Also, you should be able to reason that both of the following print the same
>>> thing twice, for types whose methods have no external side-effects:
>>> 
>>>  func gg(x: T) {
>>>print(x)
>>>x.noChange()
>>>print(x)
>>>  }
>>> 
>>>  func ggg(x: T) {
>>>print(x)
>>>var y = x
>>>y.changeMe()
>>>print(x)
>>>  }
>> I see the issue here.  Though, it seems to me it is just a more easily
>> discoverable version of an entire class of problem with reference
>> types in general. X could be changed on a different thread too, for
>> example.  or in a nested function call.
>> 
>> You would also still have the same problem with 'let y = x'.
>> 
>>> When T is a class type, it can easily violate *all* of these
>>> expectations.  In other words, classes naturally bypass the mutation
>>> model.
>>> 
>>> If we are going to maintain source stability after Swift 3, it seems
>>> that we either need to address this now, or decide that it won't be
>>> addressed, because of the “viral const” problem.
>>> 
>>> One idea that Jordan and I have floated is that protocols with mutating
>>> methods should be constrained to applying to non-class types.  That
>>> would be a step in the right direction, but, that still leaves cases
>>> like gg able to easily violate expectations when the protocol in
>>> question has no mutating methods.
>> 
>> I really *dislike* the approach of disallowing class types for
>> protocols with mutating methods, unless an additional reference type
>> is added.  I have several protocols which have conforming classes and
>> structs and that that lets you choose reference vs value semantics.
> 
> How do you write generic code that works on both reference and value
> types conforming to such a protocol?
> 
>> I would much rather have us mark class methods as mutating when they
>> change the class’s value, and just having the concept be separate from
>> let/var in that case.
>> 
>>> 
>>> Another possibility would be to formalize the idea of value semantics in
>>> protocol declarations, so that non-class protocols were only allowed to
>>> apply to values.
>> 
>> I would like to have a way to require value semantics in a protocol
>> (similar to how we can require ‘class' now).  I still really want/need
>> the ability to have a protocol which can be adhered to by both value
>> and class types though...
> 
> I really want to see examples of generic code that isn't terribly tricky
> to write correctly so it will work on both kinds of type.
> 
>>> It's also possible that I've overestimated the seriousness of the issue
>>> and we actually can afford to postpone thinking about it until after
>>> Swift 4.
>>> 
>>> Thoughts?
>> 
>> I would vote to postpone to swift 4, and have it be part of a larger
>> discussion involving the marking of side-effects and thread safe
>> mutability.
>> 
>> If you need a stop-gap for Swift 3, I would be in favor of adding the
>> ability to mark a particular protocol as needing to be a value type
>> (not every protocol… just those that are marked as such).  That should
>> give you the guarantees you need for particular projects.
> 
> That's a reasonable stopping point.
> 
> -- 
> Dave
> ___
> swift-evolution mailing 

Re: [swift-evolution] [Proposal] Sealed classes by default

[Rod Brown via swift-evolution]

From my understanding, "Sealed" or whatever we will call it technically 
provides no actual optimisations. We cannot assume the class is final because 
something inside the module may have vended a subclass.

The issue that "sealed" as a concept fills is that you stop people from 
subclassing types that were never specifically designed for subclassing, but 
allows the module to do some subclassing for its own needs because the 
developer understands how the class works.

It also means a developer of the framework can retroactively apply "Final" to 
the class if they've worked out it actually should be final and will never be 
subclass. If the concept of Sealed did not exist, then a framework could never 
finalise a class down the track - users of the framework may have subclassed 
the type, and now the framework is hamstrung by its previous "openness".

Should this be the default? In my opinion, yes.  Allowing subclassing to other 
clients should be explicit. It will tie you down and limit you from developing 
into the future. Allowing subclasses from other clients is a promise for the 
life of your product, and cannot be reneged. On classes that are not designed 
for subclassing, this is ill advised, and on classes you wish to optimise, it's 
a permanent limitation.

While I fear the abuse framework vendors will exercise, by allowing clever 
private hacks, and disallowing obj-c style workarounds, I think the safety and 
longevity of this approach is far more important.

+1 to the concept. I agree "sealed" is not foot wording and can be improved.

- Rod Brown

> On 30 Jun. 2016, at 5:05 am, Michael Peternell via swift-evolution 
>  wrote:
> 
> I'm still unhappy about this "sealed by default" proposal. That really looks 
> like premature optimization to me. Instead there should be some `sealed` 
> keyword. Maybe it should be called `applepublic` :-p Everyone will understand!
> 
> `sealed` classes should be a special optimization used by optimizing 
> developers who ask for it. Don't make it an unwanted and un-asked-for default 
> optimization. The people who care for optimization much will learn about 
> `sealed` and be able to apply the concept in both cases. The people who don't 
> care about performance will just be disappointed by the "implicitly sealed" 
> behavior. And with this proposal, when I read `unsealed` I can never know: 
> "did this developer intend me to be able to subclass this class? or did he 
> just not want to restrict me unnecessarily?" The documenting aspect of 
> `unsealed` is so small.
> 
> And `sealed` is just an optimization; IMHO the magic of static dispatch lies 
> in final classes or final methods. Sealing everything by default just marks 
> many classes and methods as implicitly final (because it can be proven that 
> they are not subclassed). I just don't think that all these theoretical 
> performance improvements are really worth the trouble in practice.
> 
> -Michael
> 
>> Am 29.06.2016 um 20:39 schrieb Vladimir.S via swift-evolution 
>> :
>> 
>> How about `public(extensible)` ?
>> 
>> On 29.06.2016 21:32, John McCall via swift-evolution wrote:
 On Jun 29, 2016, at 11:16 AM, Michael Peternell via swift-evolution 
  wrote:
 Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't 
 really make sense. `internal` declarations are always sealed.
>>> 
>>> Right.
>>> 
>>> If "sealed" is the default behavior for public classes and methods — and I 
>>> don't think the modifier is worth adding unless it's the default — then we 
>>> need a way of "unsealing" classes and methods that's fairly pithy.  I don't 
>>> think a parenthesized spelling is good enough for that.  And we should try 
>>> to make the positive form ("can be overridden") shorter than the negative 
>>> ("cannot be overridden"), because the latter will not usually be written.
>>> 
>>> To me, the ideal spelling would be usable in place of "public".  If it does 
>>> have to be stacked with "public", then I think it ought to be pretty short.
>>> 
>>> "communal"? :)
>>> 
>>> "open" doesn't carry quite the right meaning, and it would need to be 
>>> paired with "public", I think.
>>> 
>>> John.
>>> 
>>> 
 
 -Michael
 
> Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution 
> :
> 
> Do we really need a new keyword? Since we already have syntax like 
> `internal(set)` couldn't we do `internal(unsealed)`, etc.
> 
>> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution 
>>  wrote:
>> On Jun 29, 2016, at 12:15 PM, Michael Peternell 
>>  wrote:
>> 
>> 
>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution 
>>> :
>>> 
>>> +1 for the concept of a "sealed” class.
>>> -1 for making it default.
>> 

Re: [swift-evolution] WWDC Meetup

[Rod Brown via swift-evolution]

I'd be interested in catching up. Was curious if there was going to be a meet 
up, either formal or informal. Sounds good.

-Rod

> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>  wrote:
> 
> I imagine that during WWDC a non-negligible proportion of the Swift Open 
> Source contributors will be in or around San-Francisco. I’d very much like to 
> profit from that opportunity to meet-up, get to know each other, talk Swift 
> over some beers! Is anybody interested? If yes, any ideas for location? I can 
> setup a Doodle once I see enough interest.
> 
> Looking forward to meet you!
> ___
> 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] Protected Access Level

[Rod Brown via swift-evolution]

I have to agree with Charlie Monroe that while this is doable, it's clear this 
is a workaround to a problem, not a viable long term language solution.

- Rod



Sent from my iPhone
> On 30 May 2016, at 2:49 PM, Callionica (Swift) 
>  wrote:
> 
> I've written up how to provide protected access control for Swift code today 
> here:
> 
> http://www.callionica.com/developer/#swift-protected
> 
> No compiler changes necessary for this technique and it distinguishes between 
> methods that can only be overridden and methods that can be both called and 
> overridden.
> ​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Rod Brown via swift-evolution]

Brent,

You make a very good point about the fact internal is not necessarily the same 
as subclass, something I hadn’t considered.

I think that the level of exposure these APIs then get - ultimately Public 
within frameworks - is too unrestricted. At least in Objective-C, we can vet 
the headers to break classes into separate sections where we don’t disclose 
certain headers to show something by default. Can we think of a way to allow 
opt-in access?

This ultimately gets into one of my major sore points with Swift: Framework 
Generated Headers suck. The Framework story for Swift seems shockingly ill 
conceived at this time. I could never imagine Apple shipping a framework with 
the current Framework setup… but I’m going into the weeds...

-Rod


> On 30 May 2016, at 10:03 AM, Brent Royal-Gordon  
> wrote:
> 
>> 1. Methods and properties that only subclasses must access, but other code 
>> has no business updating. An example of this UIGestureRecognizer. State 
>> machine type access is something where external items should not access, but 
>> internal state may require the rights to update.
> 
> But again, "external" does not necessarily mean "non-subclass", and 
> "internal" does not necessarily mean "subclass". A particular subclass might 
> not require access, and a helper type/function might require access.
> 
> This insight—that the type graph doesn't always reflect the boundaries of 
> concerns—is the very basis of Swift's current access control design. It's the 
> reason why `private` (soon to become `fileprivate`) doesn't grant visibility 
> to extensions on the same type in different files, but *does* grant it to 
> extensions on different types in the same file. This is an important 
> innovation in Swift's access control design, and we shouldn't ignore it when 
> we're thinking about `protected`.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [Proposal] Protected Access Level

[Rod Brown via swift-evolution]

I agree that we should be looking for what makes sense, not just what we’ve 
seen in other languages. That said, there seems a lot of hate for OOP in 
general that seems to be clouding people’s vision here.

I think that “protected” as a form of access control is exactly what we want: 
rights that subclasses should be allowed, but other classes should not. 
Generally they refer to internal state that only the class itself, or its 
subclass, has any business either updating or calling.

Lets drop the word “protected” for a second and actually examine the use cases 
for differing access control in classes. I think the best example of this in 
different contexts are:

1. Methods and properties that only subclasses must access, but other code has 
no business updating. An example of this UIGestureRecognizer. State machine 
type access is something where external items should not access, but internal 
state may require the rights to update.

2. Methods and properties that should be overridable, but are helper methods 
and shouldn’t be called by external methods, and perhaps shouldn’t be even 
called directly. This includes -layoutSubviews on UIView, a multitude of other 
methods in UIKit, etc. Thus I think Brent had a good point that calling a 
method might need to have different access rights to overriding it.

I think #1 shows specifically the need for access control for subclasses only, 
and thus a ‘protected’- style access control level.
I think #2 shows a need to differentiate the access rights of calling a method 
from access rights to see or override the method.

While we can find workarounds that obfuscate access, these aren’t access 
controls, they’re convoluted workarounds to avoid correcting our access control 
rules in the first place.

How do these things bridge into Objective-C?
Protected doesn’t make sense in Objective-C. You cannot subclass a Swift Class 
in Objective C, so overriding is irrelevant. I suspect the rule should be 
simple: Anything Protected should not be visible to Objective-C, much like 
private is hidden currently.

- Rod


> On 30 May 2016, at 8:45 AM, Leonardo Pessoa via swift-evolution 
>  wrote:
> 
> Vanderlei, my point in bringing such topics to this discussion is to make 
> everyone here think if we're trying to really enhance the language within its 
> intended purpose or if we're trying to change the language into something 
> else were familiar with from other languages we work/ed with just because 
> we're used to work like that. I just started thinking about this today and 
> just cannot stop now. No intention to start a war here but I think everyone 
> should ask themselves this for every proposed change to the language.
> 
> About the topic at-hand, we have to remember Swift is bridged to Objective-C, 
> which has no protected (or abstract). How do you propose these protected 
> members be bridged should the proposal pass?
> From: Vanderlei Martinelli via swift-evolution 
> 
> Sent: ‎29/‎05/‎2016 06:56 PM
> To: swift-evolution 
> Subject: Re: [swift-evolution] [Proposal] Protected Access Level
> 
> Thank you all for your comments. :-)
> 
> Well... My goal is to keep the thing really simple and do not start a new 
> "OOP x POP" (or "something" x "other thing") war.
> 
> "Protected" access level is not a new concept at all (except for the Swift 
> language), so I did not propose anything preposterous.
> 
> Of course in the Swift of my dreams we also have "abstract" access level 
> modifier, "protected" access level, *real* "private" access level and "file" 
> access level modifier (along with many, many other things, of course). But 
> this proposal is not about this. It is only about include the "protected" 
> access level.
> 
> There is, however, something that I need to get off my chest: I really would 
> like to have the freedom to go to the depths with protocols as well with 
> classes. I work in real apps everyday that uses Cocoa frameworks (based on 
> classes) and these apps must be shipped and I like them well written. Maybe 
> am I insane for proposing a better support for classes in Swift? If so, this 
> explains why every time I suggest better support for classes in Swift there 
> is an endless discussion and someone proclaims the death of OOP and is it. 
> OK... Maybe someday we will not have more classes in Swift. Until there: the 
> current language status is the best way to handle OOP in Swift? Or is there a 
> better way? I think there is.
> 
> 
> Regards,
> 
> Vanderlei Martinelli
> 
> 
> 
> 
> 
> 
> 
> On Sat, May 28, 2016 at 7:52 PM, Vanderlei Martinelli 
> > wrote:
> Hello.
> 
> 
> This is the first draft. I'd like to know your opinion about it.
> 
> (I know that this subject could have been discussed before. If so, please 
> indicate me the correct thread to follow and interact.)
> 
> 
> Regards,

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Rod Brown via swift-evolution]

+1. Completely agree with Brent's views here.

On 28 May 2016, at 9:15 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> The idea is simple:
>> 
>>• Can we make return keyword optional in cases like this?
>>• Shouldn’t this behave like @autoclosure or @noescape?
> 
> This actually doesn't have anything to do with @autoclosure or @noescape. Any 
> one-expression closure can omit the `return` statement and have an inferred 
> return type.
> 
>> type A {
>>var characters: [Character] = …
>>var string: String { String(self.characters) }
>>var count: Int { 42 }
>> }
> 
> Despite those inaccuracies, I do think that it's a good idea to permit 
> single-expression accessors to omit the `return` statement; it will make them 
> much less clunky. I would even extend this to cases where you use the `get` 
> keyword:
> 
>var string: String {
>get { String(self.characters) }
>set { characters = Array(newValue.characters) }
>}
> 
> -- 
> 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-0083: Remove bridging conversion behavior from dynamic casts

[Rod Brown via swift-evolution]

Yes, I have to say Doug seems to be on the money with the concerns I hold with 
the current proposals about stripping out the "Objective-C Magic" in the bridge 
between Swift and Objective C.

There seems to be a strong push recently to rip out these APIs with clearly 
well meaning intent, but lack of consideration for the many APIs that this will 
make rather uncomfortable to use.

I think this request tends to gloss over the fact that a vast majority of Swift 
code is still written for iOS and OS X and utilizes the Objective-C APIs 
extensively. As Doug points out, we are chipping away very fast at the bridging 
simplicity that made Swift brilliant to use on Apple Platforms, and I don't 
think the gains begin to approach the losses from these changes.

While I agree strongly with the concept of wiping such bridges out where 
possible in concept, I am pragmatic that perhaps doing so is not in the best 
interests of Swift's usability in the short term at least. I think because we 
haven't experienced writing an Objective-C based app in Swift, we might be 
getting lost in the "concept" of stripping bridging, while missing the real 
world implications of such actions.

- Rod

> On 25 May 2016, at 2:49 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> I am way late, but I share Brent’s concerns. I don’t think this addresses 
>> the very common case of “getting a String out of a heterogeneous dictionary”.
>> 
>> let name = plist[“name”] as! String
>> 
>> becomes one of these:
>> 
>> let name = plist[“name”] as! NSString as String
>> let name = String(plist[“name”] as! NSString)
>> let name = String(forceBridging: plist[“name”]) // not in the proposal
>> 
>> none of which I’m particularly happy with. 
> 
> I am also way, way late, here, but this ties into a philosophical concern I 
> have. The bridging that we have in place was designed to put Swift’s value 
> types front-and-center in the Swift experience, even when interoperating with 
> Objective-C APIs using reference-semantic types. It was a specific goal that 
> one should not have to juggle between Swift.Array and NSArray—NSArray is 
> bridged away in imported APIs, Swift arrays implicitly convert to AnyObject 
> when working an AnyObject-based API, dynamic bridging conversions would pass 
> through NSArray to get to Swift arrays, etc. So while one can certainly reach 
> for NS(Mutable)Array in Swift, one should not *have* to do so in Swift.
> 
> This proposal and SE-0072 are chipping away at that bridging story, making 
> the explicit use of NSArray/NSString/etc. required for interoperability with 
> Objective-C APIs. While it does make the language more explicit and 
> predictable (and dynamic casting more efficient!), it makes the use of these 
> bridged reference-semantic more prevalent, which may lead to more overall 
> confusion about which set of types to use. There might even be a portability 
> argument: the current scheme lets you gloss over Any vs. AnyObject (which is 
> a current difference we see in ObjC Foundation vs. corelibs Foundation).
> 
>   - Doug
> 
>> 
>> Jordan
>> 
>> 
 On May 19, 2016, at 02:31, Brent Royal-Gordon via swift-evolution 
  wrote:
 
* What is your evaluation of the proposal?
>>> 
>>> The review is technically over, but I don't believe a decision has been 
>>> announced yet, so...
>>> 
>>> I am generally in favor, but I have a serious concern about the readability 
>>> of certain conversions with this change. To wit, conversions like these:
>>> 
>>> myArray as! [NSView]
>>> myDictionary as! [String: NSView]
>>> 
>>> Are about to become something more like these:
>>> 
>>> [NSView](forcedLazyBridging: myArray)
>>> [String: NSView](forcedLazyBridging: myDictionary)
>>> 
>>> Or these:
>>> 
>>> Array(forcedLazyBridging: myArray)
>>> Dictionary(forcedLazyBridging: myDictionary)
>>> 
>>> Either option is a significant regression in code readability compared to 
>>> the status quo.
>>> 
>>> It's enough to make me wonder if we shouldn't have special-cased conversion 
>>> methods for NSArray, NSDictionary, and NSSet:
>>> 
>>> myArray.of(NSView)  // returns [NSView]
>>> myDictionary.of(NSView, for: String)// returns [String: NSView]
>>> mySet.of(NSView)// returns 
>>> Set
>>> 
>>> On the other hand, if you *don't* have to specify an element type, these 
>>> aren't so bad:
>>> 
>>> Array(forcedLazyBridging: myArray)
>>> Dictionary(forcedLazyBridging: myDictionary)
>>> 
>>> And it gets even better if you use something a little saner than 
>>> `forcedLazyBridging` for the label.
>>> 
* Is the problem being addressed significant enough to warrant a change 
 to Swift?
>>> 
>>> Yes. Conversions are