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

[David Hart via swift-evolution]

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

David.

> Jordan
> 
> 
> 
>> On Aug 9, 2017, at 08:19, Zach Waldowski via swift-evolution 
>> > wrote:
>> 
>> I disagree. Closed is indeed the stronger guarantee, but APIs are designed 
>> differently in Swift; closed is a sensible default. We shouldn’t need to 
>> define new keywords and increase the surface area of the language for 
>> something that has verisimilitude with the existing open syntax.
>> 
>> Sincerely,
>>   Zachary Waldowski
>>   z...@waldowski.me 
>> 
>> 
>> On Wed, Aug 9, 2017, at 06:23 AM, David Hart via swift-evolution wrote:
>>> 
>>> 
>>> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution 
>>> > wrote:
 Hi Jordan, is that only me or haven't you metioned the default should be 
 applied to all new enums? Personally I'd say that 'closed' should be the 
 default and the 'open' enum would require an extra keyword.
>>> 
>>> I think it should definitely be the other way round for public enums 
>>> because closed is the stronger guarantee. Final is the default for classes 
>>> because open is the stronger guarantee. That’s probably why we should not 
>>> use the same keywords.
>>> 
 Now about the keyword itself. Here are two keywords that IMHO nail their 
 behavior down to the point:
 
 finite enum A {} - so to say a closed enum (default)
 infinite enum B {} - so to say an open enum (requires default case in a 
 switch statement)
 
 If you think the default should be the other way around, than feel free to 
 switch that. 'finite' also implies that the enum connot ever be extended 
 with more cases (to become infinite), which was also mentioned in your 
 email.
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 Am 9. August 2017 um 00:27:53, Jordan Rose via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> 
> 
> 
> 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 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Adrian Zubarev via swift-evolution]

Well, if there is one, then I apologize for bothering anyone. I just assumed it 
would be included in the proposal itself, and I couldn't find it myself. ;)  

Thank you David.

--  
Adrian Zubarev
Sent with Airmail  

Am 10. August 2017 um 07:30:16, David Hart 
(da...@hartbit.com(mailto:da...@hartbit.com)) schrieb:

>  
>  
> > On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution 
> >  wrote:  
> >  
> > Hi there, I don’t mean to be rude or something, nor do I want to hold the 
> > review process up from succeeding, but where is the branch with the 
> > implementation?  
> >  
> >  
> > Quote:  
> >  
> > > The proposal phase for Swift 4 is now officially over
> >  
> >  
> > I hope that the core team does not pick proposals they like, for instance 
> > their own ones, and just skip the restriction of an implementation. I just 
> > want to make sure that everyone plays with the same rules, so that it will 
> > be fair for everyone
> >  
> >  
> >  
>  
> I don’t know what gave you the impression the Core Team would bend the rules 
> or play favorites. It’s not authored from an Apple engineer and, if you have 
> a look at the PR for the proposal, there is a link to the implementation: 
> https://github.com/apple/swift/pull/9619
> >  
> > To strengthen up my criticism, here is a PR of a different proposal which 
> > didn’t made it into Swift 4 but which was asked for an implementation 
> > yesterday:  
> >  
> >  
> > https://github.com/apple/swift-evolution/pull/707
> >  
> >  
> > Have a nice review ;)
> >  
> >  
> >  
> >  
> >  
> >  
> > Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
> > (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:
> >  
> > >  
> > > And of course, the correct proposal link is:
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
> > >  
> > >  
> > > > On Aug 9, 2017, at 4:10 PM, Chris Lattner 
> > > >  wrote:
> > > >  
> > > > I forgot to mention that the implementation of this feature is 
> > > > available here:
> > > > https://github.com/apple/swift/pull/9619
> > > >  
> > > > -Chris
> > > >  
> > > >> On Aug 9, 2017, at 4:08 PM, Chris Lattner 
> > > >>  wrote:
> > > >>  
> > > >> Hello Swift community,
> > > >>  
> > > >> The review of SE-0185 - "Synthesizing Equatable and Hashable 
> > > >> conformance" begins now and runs through August 15, 2017. The proposal 
> > > >> is available here:
> > > >> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.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:
> > > >>  
> > > >> 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,
> > > >>  
> > > >> Chris Lattner
> > > >> Review Manager
> > > >>  
> > > >>  
> > > >  
> > > > ___
> > > > swift-evolution-announce mailing list
> > > > swift-evolution-annou...@swift.org(mailto:swift-evolution-annou...@swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> > >  
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >  
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[David Hart via swift-evolution]

> On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hi there, I don’t mean to be rude or something, nor do I want to hold the 
> review process up from succeeding, but where is the branch with the 
> implementation? 
> 
> Quote: 
> 
> The proposal phase for Swift 4 is now officially over
> I hope that the core team does not pick proposals they like, for instance 
> their own ones, and just skip the restriction of an implementation. I just 
> want to make sure that everyone plays with the same rules, so that it will be 
> fair for everyone
> 
I don’t know what gave you the impression the Core Team would bend the rules or 
play favorites. It’s not authored from an Apple engineer and, if you have a 
look at the PR for the proposal, there is a link to the implementation: 
https://github.com/apple/swift/pull/9619 
To strengthen up my criticism, here 
is a PR of a different proposal which didn’t made it into Swift 4 but which was 
asked for an implementation yesterday: 
> 
> https://github.com/apple/swift-evolution/pull/707 
> 
> Have a nice review ;)
> 
> 
> 
> 
> 
> Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> And of course, the correct proposal link is:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>>  
>> 
>> 
>> 
>> > On Aug 9, 2017, at 4:10 PM, Chris Lattner > > > wrote:
>> > 
>> > I forgot to mention that the implementation of this feature is available 
>> > here:
>> > https://github.com/apple/swift/pull/9619 
>> > 
>> > 
>> > -Chris
>> > 
>> >> On Aug 9, 2017, at 4:08 PM, Chris Lattner > >> > wrote:
>> >> 
>> >> Hello Swift community,
>> >> 
>> >> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
>> >> begins now and runs through August 15, 2017. The proposal is available 
>> >> here:
>> >> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.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:
>> >> 
>> >> 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,
>> >> 
>> >> Chris Lattner
>> >> Review Manager
>> >> 
>> >> 
>> > 
>> > ___
>> > swift-evolution-announce mailing list
>> > swift-evolution-annou...@swift.org 
>> > 
>> > https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>> > 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Adrian Zubarev via swift-evolution]

Hi there, I don’t mean to be rude or something, nor do I want to hold the 
review process up from succeeding, but where is the branch with the 
implementation?

Quote:

The proposal phase for Swift 4 is now officially over
I hope that the core team does not pick proposals they like, for instance their 
own ones, and just skip the restriction of an implementation. I just want to 
make sure that everyone plays with the same rules, so that it will be fair for 
everyone.

To strengthen up my criticism, here is a PR of a different proposal which 
didn’t made it into Swift 4 but which was asked for an implementation yesterday:

https://github.com/apple/swift-evolution/pull/707

Have a nice review ;)




Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
(swift-evolution@swift.org) schrieb:

And of course, the correct proposal link is:
https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md


> On Aug 9, 2017, at 4:10 PM, Chris Lattner  wrote:
>  
> I forgot to mention that the implementation of this feature is available here:
> https://github.com/apple/swift/pull/9619
>  
> -Chris
>  
>> On Aug 9, 2017, at 4:08 PM, Chris Lattner  wrote:
>>  
>> Hello Swift community,
>>  
>> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
>> begins now and runs through August 15, 2017. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.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:
>>  
>> 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,
>>  
>> Chris Lattner
>> Review Manager
>>  
>>  
>  
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] Enums and Source Compatibility

[Charlie Monroe via swift-evolution]

Hi Jordan,

let's say I'm writing my custom number formatter and I switch over 
NSNumberFormatterStyle (NumberFormatter.Style in Swift) - the question always 
is what to do with the default case - it's a value that I am not 
programmatically counting with. I would personally just put in fatalError with 
a description that it was passed an unhandled style. Listing all enums in 
Foundation, I can see using most of them this way.

I personally have most of my switches exhaustive, mainly for the sake of being 
warned/error'ed when a new case is introduced - I've just done a quick search 
through my projects and I use default: usually for switching over non-enums 
(strings, object matching, ints, ...).

Maybe I'm in the minority here... Seemed like a good practice to me - usually 
the enum doesn't have but a few items on the list and you usually don't handle 
just 1-2 cases in your switch, which makes the default label save you 1-2 lines 
of code that can save you from unnnecessarily crashing during runtime...

> On Aug 10, 2017, at 1:57 AM, Jordan Rose  wrote:
> 
> Hi, Charlie. This is fair—if you're switching over an open enum at all, 
> presumably you have a reason for doing so and therefore might want to handle 
> all known cases every time you update your SDK. However, I think in practice 
> that's going to be rare—do you have examples of exhaustive switches on SDK 
> enums that exist in your own app?
> 
> (There's an additional piece about how to handle cases with different 
> availability—there's nowhere obvious to write the #available.)
> 
> I suspect marking SDK enums "closed" will be much easier than nullability, 
> simply because there are so few of them. Here's some data to that effect: out 
> of all  60 or so NS_ENUMs in Foundation, only 6 of them are ones I would 
> definitely mark "closed":
> 
> - NSComparisonResult
> - NSKeyValueChange / NSKeyValueSetMutationKind
> - NSRectEdge
> - NSURLRelationship
> - maybe NSCalculationError
> 
> There are a few more, like NSURLHandleStatus, where I could see someone 
> wanting to exhaustively switch as well, but the main point is that there is a 
> clear default for public enums, at least in Objective-C, and that even in a 
> large framework it's not too hard to look at all of them.
> 
> (Note that NSComparisonResult is technically not part of Foundation; it lives 
> in the ObjectiveC module as /usr/include/objc/NSObject.h.)
> 
> Jordan
> 
> 
>> On Aug 8, 2017, at 21:53, Charlie Monroe > > wrote:
>> 
>> While I agree with the entire idea and would actually use behavior like this 
>> in a few instances, I feel that in most cases, you would simply put 
>> 
>> default:
>>  fatalError()
>> 
>> The huge downside of this is that you no longer get warned by the compiler 
>> that you are missing a case that was added - a common thing I personally do 
>> (and I have a feeling I'm not alone) - add an enum case, build the app, see 
>> what broke and fix it - as you get warnings/errors about the switch not 
>> being exhaustive. You find this out during runtime (if you're lucky), 
>> otherwise your end user.
>> 
>> As you've noted all enums from ObjC would need to be marked with an 
>> annotation marking if they are closed - which given the way nullability is 
>> still missing in many frameworks out there, I think would take years.
>> 
>> I'd personally expand this proposal by introducing switch! (with the 
>> exclamation mark) which would allow to treat open enums as closed. Example:
>> 
>> // Imported from ObjC
>> open enum NSAlert.Style { ... }
>> 
>> switch! alert.style {
>> case .warning:
>>  // ...
>> case .informational:
>>  // ...
>> case .critical:
>>  // ...
>> }
>> 
>> The force-switch would implicitely create the default label crashing, 
>> logging the rawValue of the enum.
>> 
>> Thoughts?
>> 
>>> On Aug 9, 2017, at 12:28 AM, Jordan Rose via swift-evolution 
>>> > 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 
>>> 

Re: [swift-evolution] How does "Sequence.joined" work?

[Daryle Walker via swift-evolution]

> On Aug 9, 2017, at 12:19 PM, Taylor Swift  wrote:
> 
> On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution 
> > wrote:
> 
>> On Aug 8, 2017, at 6:45 PM, Geordie Jay > > wrote:
>> 
>> Daryle Walker via swift-evolution > > schrieb am Di. 8. Aug. 2017 um 21:25:
>>> On Aug 8, 2017, at 12:35 AM, Félix Cloutier >> > wrote:
>>> 
>>> All this means is that `joined()` does not create an array that contains 
>>> the new result. It's only as magic as the COW semantics on arrays.
>> 
>> So you’re saying the COW semantics for Array and other standard library 
>> types have secret references/pointers that work even for “let”-mode objects, 
>> and the Sequence variants the various forms of “joined” need use a 
>> Sequence/Collection of those secret references?
>> 
>> I know nothing about this specific type under the hood and your question 
>> stumped me when I first saw it as well, so take this with a grain of salt:
>> 
>> I think it's basically just storing the arrays internally (as let) and when 
>> you iterate through the collection it just goes through the subsequences one 
>> by one, when the last index of the first is reached it begins with the next 
>> subsequence.
>> 
>> As for how it avoids creating new storage, simple. As someone else 
>> mentioned, this is no more magic than Copy On Write for normal arrays.
>> 
>> let a = [1,2,3]
>> let b = a // this doesn't produce a copy of the underlying buffer.. I.e. 
>> value semantics but only one buffer needed
>> 
>> ^^^ This is the take-home message. And your intuition about COW is correct: 
>> its internal storage is a reference type containing a buffer pointer. When 
>> (and only when) a mutation occurs, the buffer is copied and the new storage 
>> becomes the backing for the resulting struct. Any existing copies remain 
>> unchanged (and truly immutable) because they keep their original storage.
>> 
>> https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift
>>  
>> 
>> 
>> 
>> So with that understanding of COW, it becomes easy to imagine all sorts of 
>> containers that don't require additional storage for their contents:
>> 
>> struct JoinedSequenceOfThreeArrays {
>>   let array1: [T]
>>   let array2: [T]
>>   let array3: [T]
>> }
>> 
>> // still only one array buffer storage is required for all of this:
>> let c = JoinedSequenceOfThreeArrays(array1: a, array2: a, array3: b)
>> 
>> Does that make sense?
> 
> Mostly, then I realized a flaw with this explanation. Your theory implies 
> that “joined” avoids creating new storage by betraying that and actually 
> copying the containers, but said containers use-COW/reference-remote-storage 
> themselves. Then what happens when a Sequence uses scoped storage for its 
> items? (Example: the mythical “just slap Collection on a tuple and call it an 
> array” type.) Either “joined” uses a different no-copy technique or it’s 
> lying about saving on storage (and the lack of scoped-storage Sequences means 
> no one has called them on it yet).
> 
> I don’t see any contradiction here. A tuple is a value type; it has no 
> concept of copy-on-write because it’s copy-on-read. So JoinedSequence will 
> store a copy of the tuple instead of a buffer reference

Besides meaning the explanation for “joined” is lying, what if the value type 
is large enough that copies should be minimized?

Hmm, it seems that there’s a hole in the language in that value-type “let”-mode 
instances cannot be aliased/referenced.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

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

[Zach Waldowski via swift-evolution]

On Wed, Aug 9, 2017, at 08:49 PM, Jordan Rose via swift-evolution wrote:> Ah, I 
forgot to mention: per my response to Charlie, the vast majority
> of enums in ObjC Foundation (80-90%) seem to be "open". I should have
> put that in the "open" side of the list. I'm not convinced that "APIs
> are designed differently in Swift" to the extent where you'd actually
> expect most enums to be closed; rather, I suspect most Swift API
> designers haven't been thinking too hard about exhaustive switches,
> and certainly not about binary compatibility, which becomes relevant
> at least for Apple once Swift libraries become part of the SDK.
Let me expound a bit. I was erroneously including string enums in my
supposition that APIs are designed differently, but overall I still
stand behind it.
Foundation is designed for paper over lots of different computing
concepts  and underlying libraries with similar-ish APIs — in a good
way! From the eyes of an API consumer, configuring something like a
formatter to behave how they want is basically a write-only proposition.
This makes simple enum cases a great design choice for hiding  swaths of
different underlying implementations  (ex: NSDateFormatterShortStyle
having a different meaning per-locale.)
Say we split up Foundation's enums  roughly into categories. You have
your policies (NSURLCacheStoragePolicy, NSDateFormatterStyle),
states/answers (NSURLSessionTaskState, NSQualityOfService), and, well,
lists (NSSearchPathDirectory, NSStringEncoding). Given those, I’d say
protocols, generics, and zero-cost abstractions are frequently a better
choice (but not always). For  instance, IMHO a closed protocol better
models commonly-used styles.
I know you ask  to only consider open/closed enums in isolation to make
it most likely to succeed, but there’s the frequent complaint that Swift
has many ways to accomplish the same thing; I think resilience will land
best with the community if it has a few really solid throughlines with
the rest of the language, open/closed I hope being among them.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


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

Re: [swift-evolution] Pitch: Improved Swift pointers

[Xiaodi Wu via swift-evolution]

On Wed, Aug 9, 2017 at 8:22 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jul 19, 2017, at 11:21 AM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What about `value:`?
>
> `ptr.initialize(value: value)`
> `ptr.initialize(value: value, count: 13)`
> `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)`
>
>
> Doesn't read as a sentence. Consider how "initialize to 3" sounds
> different from "initialize value 3".
>
> Personally, I'd go with:
>
> ptr.initialize(to: value)
> ptr.initialize(to: value, repeatCount: 3)
>
> (Or just `repeat`/`repeating` if you don't feel like you need the word
> "count" to disambiguate.)
>

Per Swift API naming guidelines, initializers don't have to read as
sentences IIRC, and I'd be inclined to grant a function named
`initialize(_:)` the same courtesy.

For arrays, `repeating:` labels the repeating value, not the number of
times it repeats, and the analogous labels here would indeed be
`ptr.initialize(repeating: value, count: 3)`. I agree with the observations
above that `repeating` looks weird if the default and most common use is 1,
though; `value` is fine, I guess--or the Swiftism `pointee`?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Howard Lovatt via swift-evolution]

>
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance".
> The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0185-synthesize-equatable-hashable.md
>
> • What is your evaluation of the proposal?
>

Overall a worthwhile addition. Specific comments:

   1. Opt in a good choice, see 2 below.
   2. Opt in should be for trivial enums as well, even though this is a
   breaking change it is clearer.
   3. The hash function should be more tightly specified, without
   specifying what it does it is hard to know if it is appropriate to use in a
   given application. I am not particularly advocating one hash function over
   another, but rather an explanation of what the user can expect. For example
   is hash consistent across invocations on the same machine and is it
   dependent upon the order of stored property declaration. It should also
   state that the hash function is not consistent across machines, since 32
   and 64 bit machines will have a different hash (as an implementation detail
   the hash function should be required to be different on different machines
   of the same architecture so that people do not mistakenly assume that for
   example all 64 bit machines produce the same hash). There has been a number
   of problems with the Java, Python, etc hash functions because these items
   were not specified.
   4. Specifying the exact hash function to be used could be considered, if
   the hash function is known then dictionary and dictionary like structures
   can be optimized.
   5. Synthesis by extensions in the same file should be considered, now
   that private extends to the file. (As an aside: also Codeable.)
   6. It is quite possible to have class types automatically synthesize
   hash and equality by calling super.hashValue and super.equals(Self). The
   omission seems at odds with treating classes equally to values.
   7. Same for tuples (should be included).
   8. Transient is a useful marker in Java and therefore should be
   considered (would also work well with Codeable).

Hope the above doesn't read negatively, the proposal as is would be a great
addition - the above are suggested improvements rather than show stopping
musts.


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

Yes, I even have a library function that mimics this because I got fed up
of writing  boiler plate.

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

Yes, part of rounding off the language.


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

Yes, see comments above based on experience with other languages


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

Something I have wanted for a while because I have used this feature in
other languages.

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

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

[Zach Waldowski via swift-evolution]

On Wed, Aug 9, 2017, at 08:42 PM, Jordan Rose via swift-evolution wrote:> - 
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.)
>From someone frequently working on teams or unfamiliar codebases, it’s
really heard to know whether “default: fatalError()” is a smell or not
without memorizing the  surface area of every API your app works with.
> … That brings us to one more concern: how different should binary
> frameworks be from source frameworks?
As few as possible. Realistically, I understand there must be  some, but
I feel like they need to be there for awfully good reasons. The
differences between app targets, framework/library targets, and
playgrounds feel arbitrary unless you understand parts of the language
very fully.
Some debugging techniques (or even just saving-time-rebuilding
techniques) involve using a binary framework and swapping it for another
binary with extra instrumentation or a source version for full
instrumentation, or vice-versa as you ossify a PoC feature into being
production-ready. It would be awful to break source compatibility as
this happens because an API you’re consuming changes behavior according
to the compiler. (I can hear my graybeard coworkers already - “It’s the
same code!”)
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


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

Re: [swift-evolution] [swift-evolution-announce] Swift 5: start your engines

[John McCall via swift-evolution]

> On Aug 9, 2017, at 8:52 PM, Howard Lovatt via swift-evolution 
>  wrote:
> I am not against these changes, of requiring an implementation, but I am a 
> little nervous. Let me expand.
> 
> I was involved in the Java Coin initiative for community driven changes to 
> Java 7. In that process the implementation barrier was set very high and it 
> effectively meant that only changes from Sun got through, a number of people 
> put considerable effort in only for the proposals to be rejected. I felt the 
> process was in the end a little disingenuous and I think that view was held 
> by many, perhaps tellingly the process has never run again for subsequent 
> Java versions.
> 
> So my cautionary note is that this requirement of implementation requires 
> careful stewardship and in particular there needs to be some means of getting 
> 'in principle' approval before the implementation stage. If done correctly it 
> could work very well.

This seems very sensible to me.  Certainly we would want some way of flushing 
out "in principle" concerns before too much implementation time gets spent.

John.

> 
>   -- Howard.
> 
> On 9 August 2017 at 02:23, Ted Kremenek  > wrote:
> Hi everyone,
> 
> The proposal phase for Swift 4 is now officially over, and the release is now 
> in endgame engineering convergence for an expected release later this year.  
> Swift 4 has turned out to be one of the highest quality, well-rounded 
> releases of Swift, and I am grateful to everyone in the community who made 
> this release come together!
> 
> Now it is time to turn our attention to Swift 5.  I have just posted updates 
> to the README.md file on the swift-evolution repository, which outlines the 
> core themes and focus areas for Swift 5:
> 
>   https://github.com/apple/swift-evolution 
> 
> 
> and a more persistent URL (invariant to future README.md changes):
> 
>   
> https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md
>  
> 
> 
> I am not going to repeat all of that information here, but I wanted to 
> highlight a few important things.
> 
> ## ABI Stability
> 
> First, ABI stability is the center focus of Swift 5 — and we will pivot much 
> of our prioritization of efforts for Swift 5 around it.  With Swift 4, ABI 
> stability was a strong goal.  In Swift 5, it is a *requirement* of the 
> release.  Whatever ABI we have at the end of Swift 5 is the ABI that we will 
> have.  ABI stability is an important inflection point for the maturity of the 
> language, and it cannot be delayed any longer.
> 
> Please note that there is a difference between ABI stability and module 
> stability.   If you are not aware of the difference — which is rather 
> important — please read the first few paragraphs of the ABI stability 
> manifesto:
> 
>   https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md 
> 
> 
> Module stability is a stretch goal for Swift 5, but even without module 
> stability we can still achieve the primary value of ABI stability.
> 
> ##  Other focus areas (including laying the groundwork for concurrency)
> 
> There are several other areas mentioned for Swift 5 which I won’t repeat 
> here, but there is a general theme of refining and broadening out the core 
> ergonomics of the language and standard library.
> 
> One of those that I wanted to highlight is laying the groundwork for 
> concurrency.  It is a non-goal of Swift 5 to roll out a full new concurrency 
> model.  That is simply too large an effort to do alongside ABI stability.  
> However, it is important that we start making progress on discussing the 
> directions for concurrency and laying some of the groundwork.  This may take 
> the form of specific enhancements to the language that get implemented, 
> depending on where the discussions for concurrency lead and how they align 
> with the priorities for delivering ABI stability in Swift 5.
> 
> ## Changes to the language evolution process
> 
> Last, I want to highlight important changes to the evolution process:
> 
>   https://github.com/apple/swift-evolution 
> #evolution-process-for-swift-5 
> 
> 
> With Swift 4, the release period was divided up into “stage 1” and “stage 2” 
> for setting guidelines for the kind of evolution proposals that were in scope 
> for the release.  This was needed to establish focus — especially after the 
> churn we saw during Swift 3 — on some core themes that were aligned with 
> converging the language towards source & ABI stability.  One downside is that 
> “stage 2” opened up discussion for 

Re: [swift-evolution] Pitch: Improved Swift pointers

[Brent Royal-Gordon via swift-evolution]

> On Jul 19, 2017, at 11:21 AM, Taylor Swift via swift-evolution 
>  wrote:
> 
> What about `value:`?
> 
> `ptr.initialize(value: value)`
> `ptr.initialize(value: value, count: 13)`
> `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)`

Doesn't read as a sentence. Consider how "initialize to 3" sounds different 
from "initialize value 3".

Personally, I'd go with:

ptr.initialize(to: value)
ptr.initialize(to: value, repeatCount: 3)

(Or just `repeat`/`repeating` if you don't feel like you need the word "count" 
to disambiguate.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

Hi, Vladimir. I think framing this as a consumer decision is the wrong place to 
start. There are some enums that definitely make sense to be "closed", all the 
time, with no additional annotations, including Foundation.NSComparisonResult 
and, well, Swift.Optional. (Yes, Optional is special, and we could always 
handle it specially if we needed to, but it would be nice if it used the same 
logic as everything else.)

Beyond that, I think something like what you and Charlie describe (your 
'@exhaustive', Charlie's 'switch!') could make sense, as a way to provide a 
deterministic behavior while still getting compiler warnings for not being 
exhaustive. (Probably the only supported behavior here would be trapping, since 
there is no way to test such a scenario with the libraries you currently have.) 
But I'd like to see a real-world example of exhaustively switching over an enum 
in the SDK before designing a feature around this; I strongly suspect it's not 
something we need…

…in the binary framework case. It may still be interesting for source 
frameworks, particularly C enums in those source frameworks.

Jordan


> On Aug 9, 2017, at 09:57, Vladimir.S  wrote:
> 
> Sorry if I misunderstood the subject, but shouldn't this also be a *consumer* 
> decision, when one wants to keep own switch exhaustive or it is OK to process 
> all possible future cases in 'default'?
> 
> If enum is 'closed' - nothing is changed, as I understand, we have the same 
> rules for switch as currently.
> 
> If 'external' enum, from other framework, was marked as 'closed' but was 
> actually changed in new version of framework/module - our source code will 
> fail to compile (because we need fix our switch cases) and our binary 
> module(built with previous version of framework) will crash.
> 
> With 'open' enums, depending on situations, I as a consumer of external 
> framework, can decide that it is important to me, in my code, check *each* 
> value of external enum in switch. If new enum case added/changed in external 
> framework - my code must fail to compile and notify me that new case should 
> be processed.
> Once we added 'default' case in 'switch' in our code for 'open' enum - we 
> lost compiler's support to keep our 'switch' exhaustive.
> 
> But from other side, in other situation, I want to process all new cases for 
> 'open' enum in 'default' branch, and so allow my source/compiled code to work 
> with new version of framework(with added cases).
> 
> So, it seems like in both situations we need to explicitly tell what is our 
> decided behavior for new cases for 'open' enum in exhaustive switch : 
> crash/fail to compile or process in 'default' block.
> 
> What if in case of exhaustive switch on 'open' enum, compiler warns us saying 
> "this is an exhaustive switch on 'open' enum, but cases can be added later. 
> clarify what is your decided behaviour. by default your code will crash if 
> new cases are added"
> , then we can add 'default' block to process new future cases or somehow mark 
> that switch as explicitly exhaustive... something like this:
> 
> @exhaustive
> switch openEnum {
>  case .yes : ...
>  case .no : ...
> }
> 
> What I'm missing?
> 
> On 09.08.2017 1:27, Jordan Rose via swift-evolution 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 

Re: [swift-evolution] [swift-evolution-announce] Swift 5: start your engines

[Howard Lovatt via swift-evolution]

I am not against these changes, of requiring an implementation, but I am a
little nervous. Let me expand.

I was involved in the Java Coin initiative for community driven changes to
Java 7. In that process the implementation barrier was set very high and it
effectively meant that only changes from Sun got through, a number of
people put considerable effort in only for the proposals to be rejected. I
felt the process was in the end a little disingenuous and I think that view
was held by many, perhaps tellingly the process has never run again for
subsequent Java versions.

So my cautionary note is that this requirement of implementation requires
careful stewardship and in particular there needs to be some means of
getting 'in principle' approval before the implementation stage. If done
correctly it could work very well.

  -- Howard.

On 9 August 2017 at 02:23, Ted Kremenek  wrote:

> Hi everyone,
>
> The proposal phase for Swift 4 is now officially over, and the release is
> now in endgame engineering convergence for an expected release later this
> year.  Swift 4 has turned out to be one of the highest quality,
> well-rounded releases of Swift, and I am grateful to everyone in the
> community who made this release come together!
>
> Now it is time to turn our attention to Swift 5.  I have just posted
> updates to the README.md file on the swift-evolution repository, which
> outlines the core themes and focus areas for Swift 5:
>
>   https://github.com/apple/swift-evolution
>
> and a more persistent URL (invariant to future README.md changes):
>
>   https://github.com/apple/swift-evolution/blob/
> 9cc90f33b6659adeaf92355c359e34e6fed73254/README.md
>
> I am not going to repeat all of that information here, but I wanted to
> highlight a few important things.
>
> ## ABI Stability
>
> First, ABI stability is the center focus of Swift 5 — and we will pivot
> much of our prioritization of efforts for Swift 5 around it.  With Swift 4,
> ABI stability was a strong goal.  In Swift 5, it is a *requirement* of the
> release.  Whatever ABI we have at the end of Swift 5 is the ABI that we
> will have.  ABI stability is an important inflection point for the maturity
> of the language, and it cannot be delayed any longer.
>
> Please note that there is a difference between ABI stability and module
> stability.   If you are not aware of the difference — which is rather
> important — please read the first few paragraphs of the ABI stability
> manifesto:
>
>   https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md
>
> Module stability is a stretch goal for Swift 5, but even without module
> stability we can still achieve the primary value of ABI stability.
>
> ##  Other focus areas (including laying the groundwork for concurrency)
>
> There are several other areas mentioned for Swift 5 which I won’t repeat
> here, but there is a general theme of refining and broadening out the core
> ergonomics of the language and standard library.
>
> One of those that I wanted to highlight is laying the groundwork for
> concurrency.  It is a non-goal of Swift 5 to roll out a full new
> concurrency model.  That is simply too large an effort to do alongside ABI
> stability.  However, it is important that we start making progress on
> discussing the directions for concurrency and laying some of the
> groundwork.  This may take the form of specific enhancements to the
> language that get implemented, depending on where the discussions for
> concurrency lead and how they align with the priorities for delivering ABI
> stability in Swift 5.
>
> ## Changes to the language evolution process
>
> Last, I want to highlight important changes to the evolution process:
>
>   https://github.com/apple/swift-evolution#evolution-process-for-swift-5
> 
>
> With Swift 4, the release period was divided up into “stage 1” and “stage
> 2” for setting guidelines for the kind of evolution proposals that were in
> scope for the release.  This was needed to establish focus — especially
> after the churn we saw during Swift 3 — on some core themes that were
> aligned with converging the language towards source & ABI stability.  One
> downside is that “stage 2” opened up discussion for potentially disruptive
> changes fairly late in the release.  Further, some proposals — such as
> SE-0155 — came in so late that there was little runway to actually
> implement them for Swift 4, let alone evaluate their impact in practice on
> real projects.  Related, there has been some desire  for a while to be able
> to better evaluate the impact of proposals on real code before they are
> locked into the release, and the best way to do that is to actually have an
> implementation that vets out the design in a proposal.
>
> With Swift 5, the focus on ABI stability will predominate priorities for
> both design and implementation work, but the Core Team did not want 

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

[Jordan Rose via swift-evolution]

Ah, I forgot to mention: per my response to Charlie, the vast majority of enums 
in ObjC Foundation (80-90%) seem to be "open". I should have put that in the 
"open" side of the list. I'm not convinced that "APIs are designed differently 
in Swift" to the extent where you'd actually expect most enums to be closed; 
rather, I suspect most Swift API designers haven't been thinking too hard about 
exhaustive switches, and certainly not about binary compatibility, which 
becomes relevant at least for Apple once Swift libraries become part of the SDK.

Jordan


> On Aug 9, 2017, at 17: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?
> 
> Jordan
> 
> 
> 
>> On Aug 9, 2017, at 08:19, Zach Waldowski via swift-evolution 
>> > wrote:
>> 
>> I disagree. Closed is indeed the stronger guarantee, but APIs are designed 
>> differently in Swift; closed is a sensible default. We shouldn’t need to 
>> define new keywords and increase the surface area of the language for 
>> something that has verisimilitude with the existing open syntax.
>> 
>> Sincerely,
>>   Zachary Waldowski
>>   z...@waldowski.me 
>> 
>> 
>> On Wed, Aug 9, 2017, at 06:23 AM, David Hart via swift-evolution wrote:
>>> 
>>> 
>>> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution 
>>> > wrote:
 Hi Jordan, is that only me or haven't you metioned the default should be 
 applied to all new enums? Personally I'd say that 'closed' should be the 
 default and the 'open' enum would require an extra keyword.
>>> 
>>> I think it should definitely be the other way round for public enums 
>>> because closed is the stronger guarantee. Final is the default for classes 
>>> because open is the stronger guarantee. That’s probably why we should not 
>>> use the same keywords.
>>> 
 Now about the keyword itself. Here are two keywords that IMHO nail their 
 behavior down to the point:
 
 finite enum A {} - so to say a closed enum (default)
 infinite enum B {} - so to say an open enum (requires default case in a 
 switch statement)
 
 If you think the default should be the other way around, than feel free to 
 switch that. 'finite' also implies that the enum connot ever be extended 
 with more cases (to become infinite), which was also mentioned in your 
 email.
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 Am 9. August 2017 um 00:27:53, Jordan Rose via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> 
> 
> 
> 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 

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

[Jordan Rose via swift-evolution]

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

Jordan



> On Aug 9, 2017, at 08:19, Zach Waldowski via swift-evolution 
>  wrote:
> 
> I disagree. Closed is indeed the stronger guarantee, but APIs are designed 
> differently in Swift; closed is a sensible default. We shouldn’t need to 
> define new keywords and increase the surface area of the language for 
> something that has verisimilitude with the existing open syntax.
> 
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me 
> 
> 
> On Wed, Aug 9, 2017, at 06:23 AM, David Hart via swift-evolution wrote:
>> 
>> 
>> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution 
>> > wrote:
>>> Hi Jordan, is that only me or haven't you metioned the default should be 
>>> applied to all new enums? Personally I'd say that 'closed' should be the 
>>> default and the 'open' enum would require an extra keyword.
>> 
>> I think it should definitely be the other way round for public enums because 
>> closed is the stronger guarantee. Final is the default for classes because 
>> open is the stronger guarantee. That’s probably why we should not use the 
>> same keywords.
>> 
>>> Now about the keyword itself. Here are two keywords that IMHO nail their 
>>> behavior down to the point:
>>> 
>>> finite enum A {} - so to say a closed enum (default)
>>> infinite enum B {} - so to say an open enum (requires default case in a 
>>> switch statement)
>>> 
>>> If you think the default should be the other way around, than feel free to 
>>> switch that. 'finite' also implies that the enum connot ever be extended 
>>> with more cases (to become infinite), which was also mentioned in your 
>>> email.
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> Am 9. August 2017 um 00:27:53, Jordan Rose via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 
 
 
 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, 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Tony Allevato via swift-evolution]

On Wed, Aug 9, 2017 at 4:59 PM Michael Ilseman via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 9, 2017, at 4:09 PM, Chris Lattner  wrote:
>
> Hello Swift community,
>
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance"
> begins now and runs through August 15, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.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:
>
> 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, it addresses one of the biggest pain points that cause people to reach
> for metaprogramming facilities.
>
> I have one clarifying point and tweak. The proposal states:
>
> A struct T: Hashable that satisfies the conditions above will receive a
> synthesized implementation of var hashValue: Int { get } that uses an
> unspecified hash function† to compute the hash value by incorporating the
> hash values of the fields as its terms, in definition order.
>
>
> This means that if the hash-combine operation is not commutative, then
> hashValues are not stable modulo member reordering. Was this scenario
> explicitly thought through? I don’t think it’s likely to be an issue in
> practice, but it's an artifact of implicit and ordered member-wise
> synthesis. It’s not obvious that declaration order is clearly the best
> order, e.g. declaration order is not necessarily memory-layout order. It
> might be better to leave the precise order unspecified, so long as it's
> guaranteed consistent during the execution of a program.
>

The stdlib documentation for hashValue states "*Hash values are not
guaranteed to be equal across different executions of your program. Do not
save hash values to use during a future execution.*"  So, we don't need to
provide member-reordering stability since the only way to reorder members
is to recompile the code (at this time).

That being said, we can certainly change the wording from "in definition
order" to "in an arbitrary, implementation-defined order" without changing
the behavior of the proposal and keeping the possibility open for future
optimizations.



>
> • 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?
>
>
> It's a reasonably scoped chunk of functionality for the biggest pain
> points, so yes.
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> Haskell and Rust both have “deriving" constructs for generating these
> kinds of things, and that simplifies a lot of code.
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Thought about it a bit; read it quickly.
>
> 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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

> On Aug 9, 2017, at 11:45, Dave DeLong  wrote:
> 
> 
>> On Aug 8, 2017, at 4:27 PM, Jordan Rose via swift-evolution 
>> > 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 Apple's 
>> frameworks again.) I don't have a great answer, though.
>> 
>> For people who like exhaustive switches, we thought about adding a new kind 
>> of 'default'—let's call it 'unknownCase' just to be able to talk about it. 
>> This lets you get warnings when you update to a new SDK, but is even more 
>> likely to be untested code. We didn't think this was worth the complexity.
>> 
>> 
>> Terminology
>> 
>> The "Library Evolution 
>> " doc (mostly written 
>> by me) originally called these "open" and "closed" enums ("requires a 
>> default" and "allows exhaustive switching", respectively), but this predated 
>> the use of 'open' to describe classes and class members. Matthew's original 
>> thread did suggest using 'open' for enums as well, but I argued against 
>> that, for a few reasons:
>> 
>> 

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Tony Allevato via swift-evolution]

On Wed, Aug 9, 2017 at 4:36 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Aug 9, 2017 at 6:08 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello Swift community,
>>
>> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance"
>> begins now and runs through August 15, 2017. The proposal is available here:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.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:
>>
>> 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?
>>
>
> Brilliant. However, I believe that this is a typo of some importance to
> clarify:
>
> > The compiler synthesizes P's requirements for a struct with one or more
> stored properties if and only if all of the types of all of its stored
> properties conform to P.
>
> I think the author means to write "...conform to {Equatable | Hashable}";
> it is unclear what it means for a struct P to have stored properties that
> "conform to P" (which would be an odd restriction in any case). The same
> issue occurs in preceding bulleted list with respect to enums.
>

In that statement, P is intended to be the protocol (Equatable or
Hashable), not the struct—but I can see how "P's requirements" might be
interpreted either way. In an earlier paragraph I state "For brevity, let P
represent either the protocol Equatable or Hashable in the descriptions
below." In other words:

"The compiler synthesizes {Equatable|Hashable}'s requirements for a struct
with one or more stored properties if and only if all of the types of all
of its stored properties conform to {Equatable|Hashable}."

Hopefully that clarifies, but I can update the write-up if necessary.



>
>> • Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>
> This is a wonderful addition.
>
>
>> • Does this proposal fit well with the feel and direction of
>> Swift?
>>
>
> Yes, the author did an excellent job paralleling the existing rules for
> Codable synthesis; I agree fully with that approach as it makes this
> feature more easily learnable and predictable for all users.
>
>
>> • 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 in recent times, but I do know that other languages do this.
>
>
>> • How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>
> A quick reading today; an in-depth study previously.
>
> ___
> 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

[Jordan Rose via swift-evolution]

> On Aug 9, 2017, at 10:15, Tony Allevato via swift-evolution 
>  wrote:
> 
> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution 
> > wrote:
> (Now with more mailing lists in the "to" field!)
> On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution 
> > 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 Apple's 
>> frameworks again.) I don't have a great answer, though.
>> 
>> For people who like exhaustive switches, we thought about adding a new kind 
>> of 'default'—let's call it 'unknownCase' just to be able to talk about it. 
>> This lets you get warnings when you update to a new SDK, but is even more 
>> likely to be untested code. We didn't think this was worth the complexity.
>> 
>> 
>> Terminology
>> 
>> The "Library Evolution 
>> " doc (mostly written 
>> by me) originally called these "open" and "closed" enums ("requires a 
>> default" and "allows exhaustive switching", 

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

There really isn't a good way to do "extensible outside the library" enums, 
because at that point you've lost the guarantee of distinct cases—it's possible 
for two modules to add the same case with the same raw value. So I don't think 
there are really three states for public enums, only two. I do sympathize with 
the keyword soup problem, though.

(Also, let's please leave protocols out of the enum discussion. Nearly all the 
reasons to give protocols a public/open distinction come from classes, not 
enums, and I wouldn't want to tie the success or failure of one proposal to the 
other.)

The issue of a default is an important one; I'll respond to it on Adrian's 
branch of the thread.

Jordan


> On Aug 9, 2017, at 09:07, Matthew Johnson  wrote:
> 
> Hi Jordan,
> 
> Thanks for bringing this topic up again!  I’m glad to see it will receive 
> attention in Swift 5.  I agree with the semantics of your proposed direction. 
>  
> 
> In terms of syntax, I continue to believe that requiring users to specify a 
> keyword indicating open or closed *in addition* to public would be 
> unfortunate.  Open / closed is only relevant for public enums and therefore 
> implies public.  We’ve done a really good job of avoiding keyword soup in 
> Swift and the way that open classes are implicitly public is a good precedent 
> that we should follow.
> 
> I also continue to believe that aligning protocols, enums and classes to use 
> consistent terminology for similar concepts has many advantages.  The 
> semantics would be:
> 
> * open: Extensible outside the library
> * public: Extensible in future versions of the library (or privately by the 
> library)
> * closed: Fixed set of publicly visible cases / subclasses / conformances 
> defined by the library and guaranteed not to change without breaking ABI and 
> source compatibility.
> 
> This approach makes public a “soft default” that preserves maximum 
> flexibility for the library author while allowing them to make a stronger 
> guarantee of user-extensibility or completeness by changing (rather than 
> adding) a keyword.  It also highlights the symmetry of the two very different 
> user-guarantees a library may choose to support.
> 
> As noted in my previous thread, this approach would require a migration for 
> protocols as well as enums as the current behavior of public protocols is to 
> allow conformances outside the library.
> 
> There are certainly reasonable arguments to be made for other approaches, 
> particularly if there is no appetite for changing the semantics of public 
> protocols (which seems likely).  Nevertheless, I think we should keep the 
> merits of consistency in mind and understand the benefits of alternatives 
> relative to the more consistent approach as we evaluate them.
> 
> In terms of alternatives, what is your opinion on using public as a “soft 
> default” and assigning it one of the two enum semantics you discuss?  Do you 
> think this makes sense or would you prefer distinct keywords for these two 
> semantics?  I don’t have any really great new ideas, but I’ll throw out 
> “complete” and “incomplete” as a possibility.
> 
> My two cents for now…
> 
> Matthew
> 
> 
>> On Aug 8, 2017, at 5:27 PM, Jordan Rose via swift-evolution 
>> > 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 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Michael Ilseman via swift-evolution]

> On Aug 9, 2017, at 4:09 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
> begins now and runs through August 15, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.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:
> 
> 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, it addresses one of the biggest pain points that cause people to reach for 
metaprogramming facilities.

I have one clarifying point and tweak. The proposal states:

> A struct T: Hashable that satisfies the conditions above will receive a 
> synthesized implementation of var hashValue: Int { get } that uses an 
> unspecified hash function† to compute the hash value by incorporating the 
> hash values of the fields as its terms, in definition order.


This means that if the hash-combine operation is not commutative, then 
hashValues are not stable modulo member reordering. Was this scenario 
explicitly thought through? I don’t think it’s likely to be an issue in 
practice, but it's an artifact of implicit and ordered member-wise synthesis. 
It’s not obvious that declaration order is clearly the best order, e.g. 
declaration order is not necessarily memory-layout order. It might be better to 
leave the precise order unspecified, so long as it's guaranteed consistent 
during the execution of a program.

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

It's a reasonably scoped chunk of functionality for the biggest pain points, so 
yes.

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

Haskell and Rust both have “deriving" constructs for generating these kinds of 
things, and that simplifies a lot of code.

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

Thought about it a bit; read it quickly.

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

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

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

Hi, Charlie. This is fair—if you're switching over an open enum at all, 
presumably you have a reason for doing so and therefore might want to handle 
all known cases every time you update your SDK. However, I think in practice 
that's going to be rare—do you have examples of exhaustive switches on SDK 
enums that exist in your own app?

(There's an additional piece about how to handle cases with different 
availability—there's nowhere obvious to write the #available.)

I suspect marking SDK enums "closed" will be much easier than nullability, 
simply because there are so few of them. Here's some data to that effect: out 
of all  60 or so NS_ENUMs in Foundation, only 6 of them are ones I would 
definitely mark "closed":

- NSComparisonResult
- NSKeyValueChange / NSKeyValueSetMutationKind
- NSRectEdge
- NSURLRelationship
- maybe NSCalculationError

There are a few more, like NSURLHandleStatus, where I could see someone wanting 
to exhaustively switch as well, but the main point is that there is a clear 
default for public enums, at least in Objective-C, and that even in a large 
framework it's not too hard to look at all of them.

(Note that NSComparisonResult is technically not part of Foundation; it lives 
in the ObjectiveC module as /usr/include/objc/NSObject.h.)

Jordan


> On Aug 8, 2017, at 21:53, Charlie Monroe  wrote:
> 
> While I agree with the entire idea and would actually use behavior like this 
> in a few instances, I feel that in most cases, you would simply put 
> 
> default:
>   fatalError()
> 
> The huge downside of this is that you no longer get warned by the compiler 
> that you are missing a case that was added - a common thing I personally do 
> (and I have a feeling I'm not alone) - add an enum case, build the app, see 
> what broke and fix it - as you get warnings/errors about the switch not being 
> exhaustive. You find this out during runtime (if you're lucky), otherwise 
> your end user.
> 
> As you've noted all enums from ObjC would need to be marked with an 
> annotation marking if they are closed - which given the way nullability is 
> still missing in many frameworks out there, I think would take years.
> 
> I'd personally expand this proposal by introducing switch! (with the 
> exclamation mark) which would allow to treat open enums as closed. Example:
> 
> // Imported from ObjC
> open enum NSAlert.Style { ... }
> 
> switch! alert.style {
> case .warning:
>   // ...
> case .informational:
>   // ...
> case .critical:
>   // ...
> }
> 
> The force-switch would implicitely create the default label crashing, logging 
> the rawValue of the enum.
> 
> Thoughts?
> 
>> On Aug 9, 2017, at 12:28 AM, Jordan Rose via swift-evolution 
>> > 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 
>> 

Re: [swift-evolution] ExpressibleByStringInterpolation

[Xiaodi Wu via swift-evolution]

This is an excellent proposal; no suggestions for improvement at this
point, as I think it has evolved excellently from its earlier forms. I hope
it goes swiftly to review.


On Tue, Aug 8, 2017 at 11:08 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> I had a proposal for replacing/reintroducing `
> ExpressibleByStringInterpolation` (which is currently deprecated pending
> a redesign), but it landed too late in the Swift 4 cycle to be considered.
> The PR is here: https://github.com/apple/swift-evolution/pull/659
>
> I think it squares up relatively well against the Swift 5 standards:
>
> * It addresses ABI stability and strings, which are both Swift 5 themes.
>
> * It includes an implementation, but it definitely needs a rebase,
> probably needs someone more experienced than me to examine it with a
> fine-toothed comb, and might need a significant redesign.
>
> * I believe it includes tests.
>
> * I don't think it's been run against the source compatibility suite. (Is
> there a way for random outside developers to do that?)
>
> So what's the next step at this point?
>
> --
> 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] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Xiaodi Wu via swift-evolution]

On Wed, Aug 9, 2017 at 6:08 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance"
> begins now and runs through August 15, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0185-synthesize-equatable-hashable.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:
>
> 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?
>

Brilliant. However, I believe that this is a typo of some importance to
clarify:

> The compiler synthesizes P's requirements for a struct with one or more
stored properties if and only if all of the types of all of its stored
properties conform to P.

I think the author means to write "...conform to {Equatable | Hashable}";
it is unclear what it means for a struct P to have stored properties that
"conform to P" (which would be an odd restriction in any case). The same
issue occurs in preceding bulleted list with respect to enums.


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

This is a wonderful addition.


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

Yes, the author did an excellent job paralleling the existing rules for
Codable synthesis; I agree fully with that approach as it makes this
feature more easily learnable and predictable for all users.


> • 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 in recent times, but I do know that other languages do this.


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

A quick reading today; an in-depth study previously.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Xiaodi Wu via swift-evolution]

On Tue, Aug 8, 2017 at 5:27 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> 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
> Apple's frameworks again.) I don't have a great answer, though.
>
> For people who like exhaustive switches, we thought about adding a new
> kind of 'default'—let's call it 'unknownCase' just to be able to talk about
> it. This lets you get warnings when you update to a new SDK, but is even
> more likely to be untested code. We didn't think this was worth the
> complexity.
>
>
> *Terminology*
>
> The "Library Evolution
> " doc (mostly
> written by me) originally called these "open" and "closed" enums ("requires
> a default" and "allows exhaustive switching", respectively), but this
> predated the use of 'open' to describe classes and class members. Matthew's
> original thread did suggest using 'open' for enums as well, but I argued
> against that, for a few reasons:
>
> - For classes, "open" and "non-open" restrict what the *client* can do.
> For enums, it's more about providing the client with additional
> guarantees—and "non-open" is the one with more guarantees.
> - The "safe" default is backwards: a 

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Jon Shier via swift-evolution]

> • What is your evaluation of the proposal?

+∞ - 1 (for no extension synthesis)

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

Most certainly. This is a major pain point, especially for structs with many 
members.

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

Yes, though I don’t particularly care about compiler magic like some, 
especially in such a useful case.

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

I believe Scala with synthesize the equivalent of Equatable conformance for 
class cases, and I’ve used Mantle in Objective-C, which did the same 
dynamically for types which inherited from the right types.

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

Studied it when originally proposed, glanced for a rearview.



Jon Shier

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Chris Lattner via swift-evolution]

And of course, the correct proposal link is:
https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md


> On Aug 9, 2017, at 4:10 PM, Chris Lattner  wrote:
> 
> I forgot to mention that the implementation of this feature is available here:
> https://github.com/apple/swift/pull/9619
> 
> -Chris
> 
>> On Aug 9, 2017, at 4:08 PM, Chris Lattner  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
>> begins now and runs through August 15, 2017. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.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:
>> 
>> 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,
>> 
>> Chris Lattner
>> Review Manager
>> 
>> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Chris Lattner via swift-evolution]

I forgot to mention that the implementation of this feature is available here:
https://github.com/apple/swift/pull/9619

-Chris

> On Aug 9, 2017, at 4:08 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
> begins now and runs through August 15, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.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:
> 
> 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,
> 
> Chris Lattner
> Review Manager
> 
> 

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

[swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
begins now and runs through August 15, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.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:

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,

Chris Lattner
Review Manager


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

Re: [swift-evolution] private extension

[Xiaodi Wu via swift-evolution]

On Wed, Aug 9, 2017 at 5:52 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> I counter with the rationale for rejecting SE-0119
> ,
> namely:
>
> The review of "SE-0119: Remove access modifiers from extensions" ran from
>> July 12...19. The proposal has been *rejected*.
>>
>> The majority of the feedback on this proposal was opposed to it, because
>> it eliminated the useful ability to apply access control to a batch of
>> methods and properties.
>
>
> In other words, access modifiers are allowed on extensions for the express
> purpose of being applied to the members in that extension. The fact that in
> one of them currently does something *other* than what it says on the tin
> is therefore problematic.
>

I agree, but after having originally raised the issue, members of the core
team clearly disagreed. Therefore, it's clear that this is going to have to
go through Swift Evolution or not be changed at all. And I also agree with
the notion that further discussions of access modifiers, which will most
certainly lead to a rehash of the whole sordid past, is unhealthy.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private extension

[Nevin Brackett-Rozinsky via swift-evolution]

I counter with the rationale for rejecting SE-0119
,
namely:

The review of "SE-0119: Remove access modifiers from extensions" ran from
> July 12...19. The proposal has been *rejected*.
>
> The majority of the feedback on this proposal was opposed to it, because
> it eliminated the useful ability to apply access control to a batch of
> methods and properties.


In other words, access modifiers are allowed on extensions for the express
purpose of being applied to the members in that extension. The fact that in
one of them currently does something *other* than what it says on the tin
is therefore problematic.

Nevin


On Wed, Aug 9, 2017 at 6:31 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170417/035885.html
>
>
> On Wed, Aug 9, 2017 at 17:05 David Hart  wrote:
>
>> Do you a have a link to that discussion?
>>
>>
>> On 10 Aug 2017, at 00:04, Xiaodi Wu  wrote:
>>
>> Agree, but again, I tried, and the answer was no, it’s not considered a
>> bug and cannot be fixed without independent discussion.
>> On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:
>>
>>> The last thing I want is to launch into a new round of discussions. I am
>>> just hoping it can be considered as a straight bug that can be fixed
>>> without any discussion.
>>>
>>>
>>> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>>>
>>> I brought this up after SE-0169, but it was deemed to be a separate
>>> issue and any further consideration was declined. Let’s not initiate
>>> another round of access control discussions.
>>> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Actually, I think this is this way only as a relic from the original
 private/fileprivate proposal. Swift 3’s private has no meaning as an
 extension modifier, so it was made to alias to fileprivate. But
 since SE-0169 modified private’s meaning so that it would make sense
 as an extension modifier, I think we should fix this.

 On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
 swift-evolution@swift.org> wrote:

 That behaviour was never explicitly mentioned in SE-0169 but I agree
 its confusing. But I’m also fairly sure the only window to do anything
 about it is Swift 4. Everybody is really worn down by those access level
 discussions.

 For illustration, Vladimir is confused that:

 private extension Foo {
 func foo() {}
 }

 is equivalent to:

 fileprivate extension Foo {
 func foo() {}
 }

 making it accessible to another type in the same file:

 struct Bar {
 func bar(foo: Foo) {
 foo.foo()
 }
 }

 Aren't access levels on extensions supposed to define the default
 access level of the members of the extension?Is this a bug then?

 On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
 swift-evolution@swift.org> wrote:

 Could someone remind please, was it decided to stick with 'private
 extension' means actually fileprivate access level for members declared in
 such extension or this could be discussed for Swift5?

 Currently, when private members are visible in type/extensions of that
 type in the same file, IMO there is no sense to treat 'private extension'
 as 'fileprivate extension', it is reasonable to group some private members
 of type into extension without making them fileprivate, and such members
 can be used from the type/other extensions.

 And also this is a huge inconsistency in my opinion: all other access
 modifiers 'work' as expected for extensions, but only 'private extension'
 means not what written, very surprising for one who don't expect this.
 ___
 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] private extension

[Nevin Brackett-Rozinsky via swift-evolution]

I agree this should be considered a simple bug. Have you filed a bug report?

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

Re: [swift-evolution] private extension

[Xiaodi Wu via swift-evolution]

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035885.html

On Wed, Aug 9, 2017 at 17:05 David Hart  wrote:

> Do you a have a link to that discussion?
>
>
> On 10 Aug 2017, at 00:04, Xiaodi Wu  wrote:
>
> Agree, but again, I tried, and the answer was no, it’s not considered a
> bug and cannot be fixed without independent discussion.
> On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:
>
>> The last thing I want is to launch into a new round of discussions. I am
>> just hoping it can be considered as a straight bug that can be fixed
>> without any discussion.
>>
>>
>> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>>
>> I brought this up after SE-0169, but it was deemed to be a separate issue
>> and any further consideration was declined. Let’s not initiate another
>> round of access control discussions.
>> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Actually, I think this is this way only as a relic from the original
>>> private/fileprivate proposal. Swift 3’s private has no meaning as an
>>> extension modifier, so it was made to alias to fileprivate. But
>>> since SE-0169 modified private’s meaning so that it would make sense as
>>> an extension modifier, I think we should fix this.
>>>
>>> On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> That behaviour was never explicitly mentioned in SE-0169 but I agree its
>>> confusing. But I’m also fairly sure the only window to do anything about it
>>> is Swift 4. Everybody is really worn down by those access level discussions.
>>>
>>> For illustration, Vladimir is confused that:
>>>
>>> private extension Foo {
>>> func foo() {}
>>> }
>>>
>>> is equivalent to:
>>>
>>> fileprivate extension Foo {
>>> func foo() {}
>>> }
>>>
>>> making it accessible to another type in the same file:
>>>
>>> struct Bar {
>>> func bar(foo: Foo) {
>>> foo.foo()
>>> }
>>> }
>>>
>>> Aren't access levels on extensions supposed to define the default access
>>> level of the members of the extension?Is this a bug then?
>>>
>>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Could someone remind please, was it decided to stick with 'private
>>> extension' means actually fileprivate access level for members declared in
>>> such extension or this could be discussed for Swift5?
>>>
>>> Currently, when private members are visible in type/extensions of that
>>> type in the same file, IMO there is no sense to treat 'private extension'
>>> as 'fileprivate extension', it is reasonable to group some private members
>>> of type into extension without making them fileprivate, and such members
>>> can be used from the type/other extensions.
>>>
>>> And also this is a huge inconsistency in my opinion: all other access
>>> modifiers 'work' as expected for extensions, but only 'private extension'
>>> means not what written, very surprising for one who don't expect this.
>>> ___
>>> 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] private extension

[David Hart via swift-evolution]

Do you a have a link to that discussion?

> On 10 Aug 2017, at 00:04, Xiaodi Wu  wrote:
> 
> Agree, but again, I tried, and the answer was no, it’s not considered a bug 
> and cannot be fixed without independent discussion.
>> On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:
>> The last thing I want is to launch into a new round of discussions. I am 
>> just hoping it can be considered as a straight bug that can be fixed without 
>> any discussion.
>> 
>> 
>>> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>>> 
>>> I brought this up after SE-0169, but it was deemed to be a separate issue 
>>> and any further consideration was declined. Let’s not initiate another 
>>> round of access control discussions.
 On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution 
  wrote:
 Actually, I think this is this way only as a relic from the original 
 private/fileprivate proposal. Swift 3’s private has no meaning as an 
 extension modifier, so it was made to alias to fileprivate. But since 
 SE-0169 modified private’s meaning so that it would make sense as an 
 extension modifier, I think we should fix this.
 
> On 9 Aug 2017, at 23:22, David Hart via swift-evolution 
>  wrote:
> 
> That behaviour was never explicitly mentioned in SE-0169 but I agree its 
> confusing. But I’m also fairly sure the only window to do anything about 
> it is Swift 4. Everybody is really worn down by those access level 
> discussions.
> 
> For illustration, Vladimir is confused that:
> 
> private extension Foo {
> func foo() {}
> }
> 
> is equivalent to:
> 
> fileprivate extension Foo {
> func foo() {}
> }
> 
> making it accessible to another type in the same file:
> 
> struct Bar {
> func bar(foo: Foo) {
> foo.foo()
> }
> }
> 
> Aren't access levels on extensions supposed to define the default access 
> level of the members of the extension?Is this a bug then?
> 
>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>> Could someone remind please, was it decided to stick with 'private 
>> extension' means actually fileprivate access level for members declared 
>> in such extension or this could be discussed for Swift5?
>> 
>> Currently, when private members are visible in type/extensions of that 
>> type in the same file, IMO there is no sense to treat 'private 
>> extension' as 'fileprivate extension', it is reasonable to group some 
>> private members of type into extension without making them fileprivate, 
>> and such members can be used from the type/other extensions.
>> 
>> And also this is a huge inconsistency in my opinion: all other access 
>> modifiers 'work' as expected for extensions, but only 'private 
>> extension' means not what written, very surprising for one who don't 
>> expect this.
>> ___
>> 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] private extension

[Xiaodi Wu via swift-evolution]

Agree, but again, I tried, and the answer was no, it’s not considered a bug
and cannot be fixed without independent discussion.
On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:

> The last thing I want is to launch into a new round of discussions. I am
> just hoping it can be considered as a straight bug that can be fixed
> without any discussion.
>
>
> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>
> I brought this up after SE-0169, but it was deemed to be a separate issue
> and any further consideration was declined. Let’s not initiate another
> round of access control discussions.
> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Actually, I think this is this way only as a relic from the original
>> private/fileprivate proposal. Swift 3’s private has no meaning as an
>> extension modifier, so it was made to alias to fileprivate. But
>> since SE-0169 modified private’s meaning so that it would make sense as
>> an extension modifier, I think we should fix this.
>>
>> On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> That behaviour was never explicitly mentioned in SE-0169 but I agree its
>> confusing. But I’m also fairly sure the only window to do anything about it
>> is Swift 4. Everybody is really worn down by those access level discussions.
>>
>> For illustration, Vladimir is confused that:
>>
>> private extension Foo {
>> func foo() {}
>> }
>>
>> is equivalent to:
>>
>> fileprivate extension Foo {
>> func foo() {}
>> }
>>
>> making it accessible to another type in the same file:
>>
>> struct Bar {
>> func bar(foo: Foo) {
>> foo.foo()
>> }
>> }
>>
>> Aren't access levels on extensions supposed to define the default access
>> level of the members of the extension?Is this a bug then?
>>
>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Could someone remind please, was it decided to stick with 'private
>> extension' means actually fileprivate access level for members declared in
>> such extension or this could be discussed for Swift5?
>>
>> Currently, when private members are visible in type/extensions of that
>> type in the same file, IMO there is no sense to treat 'private extension'
>> as 'fileprivate extension', it is reasonable to group some private members
>> of type into extension without making them fileprivate, and such members
>> can be used from the type/other extensions.
>>
>> And also this is a huge inconsistency in my opinion: all other access
>> modifiers 'work' as expected for extensions, but only 'private extension'
>> means not what written, very surprising for one who don't expect this.
>> ___
>> 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] private extension

[David Hart via swift-evolution]

The last thing I want is to launch into a new round of discussions. I am just 
hoping it can be considered as a straight bug that can be fixed without any 
discussion.

> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
> 
> I brought this up after SE-0169, but it was deemed to be a separate issue and 
> any further consideration was declined. Let’s not initiate another round of 
> access control discussions.
>> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution 
>>  wrote:
>> Actually, I think this is this way only as a relic from the original 
>> private/fileprivate proposal. Swift 3’s private has no meaning as an 
>> extension modifier, so it was made to alias to fileprivate. But since 
>> SE-0169 modified private’s meaning so that it would make sense as an 
>> extension modifier, I think we should fix this.
>> 
>>> On 9 Aug 2017, at 23:22, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> That behaviour was never explicitly mentioned in SE-0169 but I agree its 
>>> confusing. But I’m also fairly sure the only window to do anything about it 
>>> is Swift 4. Everybody is really worn down by those access level discussions.
>>> 
>>> For illustration, Vladimir is confused that:
>>> 
>>> private extension Foo {
>>> func foo() {}
>>> }
>>> 
>>> is equivalent to:
>>> 
>>> fileprivate extension Foo {
>>> func foo() {}
>>> }
>>> 
>>> making it accessible to another type in the same file:
>>> 
>>> struct Bar {
>>> func bar(foo: Foo) {
>>> foo.foo()
>>> }
>>> }
>>> 
>>> Aren't access levels on extensions supposed to define the default access 
>>> level of the members of the extension?Is this a bug then?
>>> 
 On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
  wrote:
 
 Could someone remind please, was it decided to stick with 'private 
 extension' means actually fileprivate access level for members declared in 
 such extension or this could be discussed for Swift5?
 
 Currently, when private members are visible in type/extensions of that 
 type in the same file, IMO there is no sense to treat 'private extension' 
 as 'fileprivate extension', it is reasonable to group some private members 
 of type into extension without making them fileprivate, and such members 
 can be used from the type/other extensions.
 
 And also this is a huge inconsistency in my opinion: all other access 
 modifiers 'work' as expected for extensions, but only 'private extension' 
 means not what written, very surprising for one who don't expect this.
 ___
 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] private extension

[Xiaodi Wu via swift-evolution]

I brought this up after SE-0169, but it was deemed to be a separate issue
and any further consideration was declined. Let’s not initiate another
round of access control discussions.
On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Actually, I think this is this way only as a relic from the original
> private/fileprivate proposal. Swift 3’s private has no meaning as an
> extension modifier, so it was made to alias to fileprivate. But
> since SE-0169 modified private’s meaning so that it would make sense as
> an extension modifier, I think we should fix this.
>
> On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> That behaviour was never explicitly mentioned in SE-0169 but I agree its
> confusing. But I’m also fairly sure the only window to do anything about it
> is Swift 4. Everybody is really worn down by those access level discussions.
>
> For illustration, Vladimir is confused that:
>
> private extension Foo {
> func foo() {}
> }
>
> is equivalent to:
>
> fileprivate extension Foo {
> func foo() {}
> }
>
> making it accessible to another type in the same file:
>
> struct Bar {
> func bar(foo: Foo) {
> foo.foo()
> }
> }
>
> Aren't access levels on extensions supposed to define the default access
> level of the members of the extension?Is this a bug then?
>
> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Could someone remind please, was it decided to stick with 'private
> extension' means actually fileprivate access level for members declared in
> such extension or this could be discussed for Swift5?
>
> Currently, when private members are visible in type/extensions of that
> type in the same file, IMO there is no sense to treat 'private extension'
> as 'fileprivate extension', it is reasonable to group some private members
> of type into extension without making them fileprivate, and such members
> can be used from the type/other extensions.
>
> And also this is a huge inconsistency in my opinion: all other access
> modifiers 'work' as expected for extensions, but only 'private extension'
> means not what written, very surprising for one who don't expect this.
> ___
> 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] [discussion] Class stored properties?

[Christopher Kornher via swift-evolution]

Class variables are not common, but they are the most natural way to implement 
class-specific functionality. Off the top of my head, I have used class 
variables for:

1) Custom allocation schemes, e.g. pools, LRU implementations
2) Diagnostics, e.g. counting the number of instances of a given class
3) Plugin-in functionality, e.g. customizing behavior of a class at runtime. In 
Swift, the variables would be closures.


You can argue that class variables these are not strictly necessary for these 
tasks, but I have found them to be handy, including during development and 
“Bring-up"

- Chris




> On Aug 9, 2017, at 12:52 PM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> I don't follow. What's a singleton/how? If you mean my example, the whole 
> point/need for the feature is so it's not. I want `.value` to be unique 
> storage for each subclass.
> 
> On Wed, Aug 9, 2017 at 7:09 PM, Robert Widmann  > wrote:
> This is a singleton, it just happens to be in class scope.
> 
> ~Robert Widmann
> 
> > On Aug 9, 2017, at 3:55 AM, Mathew Huusko V via swift-evolution 
> > > wrote:
> >
> > Curious if class stored properties have ever been discussed (doesn't seem 
> > so..)?
> >
> > Also, assuming no, and assuming there's a good reason no/they're not coming 
> > anytime soon, what are some patterns people have been using in their place? 
> > I was considering something like..
> >
> > class SomeClass {
> > private static var _classValues = [SomeClass.Type: Int]()
> >
> > class var value: Int {
> > get { _classValues[self] }
> > set { _classValues[self] = newValue }
> > }
> > }
> >
> > .. but then I remembered types aren't hashable yet either (so I guess I 
> > need to stringify it first).
> > ___
> > 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] private extension

[David Hart via swift-evolution]

Actually, I think this is this way only as a relic from the original 
private/fileprivate proposal. Swift 3’s private has no meaning as an extension 
modifier, so it was made to alias to fileprivate. But since SE-0169 modified 
private’s meaning so that it would make sense as an extension modifier, I think 
we should fix this.

> On 9 Aug 2017, at 23:22, David Hart via swift-evolution 
>  wrote:
> 
> That behaviour was never explicitly mentioned in SE-0169 but I agree its 
> confusing. But I’m also fairly sure the only window to do anything about it 
> is Swift 4. Everybody is really worn down by those access level discussions.
> 
> For illustration, Vladimir is confused that:
> 
> private extension Foo {
> func foo() {}
> }
> 
> is equivalent to:
> 
> fileprivate extension Foo {
> func foo() {}
> }
> 
> making it accessible to another type in the same file:
> 
> struct Bar {
> func bar(foo: Foo) {
> foo.foo()
> }
> }
> 
> Aren't access levels on extensions supposed to define the default access 
> level of the members of the extension?Is this a bug then?
> 
>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
>> > wrote:
>> 
>> Could someone remind please, was it decided to stick with 'private 
>> extension' means actually fileprivate access level for members declared in 
>> such extension or this could be discussed for Swift5?
>> 
>> Currently, when private members are visible in type/extensions of that type 
>> in the same file, IMO there is no sense to treat 'private extension' as 
>> 'fileprivate extension', it is reasonable to group some private members of 
>> type into extension without making them fileprivate, and such members can be 
>> used from the type/other extensions.
>> 
>> And also this is a huge inconsistency in my opinion: all other access 
>> modifiers 'work' as expected for extensions, but only 'private extension' 
>> means not what written, very surprising for one who don't expect this.
>> ___
>> 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] private extension

[David Hart via swift-evolution]

That behaviour was never explicitly mentioned in SE-0169 but I agree its 
confusing. But I’m also fairly sure the only window to do anything about it is 
Swift 4. Everybody is really worn down by those access level discussions.

For illustration, Vladimir is confused that:

private extension Foo {
func foo() {}
}

is equivalent to:

fileprivate extension Foo {
func foo() {}
}

making it accessible to another type in the same file:

struct Bar {
func bar(foo: Foo) {
foo.foo()
}
}

Aren't access levels on extensions supposed to define the default access level 
of the members of the extension?Is this a bug then?

> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
>  wrote:
> 
> Could someone remind please, was it decided to stick with 'private extension' 
> means actually fileprivate access level for members declared in such 
> extension or this could be discussed for Swift5?
> 
> Currently, when private members are visible in type/extensions of that type 
> in the same file, IMO there is no sense to treat 'private extension' as 
> 'fileprivate extension', it is reasonable to group some private members of 
> type into extension without making them fileprivate, and such members can be 
> used from the type/other extensions.
> 
> And also this is a huge inconsistency in my opinion: all other access 
> modifiers 'work' as expected for extensions, but only 'private extension' 
> means not what written, very surprising for one who don't expect this.
> ___
> 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

[Adrian Zubarev via swift-evolution]

I’d very much in favour of a consistent access modifiers across the whole 
language and eliminate exclusive `open`. `open/public` protocols are more than 
welcome. Plus it’s already has been said that Swift will potentially support 
subtyping for value type in some future, where we’ll yet again would need to 
align what `public` and `open` will mean. So I’d appreciate all the steps that 
could already be made now to align their meaning as much as it’s possible to 
this moment.


Am 9. August 2017 um 18:08:09, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi Jordan,

Thanks for bringing this topic up again!  I’m glad to see it will receive 
attention in Swift 5.  I agree with the semantics of your proposed direction.  

In terms of syntax, I continue to believe that requiring users to specify a 
keyword indicating open or closed *in addition* to public would be unfortunate. 
 Open / closed is only relevant for public enums and therefore implies public.  
We’ve done a really good job of avoiding keyword soup in Swift and the way that 
open classes are implicitly public is a good precedent that we should follow.

I also continue to believe that aligning protocols, enums and classes to use 
consistent terminology for similar concepts has many advantages.  The semantics 
would be:

* open: Extensible outside the library
* public: Extensible in future versions of the library (or privately by the 
library)
* closed: Fixed set of publicly visible cases / subclasses / conformances 
defined by the library and guaranteed not to change without breaking ABI and 
source compatibility.

This approach makes public a “soft default” that preserves maximum flexibility 
for the library author while allowing them to make a stronger guarantee of 
user-extensibility or completeness by changing (rather than adding) a keyword.  
It also highlights the symmetry of the two very different user-guarantees a 
library may choose to support.

As noted in my previous thread, this approach would require a migration for 
protocols as well as enums as the current behavior of public protocols is to 
allow conformances outside the library.

There are certainly reasonable arguments to be made for other approaches, 
particularly if there is no appetite for changing the semantics of public 
protocols (which seems likely).  Nevertheless, I think we should keep the 
merits of consistency in mind and understand the benefits of alternatives 
relative to the more consistent approach as we evaluate them.

In terms of alternatives, what is your opinion on using public as a “soft 
default” and assigning it one of the two enum semantics you discuss?  Do you 
think this makes sense or would you prefer distinct keywords for these two 
semantics?  I don’t have any really great new ideas, but I’ll throw out 
“complete” and “incomplete” as a possibility.

My two cents for now…

Matthew


On Aug 8, 2017, at 5:27 PM, Jordan Rose via swift-evolution 
 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 

Re: [swift-evolution] [discussion] What generics feature would this be?

[Mathew Huusko V via swift-evolution]

Very interesting. Is this likely to be changed in the future (either
existentials conforming to their protocols, or `S: Protocol` specifically
allowing for existentials)?

Also, is this at all related? Another instance of at naive/face value
something seeming like it should conform, but not..

protocol Special {}
protocol SubSpecial: Special {}

let spec: Special.Protocol = Special.self // works
let subspec: Special.Protocol = SubSpecial.self // doesnt work



On Wed, Aug 9, 2017 at 7:17 PM, Austin Zheng  wrote:

> A existential type of some protocol `P`, counterintuitively, doesn't
> conform to itself, unless it's an Objective-C protocol.
>
> Because `S : Special` means S has to be a type that conforms to the
> protocol `Special`, and `special` is of the existential type `Special`, the
> existential type `Special` doesn't conform to the protocol `Special`, so it
> can't be used for `S`.
>
> Best,
> Austin
>
> > On Aug 9, 2017, at 7:19 AM, Mathew Huusko V via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > Curious what part of generics the below would fall under? This hit me by
> surprise/makes even non-generic/Self-depending protocols un-interchangeable
> with classes..
> >
> > ```
> > protocol Special {}
> >
> > func doWithAndReturn(_ special: S) -> S { ... }
> >
> > let special: Special = ...
> >
> > // "error: Generics parameter 'S' could not be inferred"
> > // works fine when 'Special' is a class
> > let newSpecial: Special = doWithAndReturn(special)
> > ```
> > ___
> > 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 5: start your engines

[Ben Rimmington via swift-evolution]

> On 9 Aug 2017, at 07:29, Jonathan Hull wrote:
> 
> Would it be possible to get a series of tutorials on how the systems that 
> make up Swift generally work?  In other words, what are the pieces and how do 
> they fit together?

Slava Pestov wrote a couple of articles last year:





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

[swift-evolution] private extension

[Vladimir.S via swift-evolution]

Could someone remind please, was it decided to stick with 'private extension' means 
actually fileprivate access level for members declared in such extension or this 
could be discussed for Swift5?


Currently, when private members are visible in type/extensions of that type in the 
same file, IMO there is no sense to treat 'private extension' as 'fileprivate 
extension', it is reasonable to group some private members of type into extension 
without making them fileprivate, and such members can be used from the type/other 
extensions.


And also this is a huge inconsistency in my opinion: all other access modifiers 
'work' as expected for extensions, but only 'private extension' means not what 
written, very surprising for one who don't expect this.

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

Re: [swift-evolution] Enums and Source Compatibility

[David Sweeris via swift-evolution]

> On Aug 9, 2017, at 11:04, Matthew Johnson  wrote:
> 
>> On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution 
>>  wrote:
>> 
>>> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution 
>>>  wrote:
>>> (Now with more mailing lists in the "to" field!)
 On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution 
  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 
 Apple's frameworks again.) I don't have a great answer, though.
 
 For people who like exhaustive switches, we thought about adding a new 
 kind of 'default'—let's call it 'unknownCase' just to be able to talk 
 about it. This lets you get warnings when you update to a new SDK, but is 
 even more likely to be untested code. We didn't think this was worth the 
 complexity.
 
 
 Terminology
 
 The "Library 

Re: [swift-evolution] [discussion] Class stored properties?

[Mathew Huusko V via swift-evolution]

I don't follow. What's a singleton/how? If you mean my example, the whole
point/need for the feature is so it's not. I want `.value` to be unique
storage for each subclass.

On Wed, Aug 9, 2017 at 7:09 PM, Robert Widmann  wrote:

> This is a singleton, it just happens to be in class scope.
>
> ~Robert Widmann
>
> > On Aug 9, 2017, at 3:55 AM, Mathew Huusko V via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Curious if class stored properties have ever been discussed (doesn't
> seem so..)?
> >
> > Also, assuming no, and assuming there's a good reason no/they're not
> coming anytime soon, what are some patterns people have been using in their
> place? I was considering something like..
> >
> > class SomeClass {
> > private static var _classValues = [SomeClass.Type: Int]()
> >
> > class var value: Int {
> > get { _classValues[self] }
> > set { _classValues[self] = newValue }
> > }
> > }
> >
> > .. but then I remembered types aren't hashable yet either (so I guess I
> need to stringify it first).
> > ___
> > 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

[Dave DeLong via swift-evolution]

> On Aug 8, 2017, at 4:27 PM, Jordan Rose via swift-evolution 
>  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 Apple's 
> frameworks again.) I don't have a great answer, though.
> 
> For people who like exhaustive switches, we thought about adding a new kind 
> of 'default'—let's call it 'unknownCase' just to be able to talk about it. 
> This lets you get warnings when you update to a new SDK, but is even more 
> likely to be untested code. We didn't think this was worth the complexity.
> 
> 
> Terminology
> 
> The "Library Evolution 
> " doc (mostly written 
> by me) originally called these "open" and "closed" enums ("requires a 
> default" and "allows exhaustive switching", respectively), but this predated 
> the use of 'open' to describe classes and class members. Matthew's original 
> thread did suggest using 'open' for enums as well, but I argued against that, 
> for a few reasons:
> 
> - For classes, "open" and "non-open" restrict what the client can do. For 
> enums, it's more about providing the client with additional guarantees—and 
> "non-open" is the one with more guarantees.

Re: [swift-evolution] [discussion] What generics feature would this be?

[Austin Zheng via swift-evolution]

A existential type of some protocol `P`, counterintuitively, doesn't conform to 
itself, unless it's an Objective-C protocol.

Because `S : Special` means S has to be a type that conforms to the protocol 
`Special`, and `special` is of the existential type `Special`, the existential 
type `Special` doesn't conform to the protocol `Special`, so it can't be used 
for `S`.

Best,
Austin

> On Aug 9, 2017, at 7:19 AM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> 
> Curious what part of generics the below would fall under? This hit me by 
> surprise/makes even non-generic/Self-depending protocols un-interchangeable 
> with classes..
> 
> ```
> protocol Special {}
> 
> func doWithAndReturn(_ special: S) -> S { ... }
> 
> let special: Special = ...
> 
> // "error: Generics parameter 'S' could not be inferred"
> // works fine when 'Special' is a class
> let newSpecial: Special = doWithAndReturn(special)
> ```
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [discussion] Class stored properties?

[Robert Widmann via swift-evolution]

This is a singleton, it just happens to be in class scope.

~Robert Widmann

> On Aug 9, 2017, at 3:55 AM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> Curious if class stored properties have ever been discussed (doesn't seem 
> so..)?
> 
> Also, assuming no, and assuming there's a good reason no/they're not coming 
> anytime soon, what are some patterns people have been using in their place? I 
> was considering something like..
> 
> class SomeClass {
> private static var _classValues = [SomeClass.Type: Int]()
> 
> class var value: Int {
> get { _classValues[self] }
> set { _classValues[self] = newValue }
> }
> }
> 
> .. but then I remembered types aren't hashable yet either (so I guess I need 
> to stringify it first).
> ___
> 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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
>> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution 
>>  wrote:
>> (Now with more mailing lists in the "to" field!)
>>> On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution 
>>>  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 
>>> Apple's frameworks again.) I don't have a great answer, though.
>>> 
>>> For people who like exhaustive switches, we thought about adding a new kind 
>>> of 'default'—let's call it 'unknownCase' just to be able to talk about it. 
>>> This lets you get warnings when you update to a new SDK, but is even more 
>>> likely to be untested code. We didn't think this was worth the complexity.
>>> 
>>> 
>>> Terminology
>>> 
>>> The "Library Evolution" doc (mostly written by me) originally called these 
>>> "open" and "closed" enums ("requires a default" and "allows exhaustive 
>>> switching", 

Re: [swift-evolution] Enums and Source Compatibility

[Tony Allevato via swift-evolution]

On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> (Now with more mailing lists in the "to" field!)
> On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> 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
> Apple's frameworks again.) I don't have a great answer, though.
>
> For people who like exhaustive switches, we thought about adding a new
> kind of 'default'—let's call it 'unknownCase' just to be able to talk about
> it. This lets you get warnings when you update to a new SDK, but is even
> more likely to be untested code. We didn't think this was worth the
> complexity.
>
>
> *Terminology*
>
> The "Library Evolution
> " doc (mostly
> written by me) originally called these "open" and "closed" enums ("requires
> a default" and "allows exhaustive switching", respectively), but this
> predated the use of 'open' to describe classes and class members. Matthew's
> original thread did suggest using 'open' for enums as well, but I argued
> against that, for a few reasons:
>
> - For classes, "open" and "non-open" restrict what the *client* can do.
> For enums, 

Re: [swift-evolution] Enums and Source Compatibility

[Vladimir.S via swift-evolution]

Sorry if I misunderstood the subject, but shouldn't this also be a *consumer* 
decision, when one wants to keep own switch exhaustive or it is OK to process all 
possible future cases in 'default'?


If enum is 'closed' - nothing is changed, as I understand, we have the same rules for 
switch as currently.


If 'external' enum, from other framework, was marked as 'closed' but was actually 
changed in new version of framework/module - our source code will fail to compile 
(because we need fix our switch cases) and our binary module(built with previous 
version of framework) will crash.


With 'open' enums, depending on situations, I as a consumer of external framework, 
can decide that it is important to me, in my code, check *each* value of external 
enum in switch. If new enum case added/changed in external framework - my code must 
fail to compile and notify me that new case should be processed.
Once we added 'default' case in 'switch' in our code for 'open' enum - we lost 
compiler's support to keep our 'switch' exhaustive.


But from other side, in other situation, I want to process all new cases for 'open' 
enum in 'default' branch, and so allow my source/compiled code to work with new 
version of framework(with added cases).


So, it seems like in both situations we need to explicitly tell what is our decided 
behavior for new cases for 'open' enum in exhaustive switch : crash/fail to compile 
or process in 'default' block.


What if in case of exhaustive switch on 'open' enum, compiler warns us saying "this 
is an exhaustive switch on 'open' enum, but cases can be added later. clarify what is 
your decided behaviour. by default your code will crash if new cases are added"
, then we can add 'default' block to process new future cases or somehow mark that 
switch as explicitly exhaustive... something like this:


@exhaustive
switch openEnum {
  case .yes : ...
  case .no : ...
}

What I'm missing?

On 09.08.2017 1:27, Jordan Rose via swift-evolution 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 

Re: [swift-evolution] Enums and Source Compatibility

[David Sweeris via swift-evolution]

(Now with more mailing lists in the "to" field!)
> On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution 
>  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 Apple's 
> frameworks again.) I don't have a great answer, though.
> 
> For people who like exhaustive switches, we thought about adding a new kind 
> of 'default'—let's call it 'unknownCase' just to be able to talk about it. 
> This lets you get warnings when you update to a new SDK, but is even more 
> likely to be untested code. We didn't think this was worth the complexity.
> 
> 
> Terminology
> 
> The "Library Evolution" doc (mostly written by me) originally called these 
> "open" and "closed" enums ("requires a default" and "allows exhaustive 
> switching", respectively), but this predated the use of 'open' to describe 
> classes and class members. Matthew's original thread did suggest using 'open' 
> for enums as well, but I argued against that, for a few reasons:
> 
> - For classes, "open" and "non-open" restrict what the client can do. For 
> enums, it's more about providing the client with additional guarantees—and 
> "non-open" is the one with more guarantees.
> - The 

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

[Tony Allevato via swift-evolution]

Thanks for the questions!

On Wed, Aug 9, 2017 at 9:18 AM Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> Looks good to me, though I have some clarifying questions. For a type
> which conforms to both Equatable and Hashable:
>
> 1. To automatically derive both Equatable and Hashable, will it be
> sufficient to declare “struct Foo: Hashable” (since Hashable refines
> Equatable) or must “Equatable” also be listed?
>

Yes, because Hashable implies Equatable. (This is also the case with
Codable, where conforming to Codable synthesizes both Decodable and
Encodable.)

Implementation-wise, the compiler asks "does this type conform to X", which
is a distinct question from "does this type explicitly state X in its
protocol conformance list". The former is the correct question to always
ask, IMO—I don't believe there are any places in the compiler where the
latter would produce different behavior than the former (but someone please
correct me if I'm wrong).


> 2. Will it be possible to automatically derive “==” while manually
> implementing “hashValue”?
> 2a. If so, will “Equatable” and “Hashable” both need to appear in the
> declaration, or will “Hashable” alone suffice?
>

> 3. Will it be possible to automatically derive “hashValue” while manually
> implementing “==”?
> 3a. If so, will “Equatable” and “Hashable” both need to appear in the
> declaration, or will “Hashable” alone suffice?
>

Either or both members can be replaced with manual implementations—of
course it's up to the user at that point to keep those implementations
behaviorally consistent. Doing so does not change the behavior described
above regarding the protocol conformance list.



> Thanks,
>
> Nevin
>
>
> On Wed, Aug 9, 2017 at 11:36 AM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Now that Swift 5 is taking proposals, I'm dusting off my proposal to
>> synthesize Equatable/Hashable conformance for enums and structs. I had
>> implemented this a few months ago hoping to squeeze it in by the Swift 4
>> deadline, but unfortunately the timeline was too tight.
>>
>> The pull request for the proposal is here:
>> https://github.com/apple/swift-evolution/pull/706. (Direct link to
>> proposal text:
>> https://github.com/allevato/swift-evolution/blob/b3dcffc2e6f74e17eba05a6eb7eb29ad58bf36a3/proposals/-synthesize-equatable-hashable.md
>> )
>>
>> The pull request for the implementation (rebased last night) is here:
>> https://github.com/apple/swift/pull/9619
>>
>> Thanks all!
>>
>>
>> ___
>> 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] How does "Sequence.joined" work?

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 8, 2017, at 6:45 PM, Geordie Jay  wrote:
>
>
> Daryle Walker via swift-evolution  schrieb am
> Di. 8. Aug. 2017 um 21:25:
>
>> On Aug 8, 2017, at 12:35 AM, Félix Cloutier 
>> wrote:
>>
>> All this means is that `joined()` does not create an array that contains
>> the new result. It's only as magic as the COW semantics on arrays.
>>
>>
>> So you’re saying the COW semantics for Array and other standard library
>> types have secret references/pointers that work even for “let”-mode
>> objects, and the Sequence variants the various forms of “joined” need use a
>> Sequence/Collection of those secret references?
>>
>
> I know nothing about this specific type under the hood and your question
> stumped me when I first saw it as well, so take this with a grain of salt:
>
> I think it's basically just storing the arrays internally (as let) and
> when you iterate through the collection it just goes through the
> subsequences one by one, when the last index of the first is reached it
> begins with the next subsequence.
>
> As for how it avoids creating new storage, simple. As someone else
> mentioned, this is no more magic than Copy On Write for normal arrays.
>
> let a = [1,2,3]
> let b = a // this doesn't produce a copy of the underlying buffer.. I.e.
> value semantics but only one buffer needed
>
> ^^^ This is the take-home message. And your intuition about COW is
> correct: its internal storage is a reference type containing a buffer
> pointer. When (and only when) a mutation occurs, the buffer is copied and
> the new storage becomes the backing for the resulting struct. Any existing
> copies remain unchanged (and truly immutable) because they keep their
> original storage.
>
> https://github.com/apple/swift/blob/master/stdlib/public/core/
> ContiguousArrayBuffer.swift
>
>
> So with that understanding of COW, it becomes easy to imagine all sorts of
> containers that don't require additional storage for their contents:
>
> struct JoinedSequenceOfThreeArrays {
>   let array1: [T]
>   let array2: [T]
>   let array3: [T]
> }
>
> // still only one array buffer storage is required for all of this:
> let c = JoinedSequenceOfThreeArrays(array1: a, array2: a, array3: b)
>
> Does that make sense?
>
>
> Mostly, then I realized a flaw with this explanation. Your theory implies
> that “joined” avoids creating new storage by betraying that and actually
> copying the containers, but said containers use-COW/reference-remote-storage
> themselves. Then what happens when a Sequence uses scoped storage for its
> items? (Example: the mythical “just slap Collection on a tuple and call it
> an array” type.) Either “joined” uses a different no-copy technique or it’s
> lying about saving on storage (and the lack of scoped-storage Sequences
> means no one has called them on it yet).
>

I don’t see any contradiction here. A tuple is a value type; it has no
concept of copy-on-write because it’s copy-on-read. So JoinedSequence will
store a copy of the tuple instead of a buffer reference
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

[Nevin Brackett-Rozinsky via swift-evolution]

Looks good to me, though I have some clarifying questions. For a type which
conforms to both Equatable and Hashable:

1. To automatically derive both Equatable and Hashable, will it be
sufficient to declare “struct Foo: Hashable” (since Hashable refines
Equatable) or must “Equatable” also be listed?

2. Will it be possible to automatically derive “==” while manually
implementing “hashValue”?
2a. If so, will “Equatable” and “Hashable” both need to appear in the
declaration, or will “Hashable” alone suffice?

3. Will it be possible to automatically derive “hashValue” while manually
implementing “==”?
3a. If so, will “Equatable” and “Hashable” both need to appear in the
declaration, or will “Hashable” alone suffice?

Thanks,

Nevin


On Wed, Aug 9, 2017 at 11:36 AM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> Now that Swift 5 is taking proposals, I'm dusting off my proposal to
> synthesize Equatable/Hashable conformance for enums and structs. I had
> implemented this a few months ago hoping to squeeze it in by the Swift 4
> deadline, but unfortunately the timeline was too tight.
>
> The pull request for the proposal is here: https://github.com/
> apple/swift-evolution/pull/706. (Direct link to proposal text:
> https://github.com/allevato/swift-evolution/blob/
> b3dcffc2e6f74e17eba05a6eb7eb29ad58bf36a3/proposals/-
> synthesize-equatable-hashable.md)
>
> The pull request for the implementation (rebased last night) is here:
> https://github.com/apple/swift/pull/9619
>
> Thanks all!
>
>
> ___
> 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 5: start your engines

[John McCall via swift-evolution]

> On Aug 9, 2017, at 2:30 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Upfront costs *will* be higher. Not only do you have to believe that a 
>> change is good, you must develop a working group that includes coders to 
>> create a prototype without any guarantee that the change will pass muster. 
>> 
>> Finding those coders and convincing them this will be a great change means 
>> that proposals will naturally skew towards Apple-driven rather than wider 
>> community-driven. However it does not exclude the latter, especially for 
>> passionate proposals that can find the coders to champion them.
> 
> I too think this is probably a positive step. I'd also like to point out a 
> couple things (while reminding you that I am *not* on the core team and speak 
> for nobody but myself):
> 
>   1. Compiler engineering is not magic. It is *especially* not magic when 
> you're largely dealing with syntax and semantics, rather than code 
> generation. I know it's intimidating, because a year ago I was pretty 
> intimidated by it, but it's basically just programming in a large, 
> complicated project with lots of weird speed hacks. And most of the standard 
> library isn't compiler engineering at all—it's just Swift code written with a 
> weird house style that forbids `private` and `fileprivate`. Anybody who knows 
> enough Swift to express an intelligent opinion on its evolution should know 
> enough to do some standard library work.
> 
>   2. We have persistently had too many designs for the available 
> implementers. If we find that this new process overshoots and we now have too 
> many implementers for the available designs, we can change the process again 
> to loosen the "must include an implementation" requirement. (For instance, we 
> might allow simpler testbed or proof-of-concept implementations, like hacky 
> preprocessors or slightly different userspace syntaxes of things that will 
> move into the compiler, when a full implementation would be too difficult to 
> provide ahead of time.)
> 
> I do have some concerns about this process. I'm worried that, unless we 
> really firm up the pre-review process, we'll end up wasting a lot of 
> implementation time on stuff that never actually makes it into the language.

The formal review has always just been a capstone of the real design process, 
i.e. the process of developing the proposal.  Up until now, that capstone has 
been a lot less meaningful than it could be because there's no choice but to 
speculate about the actual effects of the change: whether they'll really be 
able to use it in all the places they think they will, how disruptive a 
potential source break would be, how much performance the feature actually 
gains/loses, etc.  Some amount of speculation is appropriate — we shouldn't 
design just for the code that exists today — but there's no replacement for the 
experience of actually trying to use a feature in code that you're comfortable 
with.

So today we have this basic development process for proposals:
  1. initial proposal development (often semi-private)
  2. presentation to swift-evolution
  3. iterative open proposal development
  4. formal review, goto 3 until confluence
  5. implementation
  6. feedback from implementation experience, goto 3 until confluence
  7. available in a nightly build or official developer preview
  8. feedback from adopters, goto 3 until confluence
  9. ship it

6 and 8 will always be meaningful sources of feedback with a potential to 
provoke a revision.  We can never completely eliminate the potential for such 
feedback to arrive after the formal review, because sometimes use or 
implementation problems only become fully apparent after you've been living 
with the design for a while.  Still, it's somewhat absurd to ask for "final" 
approval for something that hasn't gone through 6 or 8 at all, and we're seeing 
the predictable result, where far too many proposals that are going through 
re-review or requiring follow-up proposals.

The Swift 5 process will hopefully look more like this:
  1. initial proposal development (often semi-private)
  2. presentation to swift-evolution
  3. iterative open proposal development
  5. implementation
  6. feedback from implementation experience, goto 3 until confluence
  7. available for early "adoption" testing as a PR branch, ideally as a 
special toolchain build
  8. feedback from early "adopters", goto 3 until confluence
  "4". formal review, goto 3 until confluence
  9. ship it

Your role as a proposal author really hasn't substantially changed.  It's 
always been the case that getting something through formal review is no 
guarantee that it will ever be implemented, so you've never been able to just 
wash your hands and walk way, and you've always needed to find an implementor.  
The only thing that's 

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 5:54 AM, Daniel Vollmer via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 9. Aug 2017, at 06:51, Taylor Swift via swift-users <
> swift-us...@swift.org> wrote:
> >
> > It’s possible to implement a classic red-black tree in Swift that
> performs better than a sorted Array, down to about n = 1,500 items, not n =
> 100,000 items as it claims. (Actually, heap allocators these days are good
> enough that performance is on par with Array all the way down to n = 1.)
>
> I’m not sure how that can be because you lose locality (but that probably
> depends on what operations “perform” includes). And IMO, heap allocations
> remain (and will remain) a bottleneck for small allocations.
>
> Daniel.
> ___
>
>
If the number of nodes is small, Swift’s heap allocator will actually place
then contiguously in memory, just like an Array, as long as you don’t wait
too long between calls to insert(_:). You can also write your own simple
memory allocator in Swift that’s backed by an Array which guarantees the
nodes will live near each other in memory. But that’s getting off topic lol
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Matthew Johnson via swift-evolution]

Hi Jordan,

Thanks for bringing this topic up again!  I’m glad to see it will receive 
attention in Swift 5.  I agree with the semantics of your proposed direction.  

In terms of syntax, I continue to believe that requiring users to specify a 
keyword indicating open or closed *in addition* to public would be unfortunate. 
 Open / closed is only relevant for public enums and therefore implies public.  
We’ve done a really good job of avoiding keyword soup in Swift and the way that 
open classes are implicitly public is a good precedent that we should follow.

I also continue to believe that aligning protocols, enums and classes to use 
consistent terminology for similar concepts has many advantages.  The semantics 
would be:

* open: Extensible outside the library
* public: Extensible in future versions of the library (or privately by the 
library)
* closed: Fixed set of publicly visible cases / subclasses / conformances 
defined by the library and guaranteed not to change without breaking ABI and 
source compatibility.

This approach makes public a “soft default” that preserves maximum flexibility 
for the library author while allowing them to make a stronger guarantee of 
user-extensibility or completeness by changing (rather than adding) a keyword.  
It also highlights the symmetry of the two very different user-guarantees a 
library may choose to support.

As noted in my previous thread, this approach would require a migration for 
protocols as well as enums as the current behavior of public protocols is to 
allow conformances outside the library.

There are certainly reasonable arguments to be made for other approaches, 
particularly if there is no appetite for changing the semantics of public 
protocols (which seems likely).  Nevertheless, I think we should keep the 
merits of consistency in mind and understand the benefits of alternatives 
relative to the more consistent approach as we evaluate them.

In terms of alternatives, what is your opinion on using public as a “soft 
default” and assigning it one of the two enum semantics you discuss?  Do you 
think this makes sense or would you prefer distinct keywords for these two 
semantics?  I don’t have any really great new ideas, but I’ll throw out 
“complete” and “incomplete” as a possibility.

My two cents for now…

Matthew


> On Aug 8, 2017, at 5:27 PM, Jordan Rose via swift-evolution 
>  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 

Re: [swift-evolution] SE-184 Improved Pointers

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick  wrote:

>
> On Aug 8, 2017, at 11:10 PM, Taylor Swift  wrote:
>
>
> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick  wrote:
>
>>
>> On Aug 8, 2017, at 8:44 PM, Taylor Swift  wrote:
>>
>> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot
>> find such a function anywhere in the API. There is copyBytes(from:)
>> ,
>> but the documentation is messed up and mentions a nonexistent count:
>> argument over and over again. The documentation also doesn’t mention what
>> happens if there is a length mismatch, so users are effectively relying on
>> an implementation detail. I don’t know how to best resolve this.
>>
>>
>> We currently have `UnsafeMutableRawBufferPointer.copyBytes(from:)`. I
>> don’t think your proposal changes that. The current docs refer to the
>> `source` parameter, which is correct. Docs refer to the parameter name, not
>> the label name. So `source.count` is the size of the input. I was pointing
>> out that it has the semantics: `debugAssert(source.count <= self.count)`.
>>
>> Your proposal changes `UnsafeRawPointer.copyBytes(from:count:)` to
>> `UnsafeRawPointer.copy(from:bytes:)`. Originally we wanted to those API
>> names to match, but I’m fine with your change. What is more important is
>> that the semantics are the same as `copyBytes(from:)`. Furthermore, any new
>> methods that you add that copy into a raw buffer (e.g.
>> initializeMemory(as:from:count:)) should have similar behavior.
>>
>>
> I’m fine with switching to taking the count from the source, though I
> think taking the count from the destination is slightly better because 1)
> the use cases I mentioned in the other email, and 2) all the other
> memorystate functions use self.count instead of source.count, if they
> take a source argument. But being consistent with the raw pointer version
> is more important.
>
>
> If it’s copying from a buffer it should not take a count, if it’s copying
> from a pointer it obviously needs to take a count. What I mean by the two
> versions being named consistently is simply that they’re both named
> `copyBytes`. That really isn’t important though. The overflow/underflow
> semantics being consistent are important.
>
> (Incidentally, the reason “bytes” needs to be in the somewhere name is
> because this method isn’t capable of copying nontrivial values)
>
> Should the methods that don’t deal with raw buffers also be modified to
> use the source argument (i.e. UnsafeMutableBufferPointer.
> initialize(from:))?
>
>
> I’m not sure what you mean by this. It also allows the destination to be
> larger than the source. Initializing from a sequence does not trap on
> overflow because we can’t guarantee the size of the sequence ahead of time.
> When I talk about consistent overflow/underflow semantics, I’m only talking
> about initializing one unsafe buffer/pointer from another unsafe
> buffer/pointer.
>
> Also, was there a reason why UnsafeMutableRawBufferPointer.
> copyBytes(from:) uses the source’s count instead of its own? Right now
> this behavior is “technically” undocumented behavior (as the public docs
> haven’t been updated) so if there was ever a time to change it, now would
> be it.
>
>
> Mainly because partial initialization is more expected than dropping data
> on the floor. Ultimately, this should be whatever typical developers would
> expect the behavior to be. I would be very hesitant to change the behavior
> now though.
>
> -Andy
>

The problem is I would expect to be able to safely call deinitialize() and
friends after calling initialize(from:). If Element is a class type and
initialize doesn’t fill the entire buffer range, calling deinitialize()
will crash. That being said, since copy(from:bytes:) and copyBytes(from:)
don’t do any initialization and have no direct counterparts in
UnsafeMutableBufferPointer, it’s okay if they have different behavior than
the other methods.


>
> —
>>
>> Another thing. The initialization methods that you’re adding to
>> `UnsafeRawPointer` and `UnsafeRawBufferPointer` should return typed
>> `UnsafePointer` and `UnsafeBufferPointer` respectively.
>>
>
> I’ll fix that once the current pending edit
>  gets merged.
>
>
>>
>> Thanks,
>>
>> -Andy
>>
>> On Tue, Aug 8, 2017 at 11:33 PM, Andrew Trick  wrote:
>>
>>>
>>> On Aug 8, 2017, at 8:29 PM, Taylor Swift  wrote:
>>>
>>>
>>>
>>> On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick  wrote:
>>>

 On Aug 8, 2017, at 6:51 PM, Taylor Swift  wrote:



 On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick  wrote:

>
> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
>>
>> Well, I think it's somewhat 

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

[Matthew Johnson via swift-evolution]

Hi Tony.  I’m really glad to see you’re brining this proposal back right away.  
It was a shame that it missed the deadline for Swift 4 and will be awesome to 
have it accepted for Swift 5.

> On Aug 9, 2017, at 10:36 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Now that Swift 5 is taking proposals, I'm dusting off my proposal to 
> synthesize Equatable/Hashable conformance for enums and structs. I had 
> implemented this a few months ago hoping to squeeze it in by the Swift 4 
> deadline, but unfortunately the timeline was too tight.
> 
> The pull request for the proposal is here: 
> https://github.com/apple/swift-evolution/pull/706 
> . (Direct link to proposal 
> text: 
> https://github.com/allevato/swift-evolution/blob/b3dcffc2e6f74e17eba05a6eb7eb29ad58bf36a3/proposals/-synthesize-equatable-hashable.md
>  
> )
> 
> The pull request for the implementation (rebased last night) is here: 
> https://github.com/apple/swift/pull/9619 
> 
> 
> Thanks all!
> 
> ___
> 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] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

[Tony Allevato via swift-evolution]

Now that Swift 5 is taking proposals, I'm dusting off my proposal to
synthesize Equatable/Hashable conformance for enums and structs. I had
implemented this a few months ago hoping to squeeze it in by the Swift 4
deadline, but unfortunately the timeline was too tight.

The pull request for the proposal is here:
https://github.com/apple/swift-evolution/pull/706. (Direct link to proposal
text:
https://github.com/allevato/swift-evolution/blob/b3dcffc2e6f74e17eba05a6eb7eb29ad58bf36a3/proposals/-synthesize-equatable-hashable.md
)

The pull request for the implementation (rebased last night) is here:
https://github.com/apple/swift/pull/9619

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

Re: [swift-evolution] ExpressibleByStringInterpolation

[Zach Waldowski via swift-evolution]

I like the proposal so far and would be happy seeing this in 4.1, even.
;) I don’t know/remember the conditions under which the previous
implementation was deemed unsuitable, but this addresses most of my
personal qualms with it.

My primary interests in an interpolation align with yours: in addition
to things like SQL statements, I want string literals to improve aspects
of Apple’s frameworks like localization and (especially of interest to
me) logging. The `StringInterpolationSegment` design allows those
interests to be satisfied by limiting the acceptable interpolation
types, which is pretty nice. At the compiler QoL level, the error
handling for this will have to be pretty spiffy though.

My only suggestion for proposed given design would be to consider making
`case interpolation(Interpolation)` take a `() throws -> Interpolation`
instead to allow for lazy evaluation, basically acting like an
autoclosure. In your SQLStatement 

I actually don’t mind the buffer approach; it aligns reasonably with
Codable’s semantics. I understand the cons there are significant. It
comes down to extensibility; the proposed design is reasonable if we
can’t think of any potential ways to extend interpolation, since the
segment enum will have to be closed.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Wed, Aug 9, 2017, at 12:08 AM, Brent Royal-Gordon via swift-evolution
wrote:
> I had a proposal for replacing/reintroducing
> `ExpressibleByStringInterpolation` (which is currently deprecated pending
> a redesign), but it landed too late in the Swift 4 cycle to be
> considered. The PR is here:
> https://github.com/apple/swift-evolution/pull/659
> 
> I think it squares up relatively well against the Swift 5 standards:
> 
> * It addresses ABI stability and strings, which are both Swift 5 themes.
> 
> * It includes an implementation, but it definitely needs a rebase,
> probably needs someone more experienced than me to examine it with a
> fine-toothed comb, and might need a significant redesign.
> 
> * I believe it includes tests.
> 
> * I don't think it's been run against the source compatibility suite. (Is
> there a way for random outside developers to do that?)
> 
> So what's the next step at this point?
> 
> -- 
> 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] Enums and Source Compatibility

[Zach Waldowski via swift-evolution]

I disagree. Closed is indeed the stronger guarantee, but APIs are
designed differently in Swift; closed is a sensible default. We
shouldn’t need to define new keywords and increase the surface area of
the language for something that has verisimilitude with the existing
open syntax.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me


On Wed, Aug 9, 2017, at 06:23 AM, David Hart via swift-evolution wrote:> 
> 
> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution  evolut...@swift.org> wrote:>> Hi Jordan, is that only me or haven't you 
> metioned the default should
>> be applied to all new enums? Personally I'd say that 'closed' should
>> be the default and the 'open' enum would require an extra keyword.> 
> I think it should definitely be the other way round for public enums
> because closed is the stronger guarantee. Final is the default for
> classes because open is the stronger guarantee. That’s probably why we
> should not use the same keywords.> 
>> Now about the keyword itself. Here are two keywords that IMHO nail
>> their behavior down to the point:>> 
>> finite enum A {} - so to say a closed enum (default)
>> infinite enum B {} - so to say an open enum (requires default case in
>> a switch statement)>> 
>> If you think the default should be the other way around, than feel
>> free to switch that. 'finite' also implies that the enum connot ever
>> be extended with more cases (to become infinite), which was also
>> mentioned in your email.>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> Am 9. August 2017 um 00:27:53, Jordan Rose via swift-evolution (swift-
>> evolut...@swift.org) schrieb:>>> 
>>> 
>>> 
>>> 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? 

[swift-evolution] [discussion] What generics feature would this be?

[Mathew Huusko V via swift-evolution]

Curious what part of generics the below would fall under? This hit me by
surprise/makes even non-generic/Self-depending protocols un-interchangeable
with classes..

```
protocol Special {}

func doWithAndReturn(_ special: S) -> S { ... }

let special: Special = ...

// "error: Generics parameter 'S' could not be inferred"
// works fine when 'Special' is a class
let newSpecial: Special = doWithAndReturn(special)
```
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [discussion] Class stored properties?

[Charlie Monroe via swift-evolution]

Hi,

can you provide a usecase for this? I remember this being used in ObjC for 
+version, but I'm not sure anymore where I'd use this...

BTW you don't need to stringify, use ObjectIdentifier (part of stdlib).

> On Aug 9, 2017, at 12:54 PM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> Curious if class stored properties have ever been discussed (doesn't seem 
> so..)?
> 
> Also, assuming no, and assuming there's a good reason no/they're not coming 
> anytime soon, what are some patterns people have been using in their place? I 
> was considering something like..
> 
> class SomeClass {
> private static var _classValues = [SomeClass.Type: Int]()
> 
> class var value: Int {
> get { _classValues[self] }
> set { _classValues[self] = newValue }
> }
> }
> 
> .. but then I remembered types aren't hashable yet either (so I guess I need 
> to stringify it first).
> ___
> 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] [discussion] Class stored properties?

[Mathew Huusko V via swift-evolution]

Curious if class stored properties have ever been discussed (doesn't seem
so..)?

Also, assuming no, and assuming there's a good reason no/they're not coming
anytime soon, what are some patterns people have been using in their place?
I was considering something like..

class SomeClass {
private static var _classValues = [SomeClass.Type: Int]()

class var value: Int {
get { _classValues[self] }
set { _classValues[self] = newValue }
}
}

.. but then I remembered types aren't hashable yet either (so I guess I
need to stringify it first).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[David Hart via swift-evolution]

> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hi Jordan, is that only me or haven't you metioned the default should be 
> applied to all new enums? Personally I'd say that 'closed' should be the 
> default and the 'open' enum would require an extra keyword.

I think it should definitely be the other way round for public enums because 
closed is the stronger guarantee. Final is the default for classes because open 
is the stronger guarantee. That’s probably why we should not use the same 
keywords.

> Now about the keyword itself. Here are two keywords that IMHO nail their 
> behavior down to the point:
> 
> finite enum A {} - so to say a closed enum (default)
> infinite enum B {} - so to say an open enum (requires default case in a 
> switch statement)
> 
> If you think the default should be the other way around, than feel free to 
> switch that. 'finite' also implies that the enum connot ever be extended with 
> more cases (to become infinite), which was also mentioned in your email.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 9. August 2017 um 00:27:53, Jordan Rose via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> 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 
>> 

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

[Daniel Vollmer via swift-evolution]

> On 9. Aug 2017, at 06:51, Taylor Swift via swift-users 
>  wrote:
> 
> It’s possible to implement a classic red-black tree in Swift that performs 
> better than a sorted Array, down to about n = 1,500 items, not n = 100,000 
> items as it claims. (Actually, heap allocators these days are good enough 
> that performance is on par with Array all the way down to n = 1.)

I’m not sure how that can be because you lose locality (but that probably 
depends on what operations “perform” includes). And IMO, heap allocations 
remain (and will remain) a bottleneck for small allocations.

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

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

[Yuta Koshizawa via swift-evolution]

I am not sure if removing initializers from `SetAlgebra` does not cause any
problems in the standard library, it seems reasonable for me if range types
could adopt `SetAlgebra`.


`SetAlgebra` contains some mutating methods like `insert`, `remove`,
`formUnion`. It means it is impossible for range types to adopt
`SetAlgebra`. In addition, even if we remove such methods from
`SetAlgebra`, because the return type of something like `union` is `Self`,
`2..3.union(5...7)` cannot be represented.

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

Re: [swift-evolution] Enums and Source Compatibility

[Adrian Zubarev via swift-evolution]

Hi Jordan, is that only me or haven't you metioned the default should be 
applied to all new enums? Personally I'd say that 'closed' should be the 
default and the 'open' enum would require an extra keyword.  

Now about the keyword itself. Here are two keywords that IMHO nail their 
behavior down to the point:  

finite enum A {} - so to say a closed enum (default)  
infinite enum B {} - so to say an open enum (requires default case in a switch 
statement)

If you think the default should be the other way around, than feel free to 
switch that. 'finite' also implies that the enum connot ever be extended with 
more cases (to become infinite), which was also mentioned in your email.

--  
Adrian Zubarev
Sent with Airmail  

Am 9. August 2017 um 00:27:53, Jordan Rose via swift-evolution 
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

>  
> 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 Apple's 
> frameworks again.) I don't have a great answer, though.
>  
> For people who like exhaustive switches, we thought about adding a new kind 
> of 'default'—let's call it 'unknownCase' just to be able to talk about it. 
> This lets you get warnings 

Re: [swift-evolution] Swift 5: start your engines

[Ted Kremenek via swift-evolution]

The project would definitely be well-served by having more documentation, and 
hopefully we’ll see that grow both incrementally and in spurts.  Even writing 
tutorials, however, must be weighed against competing priorities — such as 
finishing the work for ABI stability.  My hope is we can find a balance of 
investment in helping more people in the community feel empowered to implement 
proposals in the compiler/standard library while not diluting focus from 
delivering ABI stability.

> On Aug 8, 2017, at 11:28 PM, Jonathan Hull  wrote:
> 
> Would it be possible to get a series of tutorials on how the systems that 
> make up Swift generally work?  In other words, what are the pieces and how do 
> they fit together?
> 
> I think it would be useful even for people who aren’t directly implementing 
> because they can have a better idea of how difficult a change actually is.  
> It might also help some of us who have been sitting on the sideline to dip 
> our toes in the water.  I know I get a bit lost every time I try to find 
> something in the Swift source, and I am guessing I am not the only one...
> 
> Thanks,
> Jon
> 
> 
>> On Aug 8, 2017, at 5:27 PM, Ted Kremenek via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On Aug 8, 2017, at 2:29 PM, Paul Cantrell >> > wrote:
>>> 
>>> I imagine that the core team will assist in providing implementations for 
>>> proposals that are crucial to the progress of the language and/or highly 
>>> popular — regardless of whether the proposal was authored by the core team 
>>> or a community member.
>>> 
>> 
>> That is true.  Everyone’s ability to assist is ultimately balanced by their 
>> own capacity and priorities, but I think there are plenty of examples of 
>> this happening in the past.  Also, there is a increasing number of people — 
>> and not just the Core Team or compiler engineers in my team at Apple — who 
>> are becoming increasingly comfortable working with the implementation of the 
>> compiler and the standard library.
>> ___
>> 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 5: start your engines

[Goffredo Marocchi via swift-evolution]

Async / await is really spoiling me in Node.JS at the moment, you leave with 
shiver with anticipation!!! :)

Sent from my iPhone

> On 9 Aug 2017, at 06:41, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution 
>>  wrote:
>> 
>> is it accept proposal for coroutine?
>> Just like the one i had proposed before: 
>> https://github.com/apple/swift-evolution/pull/73
> 
> Hi Susan,
> 
> I’d love to see progress on this specific topic, with specific application to 
> async/await.  I have a much more detailed proposal in the works, I’ll share 
> it when it is ready.
> 
> -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] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 8, 2017, at 11:10 PM, Taylor Swift  wrote:
> 
> 
> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick  > wrote:
> 
>> On Aug 8, 2017, at 8:44 PM, Taylor Swift > > wrote:
>> 
>> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot find 
>> such a function anywhere in the API. There is copyBytes(from:) 
>> ,
>>  but the documentation is messed up and mentions a nonexistent count: 
>> argument over and over again. The documentation also doesn’t mention what 
>> happens if there is a length mismatch, so users are effectively relying on 
>> an implementation detail. I don’t know how to best resolve this.
> 
> We currently have `UnsafeMutableRawBufferPointer.copyBytes(from:)`. I don’t 
> think your proposal changes that. The current docs refer to the `source` 
> parameter, which is correct. Docs refer to the parameter name, not the label 
> name. So `source.count` is the size of the input. I was pointing out that it 
> has the semantics: `debugAssert(source.count <= self.count)`.
> 
> Your proposal changes `UnsafeRawPointer.copyBytes(from:count:)` to 
> `UnsafeRawPointer.copy(from:bytes:)`. Originally we wanted to those API names 
> to match, but I’m fine with your change. What is more important is that the 
> semantics are the same as `copyBytes(from:)`. Furthermore, any new methods 
> that you add that copy into a raw buffer (e.g. 
> initializeMemory(as:from:count:)) should have similar behavior.
> 
>  
> I’m fine with switching to taking the count from the source, though I think 
> taking the count from the destination is slightly better because 1) the use 
> cases I mentioned in the other email, and 2) all the other memorystate 
> functions use self.count instead of source.count, if they take a source 
> argument. But being consistent with the raw pointer version is more important.

If it’s copying from a buffer it should not take a count, if it’s copying from 
a pointer it obviously needs to take a count. What I mean by the two versions 
being named consistently is simply that they’re both named `copyBytes`. That 
really isn’t important though. The overflow/underflow semantics being 
consistent are important.

(Incidentally, the reason “bytes” needs to be in the somewhere name is because 
this method isn’t capable of copying nontrivial values)

> Should the methods that don’t deal with raw buffers also be modified to use 
> the source argument (i.e. UnsafeMutableBufferPointer.initialize(from:))?

I’m not sure what you mean by this. It also allows the destination to be larger 
than the source. Initializing from a sequence does not trap on overflow because 
we can’t guarantee the size of the sequence ahead of time. When I talk about 
consistent overflow/underflow semantics, I’m only talking about initializing 
one unsafe buffer/pointer from another unsafe buffer/pointer.

> Also, was there a reason why UnsafeMutableRawBufferPointer.copyBytes(from:) 
> uses the source’s count instead of its own? Right now this behavior is 
> “technically” undocumented behavior (as the public docs haven’t been updated) 
> so if there was ever a time to change it, now would be it.

Mainly because partial initialization is more expected than dropping data on 
the floor. Ultimately, this should be whatever typical developers would expect 
the behavior to be. I would be very hesitant to change the behavior now though.

-Andy

> —
> 
> Another thing. The initialization methods that you’re adding to 
> `UnsafeRawPointer` and `UnsafeRawBufferPointer` should return typed 
> `UnsafePointer` and `UnsafeBufferPointer` respectively.
> 
> I’ll fix that once the current pending edit 
>  gets merged.
>  
> 
> Thanks,
> 
> -Andy
> 
>> On Tue, Aug 8, 2017 at 11:33 PM, Andrew Trick > > wrote:
>> 
>>> On Aug 8, 2017, at 8:29 PM, Taylor Swift >> > wrote:
>>> 
>>> 
>>> 
>>> On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick >> > wrote:
>>> 
 On Aug 8, 2017, at 6:51 PM, Taylor Swift > wrote:
 
 
 
 On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick > wrote:
 
> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
> 
> Well, I think it's somewhat ridiculous for users to write this every time 
> they allocate a buffer:
> 
> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: 
> MemoryLayout.alignment)`
> 
> If anyone reading the code is unsure about the Swift API's alignment
> guarantee, it's trivial to check the API docs.
> 
> You could 

Re: [swift-evolution] Swift 5: start your engines

[Brent Royal-Gordon via swift-evolution]

> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Upfront costs *will* be higher. Not only do you have to believe that a change 
> is good, you must develop a working group that includes coders to create a 
> prototype without any guarantee that the change will pass muster. 
> 
> Finding those coders and convincing them this will be a great change means 
> that proposals will naturally skew towards Apple-driven rather than wider 
> community-driven. However it does not exclude the latter, especially for 
> passionate proposals that can find the coders to champion them.

I too think this is probably a positive step. I'd also like to point out a 
couple things (while reminding you that I am *not* on the core team and speak 
for nobody but myself):

1. Compiler engineering is not magic. It is *especially* not magic when 
you're largely dealing with syntax and semantics, rather than code generation. 
I know it's intimidating, because a year ago I was pretty intimidated by it, 
but it's basically just programming in a large, complicated project with lots 
of weird speed hacks. And most of the standard library isn't compiler 
engineering at all—it's just Swift code written with a weird house style that 
forbids `private` and `fileprivate`. Anybody who knows enough Swift to express 
an intelligent opinion on its evolution should know enough to do some standard 
library work.

2. We have persistently had too many designs for the available 
implementers. If we find that this new process overshoots and we now have too 
many implementers for the available designs, we can change the process again to 
loosen the "must include an implementation" requirement. (For instance, we 
might allow simpler testbed or proof-of-concept implementations, like hacky 
preprocessors or slightly different userspace syntaxes of things that will move 
into the compiler, when a full implementation would be too difficult to provide 
ahead of time.)

I do have some concerns about this process. I'm worried that, unless we really 
firm up the pre-review process, we'll end up wasting a lot of implementation 
time on stuff that never actually makes it into the language. I'm also worried 
that we'll end up accepting sub-optimal designs because the alternative is to 
throw out a lot of work that's already been done and defer a feature to a 
future version. But again, we can refine the process as we notice its problems. 
All of these concerns are speculative; the concern that we don't have the 
implementation bandwidth needed for the current design process is very real.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Swift 5: start your engines

[Jonathan Hull via swift-evolution]

Would it be possible to get a series of tutorials on how the systems that make 
up Swift generally work?  In other words, what are the pieces and how do they 
fit together?

I think it would be useful even for people who aren’t directly implementing 
because they can have a better idea of how difficult a change actually is.  It 
might also help some of us who have been sitting on the sideline to dip our 
toes in the water.  I know I get a bit lost every time I try to find something 
in the Swift source, and I am guessing I am not the only one...

Thanks,
Jon


> On Aug 8, 2017, at 5:27 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> 
> 
>> On Aug 8, 2017, at 2:29 PM, Paul Cantrell > > wrote:
>> 
>> I imagine that the core team will assist in providing implementations for 
>> proposals that are crucial to the progress of the language and/or highly 
>> popular — regardless of whether the proposal was authored by the core team 
>> or a community member.
>> 
> 
> That is true.  Everyone’s ability to assist is ultimately balanced by their 
> own capacity and priorities, but I think there are plenty of examples of this 
> happening in the past.  Also, there is a increasing number of people — and 
> not just the Core Team or compiler engineers in my team at Apple — who are 
> becoming increasingly comfortable working with the implementation of the 
> compiler and the standard library.
> ___
> 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-users] How does "Sequence.joined" work?

[Félix Cloutier via swift-evolution]

The benefit that standard library containers have over containers from other 
modules is that they're optimized as if they were part of your own module, so 
you can get the same thing by including the collection classes in your own 
executable instead of linking with the module. It's my understanding that the 
@_transparent attribute could surface to the public side with module format 
stability.

Either way, the issue of cross-module optimizations is separate from COW 
mechanics, and it was certainly not my goal to distract anyone from the main 
topic by including an after-thought reference to an algorithmically impressive 
package. The important takeaway is that COW semantics don't rely on special 
features, joined() doesn't have to go out of its way to ensure that new storage 
isn't allocated, and the one important library feature behind these containers, 
isKnownUniquelyReferenced, lives in broad daylight.

> Le 8 août 2017 à 22:56, Taylor Swift  a écrit :
> 
> 
> 
> On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff  > wrote:
> On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users 
> > wrote:
> 
> 
> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution 
> > wrote:
> Yes, exactly. An Array is a struct wrapper for a reference type 
> representing storage. Mutating functions first check if they own the only 
> reference to the storage using isKnownUniquelyReferenced 
> .
>  If not, they make a fresh copy before applying the mutating operation.
> 
> There's no difference for `let` arrays. Access control is enforced at 
> compile-time through Array's design: the compiler will prevent you from 
> calling `mutating` functions on `let` structs, and Array is careful to not 
> expose functionality that could modify its storage outside of `mutating` 
> functions.
> 
> There is no secret. Anyone could implement the same thing only using publicly 
> available and documented compiler features. In fact, it's been done already 
> for some very powerful collections .
> 
> This isn’t entirely true. That BTree module readme seems to contain a lot of 
> unsubstantiated hyperbole. It’s possible to implement a classic red-black 
> tree in Swift that performs better than a sorted Array, down to about n = 
> 1,500 items, not n = 100,000 items as it claims. (Actually, heap allocators 
> these days are good enough that performance is on par with Array all the way 
> down to n = 1.) Red-Black trees are slow when distributed as packages because 
> of the crossmodule optimization boundary. (This also means the BTree module 
> is much slower than Array for most reasonable n.) It’s possible to write 
> modules using compiler attributes that mitigate this slowdown (reclaiming 
> over 50% of lost performance) but it’s hacky and forces you to design your 
> libraries like the standard library (meaning: ugly underscored properties 
> everywhere and everything is public). And these features aren’t “publicly 
> available” or documented at all. 
> 
> This seems harsh. I didn't notice Félix making any claims about BTree's 
> performance. The necessary API for implementing COW is indisputably public 
> and documented:
> 
> https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced
>  
> 
> 
> 
> I really didn’t mean it to be harsh (sorry if it sounded that way ), it’s 
> just that people tend to be overly optimistic about the performance that can 
> be achieved with custom Collection packages. It’s true that you can imitate 
> the functionality of stdlib Collection types with public and documented Swift 
> features, but such custom Collections (when distributed as packages) are 
> almost never effective at improving an application’s performance due to the 
> huge constant factor of cross module calls, unless the library author was 
> willing to make use of undocumented compiler features.
> 

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

Re: [swift-evolution] Swift 5: start your engines

[Jean-Daniel via swift-evolution]

> Le 9 août 2017 à 00:06, Erica Sadun via swift-evolution 
>  a écrit :
> 
> 
>> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>> Perhaps I am too optimistic, and core team members correct me if I am 
>> speaking out of turn here, but…
>> 
>> I imagine that the core team will assist in providing implementations for 
>> proposals that are crucial to the progress of the language and/or highly 
>> popular — regardless of whether the proposal was authored by the core team 
>> or a community member.
>> 
>> From what I know of the team, they’re not going to let a good idea languish 
>> just because of the name that’s in the author field. I’m sure they _are_ 
>> going to strategically prioritize what gets attention, and that’s not a bad 
>> thing.
>> 
>> Cheers,
>> 
>> Paul
> 
> Perhaps I'm being overly optimistic but I see this change as enhancing 
> collaboration between idea-level and code-level evolution. Requiring a 
> preliminary implementation:
> 
> Ensures a proof of concept that the proposed change (like expanding `Self` to 
> classes) is realistic and possible.
> Ensures that the Swift codebase impact can be measured at the time the 
> proposal is evaluated.
> Encourages multi-author proposal teams, comprised of people who understand 
> code impact as well those who can express the importance of the language 
> expression from a user side. 
> Provides real world "road testing" of proposed toolchain enhancements, 
> letting the changes be "tuned" before proposal. This minimizes adoption 
> regrets, because the beta toolchain can be used with real code. (As with the 
> tuples and closures)
And it will also avoid late changes and new review roundtrip to accepted 
proposals because we find that some points are ambiguous while implementing it.
And hopefully, it will also decrease the stack of non implemented accepted 
proposals.

> Upfront costs *will* be higher. Not only do you have to believe that a change 
> is good, you must develop a working group that includes coders to create a 
> prototype without any guarantee that the change will pass muster. 
> 
> Finding those coders and convincing them this will be a great change means 
> that proposals will naturally skew towards Apple-driven rather than wider 
> community-driven. However it does not exclude the latter, especially for 
> passionate proposals that can find the coders to champion them.
> 
> -- Erica
> 
> ___
> 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] range.contains(anotherRange)

[Yuta Koshizawa via swift-evolution]

2017-08-09 12:50 GMT+09:00 Robert Bennett :


It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks
the required initializers. Is there anything that can be done about this?
Actually, it makes me wonder whether those initializers should even be a
part of SetAlgebra — why must something implementing SetAlgebra be able to
be initialized as empty or from a finite sequence?


I am not sure if removing initializers from `SetAlgebra` does not cause any
problems in the standard library, it seems reasonable for me if range types
could adopt `SetAlgebra`.

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

Re: [swift-evolution] SE-184 Improved Pointers

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick  wrote:

>
> On Aug 8, 2017, at 8:44 PM, Taylor Swift  wrote:
>
> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot
> find such a function anywhere in the API. There is copyBytes(from:)
> ,
> but the documentation is messed up and mentions a nonexistent count:
> argument over and over again. The documentation also doesn’t mention what
> happens if there is a length mismatch, so users are effectively relying on
> an implementation detail. I don’t know how to best resolve this.
>
>
> We currently have `UnsafeMutableRawBufferPointer.copyBytes(from:)`. I
> don’t think your proposal changes that. The current docs refer to the
> `source` parameter, which is correct. Docs refer to the parameter name, not
> the label name. So `source.count` is the size of the input. I was pointing
> out that it has the semantics: `debugAssert(source.count <= self.count)`.
>
> Your proposal changes `UnsafeRawPointer.copyBytes(from:count:)` to
> `UnsafeRawPointer.copy(from:bytes:)`. Originally we wanted to those API
> names to match, but I’m fine with your change. What is more important is
> that the semantics are the same as `copyBytes(from:)`. Furthermore, any new
> methods that you add that copy into a raw buffer (e.g.
> initializeMemory(as:from:count:)) should have similar behavior.
>
>
I’m fine with switching to taking the count from the source, though I think
taking the count from the destination is slightly better because 1) the use
cases I mentioned in the other email, and 2) all the other memorystate
functions use self.count instead of source.count, if they take a source
argument. But being consistent with the raw pointer version is more
important.

Should the methods that don’t deal with raw buffers also be modified to use
the source argument (i.e. UnsafeMutableBufferPointer.initialize(from:))?

Also, was there a reason why UnsafeMutableRawBufferPointer.copyBytes(from:)
uses the source’s count instead of its own? Right now this behavior is
“technically” undocumented behavior (as the public docs haven’t been
updated) so if there was ever a time to change it, now would be it.

—
>
> Another thing. The initialization methods that you’re adding to
> `UnsafeRawPointer` and `UnsafeRawBufferPointer` should return typed
> `UnsafePointer` and `UnsafeBufferPointer` respectively.
>

I’ll fix that once the current pending edit
 gets merged.


>
> Thanks,
>
> -Andy
>
> On Tue, Aug 8, 2017 at 11:33 PM, Andrew Trick  wrote:
>
>>
>> On Aug 8, 2017, at 8:29 PM, Taylor Swift  wrote:
>>
>>
>>
>> On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick  wrote:
>>
>>>
>>> On Aug 8, 2017, at 6:51 PM, Taylor Swift  wrote:
>>>
>>>
>>>
>>> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick  wrote:
>>>

 > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
>
> Well, I think it's somewhat ridiculous for users to write this every
> time they allocate a buffer:
>
> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo:
> MemoryLayout.alignment)`
>
> If anyone reading the code is unsure about the Swift API's alignment
> guarantee, it's trivial to check the API docs.
>
> You could introduce a clearly documented default `alignedTo`
> argument. The reason I didn't do that is that the runtime won't
> respect it anyway. But I think it would be fair to go ahead with the
> API and file a bug against the runtime.
>

 Default argument of MemoryLayout.alignment is the way to go but
 as you said i don’t know if that is actually allowed/works. An alternative
 is to have two allocate methods each, one that takes an alignment argument
 and one that doesn’t (and aligns to pointer alignment) but that feels
 inelegant. Default arguments would be better.


 Default argument makes sense to me too. Then the raw buffer pointer and
 regular raw pointer APIs can be consistent with each other.

 Runtime bug: https://bugs.swift.org/browse/SR-5664


>>> yikes i was not aware of this. I don’t think it’s bad enough to warrant
>>> dropping the argument like with deallocate(capacity:) but I can imagine
>>> bad things happening to code that crams extra inhabitants into pointers.
>>>
>>>
>>> If we ever need to do pointer adjustment during deallocation to
>>> accommodate alignment, then I think the Swift runtime can track that. I see
>>> no reason to muddy the UnsafeRawPointer API with it. So, I agree with your
>>> proposed change to drop `alignedTo` there.
>>>
>>> -Andy
>>>
>>
>> oh lol I was talking about assuming the pointer returned by
>> allocate(bytes:alignedTo:) is a multiple of alignedTo. Some code might
>> be 

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Tino Heth via swift-evolution]

> If you’re into analogies, I see features like the generics improvements, 
> concurrency model, ownership system, macro system, ABI stability, new 
> frameworks, and other large scale efforts as the “bricks" that make up the 
> house of Swift.  In that analogy, smaller proposals are “mortar” that fills 
> in the cracks between the bricks.  If we add too much mortar too early on, we 
> run the risk of the house of Swift being built out of mortar, or of not being 
> able to fit the bricks into the right places.  That would be very bad, given 
> that we all want the house of Swift to be strong and beautiful over the long 
> term.

I really like this image — especially because it shows the need for a third 
ingredient:
Even with a perfect mixture of mortar and bricks, you'll end up with little 
more than a pile of rocks and clay if you don't have some kind of blueprint.

Of course, an analogy is just analogy, but I think especially under the light 
of the change of rules for the evolution process, it is even more important to 
have a bigger picture of the future Swift:
Instead of people just arguing for their favourite type of block to be 
integrated as soon as possible, I'd like to see more guidance on which 
additions fit into the plan, and how they interact with each other.
Not only because this might protected people from wasting their time with 
shaping the wrong bricks, but also to increase consistency in the language.

- Tino

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

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff  wrote:

> On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <
> swift-us...@swift.org> wrote:
>
>>
>>
>> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Yes, exactly. An Array is a struct wrapper for a reference type
>>> representing storage. Mutating functions first check if they own the only
>>> reference to the storage using isKnownUniquelyReferenced
>>> .
>>> If not, they make a fresh copy before applying the mutating operation.
>>>
>>> There's no difference for `let` arrays. Access control is enforced at
>>> compile-time through Array's design: the compiler will prevent you from
>>> calling `mutating` functions on `let` structs, and Array is careful to not
>>> expose functionality that could modify its storage outside of `mutating`
>>> functions.
>>>
>>> There is no secret. Anyone could implement the same thing only using
>>> publicly available and documented compiler features. In fact, it's been
>>> done already for some very powerful collections
>>> .
>>>
>>
>> This isn’t entirely true. That BTree module readme seems to contain a lot
>> of unsubstantiated hyperbole. It’s possible to implement a classic
>> red-black tree in Swift that performs better than a sorted Array, down
>> to about *n* = 1,500 items, not *n* = *100,000* items as it claims.
>> (Actually, heap allocators these days are good enough that performance is
>> on par with Array all the way down to *n* = 1.) Red-Black trees are slow
>> when *distributed* as packages because of the crossmodule optimization
>> boundary. (This also means the BTree module is much slower than Array
>> for most reasonable *n*.) It’s possible to write modules using compiler
>> attributes that mitigate this slowdown (reclaiming over 50% of lost
>> performance) but it’s hacky and forces you to design your libraries like
>> the standard library (meaning: ugly underscored properties everywhere and
>> everything is public). And these features aren’t “publicly available” or
>> documented at all.
>>
>
> This seems harsh. I didn't notice Félix making any claims about BTree's
> performance. The necessary API for implementing COW is indisputably public
> and documented:
>
> https://developer.apple.com/documentation/swift/2429905-
> isknownuniquelyreferenced
>
>
I really didn’t mean it to be harsh (sorry if it sounded that way ), it’s
just that people tend to be overly optimistic about the performance that
can be achieved with custom Collection packages. It’s true that you can
imitate the *functionality* of stdlib Collection types with public and
documented Swift features, but such custom Collections (when distributed as
packages) are almost never effective at improving an application’s
performance due to the huge constant factor of cross module calls, unless
the library author was willing to make use of undocumented compiler
features.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution