Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 12 Jan 2018, at 18:25, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 11, 2018, at 23:30, Chris Lattner  wrote:
>> 
>> 
>>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution 
>>>  wrote:
>>> 
>>> A question about the new #unknown behavior. Is it intended to be used for 
>>> error handling too ?
>>> Will it be possible to use in catch clause ?
>> 
>> If we go with the #unknown approach, then yes of course it will work in 
>> catch clauses.  They are patterns, so it naturally falls out.
> 
> It will not work in catch clauses because you need to have a static type 
> that's an enum. Catch clauses always (today…) have a static type of 'Error'.
> 
> 
>> 
>> If we go with the “unknown default:” / “unknown case:"  approach, then no, 
>> this has nothing to do with error handling.
>> 
>> IMO, this pivots on the desired semantics for “unknown cases in enums”: if 
>> you intentionally try to match on this, do we get a warning or error if you 
>> don’t handle all the cases?  If we can get to consensus on that point, then 
>> the design is pretty obvious IMO.
> 
> That's fair. I'm strongly in favor of a warning, though, because again, 
> people don't edit their dependencies.

A warning is better than nothing :), but for third party libraries you include 
in the app you are responsible for not updating to a library that would break 
your build and between compiler and automation catch this error before merging 
a PR and putting it in production. It is also your responsibility to reasonable 
choose a library that is properly maintained and vetted.

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

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Goffredo Marocchi via swift-evolution]

I am sorry, but I have to disagree here. Having two separate proposals would 
make it highly more likely that one thing is done and the other one postponed 
and postponed until it seems no longer relevant in the grand scheme of 
things... first we lost labels in callbacks / stores functions (has there been 
at least some Core Team chat about this after last year?) and now we are losing 
compiler enforced exhaustive switching over enum... not only that, until we 
improve diagnostic and at least warn users we are now even behind Objective-C 
as compiler can enforce exhaustive switching and actually mandate no default 
case for enums through a compiler warning.

Sent from my iPhone

> On 11 Jan 2018, at 04:31, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jan 10, 2018, at 10:10 AM, Jordan Rose  wrote:
>> 
 
 - Matching known cases is a feature, not a limitation, to avoid existing 
 code changing meaning when you recompile. I'll admit that's not the 
 strongest motivation, though, since other things can change the meaning of 
 existing code when you recompile already.
>>> 
>>> I’m not sure I understand this. 
>>> 
>>> The whole motivation for this feature is to notify people if they are not 
>>> handling a “newly known” case.  If they don’t care about this, they can 
>>> just use default.
>> 
>> Notify, yes. Error, no. It's a design goal that adding a new case does not 
>> break source compatibility in addition to not breaking binary compatibility 
>> (because people don't like editing their dependencies) and therefore the 
>> behavior has to be defined when they recompile with no changes.
>> 
> 
> Ok, if that’s the desired design, then (IMO) the right way to spell it is 
> “unknown default:” and it should have semantics basically aligned with the 
> design you laid out in the revision of the proposal.  If this is supposed to 
> be an error, then it should be a pattern production.
> 
> Do you have a sense for whether this is what people want?  We really should 
> have a review cycle evaluating exactly this sort of tradeoff.
> 
> In any case, I’ve said this before off-list, but I find this whole discussion 
> (of how to improve diagnostics for unknown cases) to be separable from the 
> core issue required to get to ABI stability.  It seems to me that we could 
> split this (ongoing) design discussion off into a separate SE, allowing you 
> to get on with the relatively uncontroversial and critical parts in SE-0192.
> 
> -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] [Review] SE 0192 - Non-Exhaustive Enums

[Goffredo Marocchi via swift-evolution]

Add -Weverything and you can ensure you are switching exhaustively ;).

Sent from my iPhone

> On 8 Jan 2018, at 19:02, Javier Soto via swift-evolution 
>  wrote:
> 
> This is very much an issue in Obj-C today. If you have an NS_ENUM defined 
> with cases A, B, and C, this switch is correct:
> 
> int foo;
> swith (e) { 
> case A: foo = 0; break;
> case B: foo = 1; break;
> case C: foo = 2; break;
> }
> 
> (Note the lack of a default case)
> 
> If that enum is defined in a framework and it changes after the app is 
> compiled (like it's the case with Apple frameworks), then that code produces 
> no warning, yet the foo variable will have a garbage value (undefined 
> behavior, but as far as the compiler can tell at compile time your code is 
> fine)
> 
> Adding a default clause to that switch has the downside of not getting 
> warnings for new added cases, like has been discussed before, which is very 
> useful.
>> On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution 
>>  wrote:
>> At this point I think it might be useful to outline how binary compatibility 
>> works for Objective-C on Apple platforms right now. As an app developer I’m 
>> not intimately familiar with what happens when you run an app compiled with 
>> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code 
>> paths or something else? The more this thread goes on the more confused I 
>> get about why Swift would have this issue while it doesn’t appear to be one 
>> for Obj-C. If an enum adds a case now, I don’t have to care until I 
>> recompile using the new SDK. Is the intention for Swift to be different in 
>> this regard?
>> 
>> 
>> 
>> Jon Shier
>> 
>>> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
  wrote:
 
 Is it hard to imagine that most everyone can get what they want and keep 
 the syntax clean and streamlined at the same time? Without any "@" signs 
 or other compiler hints?
>>> 
>>> For what it's worth, the original version of the proposal started with a 
>>> modifier (a context-sensitive keyword, like 'final'), but the core team 
>>> felt that there were a lot of modifiers in the language already, and this 
>>> didn't meet the bar.
>>> 
>>> 
> "Rather, we are how to enable the vendor of a nonexhaustive enum to add 
> new cases without breaking binaries compiled against previous versions"
 
 When an enum changes, and the change causes the code to break, the user 
 can be presented with migration options from an automated IDE tool. In 
 what specific way does this not solve the issue about having to upgrade 
 your code when using someone else's code library? This very notion implies 
 your disgruntled about doing work when things are upgraded, is that really 
 what this fuss is all about?
 
 A well written language interpreter and auto-tooling IDE would not need 
 hints embedded in the code syntax itself. Migration hints from version to 
 version should not be a part of either the past or future version of the 
 code library.
>>> 
>>> Thanks for bringing this up! Unfortunately, it falls down in practice, 
>>> because if there's a new enum case, it's unclear what you want to do with 
>>> it. If you're handling errors, it's not obvious that the way you've handled 
>>> any of the other errors is appropriate. In the (admittedly controversial) 
>>> SKPaymentTransactionState case, none of the existing code would be 
>>> appropriate to handle the newly-introduced "deferred" case, and nor could 
>>> StoreKit provide "template" code that would be appropriate to the client 
>>> app.
>>> 
>>> 
>>> In any case, though, the key point on this particular quoted sentence is 
>>> "without breaking binaries". Any such change must be valid without 
>>> recompilation, and indeed without any intervention from the developer or an 
>>> IDE, because that's what happens when the user updates their OS.
>>> 
>>> Jordan
>>> 
>>> 
>>> 
 
 ...
 
 I don't expect the community to agree on language grammar, but the common 
 sense here on how to achieve the intended goals seems to be out of wack.
 
 If someone can present a clear logical statement as to how an automated 
 migration tool behind the scenes in the IDE to handle all your versioning 
 worries, does not make this whole discussion about adding more convoluted 
 syntax additions irrelevant, I'd love to hear it.
 
 ___
 
 Sincerely,
 Jason
 
 
 
 
 
 
> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu  wrote:
>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution 
>>  wrote:
> 
>> I think this whole thing has been unnecessarily convoluted. As a result, 
>> the majority of the replies are rabbit holes.
>> 
>> In my opinion, the true root of the concept in ques

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

[Goffredo Marocchi via swift-evolution]

Fair concerns Gwendal, but why can’t the default in these cases be just 
exhaustive / frozen unless the library developer explicitly marks it as 
“unfrozen/non exhaustive” and the compiler can warn the users when they switch 
over it instead of throwing an error by default (the user can still treat 
warnings as errors if they want and suppress this warning if they wanted to in 
this vision)?

I think, sorry if I am being presumptions, that the onus in this case should be 
on the library author to mark enums and opt in in this non exhaustive 
behaviour. @Jordan what would the issue in this be?

Sent from my iPhone

> On 5 Jan 2018, at 09:11, Gwendal Roué  wrote:
> 
> 
>> Le 5 janv. 2018 à 09:11, Goffredo Marocchi via swift-evolution 
>>  a écrit :
>> 
>> I feel like this change will make the life easier for library authors, but 
>> risks making it easier and easier to make mistakes in apps using the 
>> libraries: exhaustive switching over enums is a good important feature that 
>> risks going away (the default matters) for not a huge effective benefit to 
>> app developers.
> 
> I agree that life is made worse for a library user that meets a non-frozen 
> enum. And I don't know if it makes the life easier for library authors, 
> because library authors not only throw code in the wild, but also try to 
> prevent library users from making the mistakes you talk about.
> 
> To take GRDB.swift as an example, it currently has 15 public enums. What are 
> my options?
> 
> More than half of those enums mirror SQLite C enums, or sets of related 
> SQLite values. SQLite is still a living piece of sofware, and it may adds new 
> cases or values in the future. It is then likely that GRDB has to be updated 
> as well. It thus looks like I can make those enums @frozen. But then it looks 
> like I betray the proposal's goal. What's the correct choice?
> 
> Some enums are like SKPaymentTransactionState: there's no way the user could 
> infer a proper behavior in a mandatory default/unknown switch case. I thus 
> also want to make them @frozen, and avoid headaches to the library users. 
> Will I pay for it later?
> 
> Some other enums are positively non-frozen. I may want to replace some of 
> them with a struct with a limited set of pre-built values. This would, IMHO, 
> improve the library UX because it would again prevent headaches for the 
> library users about scary "future" cases. In the struct with a limited set of 
> values, there is no future cases. Instead, there are a limited set of named 
> values. Which is a very different way to say the same thing.
> 
> This last paragraph draws a strong parallel between non-frozen enums and 
> structs:
> 
> // non-frozen enum:
> public enum E {
> case a, b
> }
> 
> // equivalent struct:
> public struct S: Equatable {
> private let value: Int
> private init(_ value: Int) { self.value = value }
> public static let a = S(1)
> public static let b = S(2)
> public static func == (lhs: S, rhs: S) -> Bool {
> return lhs.value == rhs.value
> }
> }
> 
> func f(_ s: S) {
> // S can be switched over just like a struct:
> switch s {
> case .a: print("a")
> case .b: print("b")
> default: print("unknown")
> }
> }
> 
> BTW, did anybody think about importing C enums as such structs?
> 
> Gwendal
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Code that ends up running in a default case somewhere in one of the several 
places you switch over that enum that you forgot about... well, it may not 
break source code compatibility, but it may introduce subtle bugs... submarine 
bugs.

Sent from my iPhone

> On 5 Jan 2018, at 08:11, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
>> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> Furthermore, the old code needs to continue working without source changes, 
>> because updating to a new SDK must not break existing code. (It can 
>> introduce new warnings, but even that is something that should be considered 
>> carefully.)
>> 
>> So: this proposal is designed to handle the use cases both for Swift library 
>> authors to come and for C APIs today, and in particular Apple's Objective-C 
>> SDKs and how they've evolved historically.
> 
> I will let your very comprehensive rationale brew a little bit more in my 
> mind and reread it, but I still think this is a bit leaning too much over to 
> library authors than library consumers (not unlike the closed by default 
> discussion we all had a while ago).
> 
> I remain very unconvinced by the “updating library/SDK” must be source 
> compatible. Especially if it is major version change and a deprecated method 
> has been removed, methods have changed signature, etc... Backward compatible 
> runtime with code compiled against the previous SDK yes, source compatible no.
> 
> I feel like this change will make the life easier for library authors, but 
> risks making it easier and easier to make mistakes in apps using the 
> libraries: exhaustive switching over enums is a good important feature that 
> risks going away (the default matters) for not a huge effective benefit to 
> app developers.
> ___
> 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 0192 - Non-Exhaustive Enums

[Goffredo Marocchi via swift-evolution]

> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution 
>  wrote:
> 
> Furthermore, the old code needs to continue working without source changes, 
> because updating to a new SDK must not break existing code. (It can introduce 
> new warnings, but even that is something that should be considered carefully.)
> 
> So: this proposal is designed to handle the use cases both for Swift library 
> authors to come and for C APIs today, and in particular Apple's Objective-C 
> SDKs and how they've evolved historically.

I will let your very comprehensive rationale brew a little bit more in my mind 
and reread it, but I still think this is a bit leaning too much over to library 
authors than library consumers (not unlike the closed by default discussion we 
all had a while ago).

I remain very unconvinced by the “updating library/SDK” must be source 
compatible. Especially if it is major version change and a deprecated method 
has been removed, methods have changed signature, etc... Backward compatible 
runtime with code compiled against the previous SDK yes, source compatible no.

I feel like this change will make the life easier for library authors, but 
risks making it easier and easier to make mistakes in apps using the libraries: 
exhaustive switching over enums is a good important feature that risks going 
away (the default matters) for not a huge effective benefit to app developers.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 Jan 2018, at 07:42, Goffredo Marocchi  wrote:
> 
> 
>> On 3 Jan 2018, at 02:07, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> [Proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md]
>> 
>> Whew! Thanks for your feedback, everyone. On the lighter side of 
>> feedback—naming things—it seems that most people seem to like '@frozen', and 
>> that does in fact have the connotations we want it to have. I like it too.
>> 
>> More seriously, this discussion has convinced me that it's worth including 
>> what the proposal discusses as a 'future' case. The key point that swayed me 
>> is that this can produce a warning when the switch is missing a case rather 
>> than an error, which both provides the necessary compiler feedback to update 
>> your code and allows your dependencies to continue compiling when you update 
>> to a newer SDK. I know people on both sides won't be 100% satisfied with 
>> this, but does it seem like a reasonable compromise?
> 
> If we can optionally treat this warning as an error yeah, but considering the 
> restricted use case, the default should still be exhaustive with unfrozen the 
> optional keyword that can be applied to opt out of the error.
> 
> Regardless of that, if it is not going to cause runtime issues why should it 
> not be a compile time error and just a warning? I think if you recompile the 
> app and are either targeting a new SDK or updating a library you bundle that 
> you should have to address this issue. Still, better than nothing :).
> 
>> 
>> The next question is how to spell it. I'm leaning towards `unexpected 
>> case:`, which (a) is backwards-compatible, and (b) also handles "private 
>> cases", either the fake kind that you can do in C (as described in the 
>> proposal), or some real feature we might add to Swift some day. `unknown 
>> case:` isn't bad either.
>> 
>> I too would like to just do `unknown:` or `unexpected:` but that's 
>> technically a source-breaking change:
>> 
>> switch foo {
>> case bar:
>>   unknown:
>>   while baz() {
>> while garply() {
>>   if quux() {
>> break unknown
>>   }
>> }
>>   }
>> }
>> 
>> Another downside of the `unexpected case:` spelling is that it doesn't work 
>> as part of a larger pattern. I don't have a good answer for that one, but 
>> perhaps it's acceptable for now.
>> 
>> I'll write up a revision of the proposal soon and make sure the core team 
>> gets my recommendation when they discuss the results of the review.
>> 
>> ---
>> 
>> I'll respond to a few of the more intricate discussions tomorrow, including 
>> the syntax of putting a new declaration inside the enum rather than outside. 
>> Thank you again, everyone, and happy new year!
>> 
>> Jordan
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

This is not what I am saying.

Change X helps use case A, but unnecessarily removes feature important (and 
like argument labels for everything quite Swift defining, but alas...) for use 
case B.

What I am saying is that before merging change X we should figure out what is 
needed (change Y) to ensure that use case B is not harmed while we do also help 
use case A.

Use case A being binary frameworks shipped by the OS and use case B being 
everything else... :).

Change X being the current proposal.

Change Y being the feature(s) needed to be added to X to ensure X’ helps use 
case A without removing the functionality use case B relies on.

Sent from my iPhone

> On 3 Jan 2018, at 02:01, Xiaodi Wu  wrote:
> 
>> On Tue, Jan 2, 2018 at 7:02 PM, Goffredo Marocchi  wrote:
>> 
>>> On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull  wrote:
 I think there are a couple of different definitions running around, and 
 that is confusing things.
 
 In my mind, ‘unexpected:’ catches only cases which were unknown at compile 
 time. Adding cases to an enum *should* be a source-breaking change. That 
 is the whole point of this.  We should have to update the switch (either 
 by handling new case explicitly, or by adding default) before successfully 
 compiling.  What ‘unexpected:’ protects against are changes to a linked 
 binary (e.g. iOS) that are now vending cases we didn’t know about when we 
 were compiled.
 
 I’ll say it again… framing this idea as one of exhaustiveness is really 
 confusing.  Enums should just always be exhaustive in swift.  There may be 
 cases where we need to use ‘unexpected:’ to handle unexpected/future cases 
 exhaustively.  If we annotate an enum as @frozen, then we won’t need to do 
 that to be exhaustive because we know it won’t change out from under us.  
 Always exhaustive. Much less confusing…
 
 Thanks,
 Jon
>>> 
>>> I think, then, you fundamentally disagree with the starting premise of the 
>>> proposal, which is specifically the addition of nonexhaustive enums to the 
>>> language, and making them the default sort of enum so that adding cases *is 
>>> not* a source-breaking change. If your whole purpose is to change the 
>>> proposal so that adding cases will _always_ be a source-breaking change and 
>>> enums are _never_ nonexhaustive, then I'm not sure how to proceed in the 
>>> discussion as we're working towards diametrically opposite goals.
>> 
>> The main issue is a resilience issue and it mainly affects binary frameworks 
>> the app links with at runtime and does not package them (read mostly Apple 
>> ones for the moment)... the fact that enum changes are source breaking is 
>> the whole entire point of swift’s enum and a best practice warning to always 
>> have turned on even before with Objective-C. Our goal, and yours goal should 
>> be the one and the same too IMHO, is not to throw the proverbial baby out 
>> with the bath water.
>> 
>> We should look for a solution that allows what Apple and OS framework 
>> authors need and also what is best for app developers and if we need 
>> something to do this we pause this proposal until that something is ready 
>> and merged.
>> 
> 
> Hmm, I think indeed we disagree fundamentally on what this proposal is about, 
> or the desired end goal.
> 
> If I understand correctly, *your* end goal is simply to enable something like 
> `@_fixed_layout` for enums, an optimization hint to allow binary frameworks 
> to add cases without being shipped with apps. You want no semantic changes to 
> how enums work.
> 
> *My* understand of this proposals goal--and I support it--is that it takes 
> this ABI compatibility problem as a starting point and discovers that there 
> are fundamentally two semantic categories of enums, ones that are necessarily 
> exhaustive (there's either something or nothing for an Optional value, there 
> are three possible comparison results for comparable types, there are four 
> sides to a rectangular window, etc.) and ones that are not. It discovers 
> that, empirically, most enums are nonexhaustive, and proposes changes to the 
> grammar so that Swift distinguishes between these two so as to prompt 
> developers to deal with the issue of nonexhaustiveness where the semantics 
> require it. The goal, then, is to introduce new spellings and semantics to 
> distinguish between two different flavors of enum. Like `open` vs. `public` 
> for classes, this has implications for ABI compatibility but isn't just about 
> ABI compatibility.
> 
> I was laboring under the idea that we were working to make such a 
> wide-ranging change as ergonomic as possible, but it seems like you and Jon 
> do not want such a change at all.
> 
>>> 
> On Jan 2, 2018, at 1:41 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger  
>>

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

[Goffredo Marocchi via swift-evolution]

> On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull  wrote:
>> I think there are a couple of different definitions running around, and that 
>> is confusing things.
>> 
>> In my mind, ‘unexpected:’ catches only cases which were unknown at compile 
>> time. Adding cases to an enum *should* be a source-breaking change. That is 
>> the whole point of this.  We should have to update the switch (either by 
>> handling new case explicitly, or by adding default) before successfully 
>> compiling.  What ‘unexpected:’ protects against are changes to a linked 
>> binary (e.g. iOS) that are now vending cases we didn’t know about when we 
>> were compiled.
>> 
>> I’ll say it again… framing this idea as one of exhaustiveness is really 
>> confusing.  Enums should just always be exhaustive in swift.  There may be 
>> cases where we need to use ‘unexpected:’ to handle unexpected/future cases 
>> exhaustively.  If we annotate an enum as @frozen, then we won’t need to do 
>> that to be exhaustive because we know it won’t change out from under us.  
>> Always exhaustive. Much less confusing…
>> 
>> Thanks,
>> Jon
> 
> I think, then, you fundamentally disagree with the starting premise of the 
> proposal, which is specifically the addition of nonexhaustive enums to the 
> language, and making them the default sort of enum so that adding cases *is 
> not* a source-breaking change. If your whole purpose is to change the 
> proposal so that adding cases will _always_ be a source-breaking change and 
> enums are _never_ nonexhaustive, then I'm not sure how to proceed in the 
> discussion as we're working towards diametrically opposite goals.

The main issue is a resilience issue and it mainly affects binary frameworks 
the app links with at runtime and does not package them (read mostly Apple ones 
for the moment)... the fact that enum changes are source breaking is the whole 
entire point of swift’s enum and a best practice warning to always have turned 
on even before with Objective-C. Our goal, and yours goal should be the one and 
the same too IMHO, is not to throw the proverbial baby out with the bath water.

We should look for a solution that allows what Apple and OS framework authors 
need and also what is best for app developers and if we need something to do 
this we pause this proposal until that something is ready and merged.

> 
>>> On Jan 2, 2018, at 1:41 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger  
 wrote:
 [...]
 
>>> in what other circumstances do we insist that the compiler inform the 
>>> end user about future additions to the API at compile time?
>> 
>> This isn’t a request for the compiler to inform the user about future 
>> additions to an API.  It is a request to validate the compiler’s 
>> knowledge of the current state of an API with the current state of the 
>> source code. 
> 
> Well, it's of course impossible to inform the user about future 
> additions, so that's poorly phrased on my part. It's about the compiler 
> informing the end user about *new* additions, part of the *current* state 
> of the API, that have cropped up since the user last revised the code 
> when the API was in a *previous* state (or, indistinguishably, members of 
> which a user is unaware regardless of the temporal sequence of when such 
> members were added). In what other circumstances do we insist that the 
> compiler perform this service?
 
 Enums. That's literally how they work today. You are arguing in favor of 
 actively removing compiler-aided correctness.
 
 There's also protocol requirements
>>> 
>>> No, that's now how enums work today, and it's not how protocol requirements 
>>> work today. Enums today are all semantically exhaustive; if a case is added 
>>> in a later version of a library, it's semantically a *different* enum type 
>>> that happens to share the same name. Not considering all the cases of an 
>>> exhaustive enum is an _error_, not a _warning_, because there is no basis 
>>> on which to proceed. This will not change with the proposal. Likewise, 
>>> adding a protocol requirement without a default implementation is 
>>> source-breaking. The result is a compiler _error_.
>>> 
>>> The question is, what non-source breaking API additions today cause the 
>>> compiler to inform the end user of such additions? The answer is: none 
>>> whatsoever. Not new methods or properties on a type, not even new protocol 
>>> requirements that have a default implementation.
>>> 
>>> 
 and, arguably, deprecated methods with a proper message ("use foo 
 instead").
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _

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

[Goffredo Marocchi via swift-evolution]

Hello all,

> On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution 
>>  wrote:
>> I think this whole thing has been unnecessarily convoluted. As a result, the 
>> majority of the replies are rabbit holes.
>> 
>> In my opinion, the true root of the concept in question is as follows:
>> 
>> A list of something is desired:
>> 1 - Pancake
>> 2 - Waffle
>> 3 - Juice
>> 
>> Developer wishes to be able to:
>> A) Add new things to the list of choices in the future as they come up with 
>> new ideas
>> B) Sometimes select one of the choices to be chosen as the normal choice if 
>> no choice is made by the user
>> 
>> A and B are separate desires. In some circumstances a developer may want to 
>> add a new choice and make it the normal choice when there was no normal 
>> choice was clarified before.
> 
> I don't think this is an accurate summary of the problem being tackled here. 
> Rather, we are how to enable the vendor of a nonexhaustive enum to add new 
> cases without breaking binaries compiled against previous versions. There is 
> little here to do with what a "default" should be. Indeed, it is an explicit 
> design decision of Swift not to support types having an implicit default 
> value.

There is no way a library developer of libraries bundled in the app can break 
the app by adding new cases. They may cause compiler issues when the app author 
tries to update the library, but it will not break existing apps.

The concern for updating enums is mostly an Apple / OS related concern for 
libraries/dynamic frameworks the app does not ship with, but links to at 
runtime and we should have an exception for that. We should not use the same 
solution for both and lose exhaustiveness checks when we do not need to. It 
would be wrong.

Those dynamic frameworks should be the one that have to opt-in (even better if 
it is done automatically for them) in non-exhaustive extra resilient behaviour, 
not libraries you ship in the app. 

The app developer should be informed and have to address the new cases or the 
removal of old cases.

>  
>> 
>> 
>> Part 2:
>> 
>> After this simple desire is clear, there should be two discussions:
>> A) In a text only coding language, what would we like the syntax to look 
>> like? (Without regard to past-bias. What should it really be, forget what 
>> mistaken design choices were made in Swift in the past)
>> B) How do we approach making this happen behind the scenes?
>> 
>> Bonus: Given that some of us have changed our approach to programming 
>> significantly beyond text based coding, and into more dynamic mediums of 
>> programming in other niches, and even here and there in Xcode - I would 
>> recommend considering how the IDE would show a modern version of this 
>> concept. I feel too often that Swift design syntax has a lack of awareness 
>> between the distinctions of what the IDE should do, as opposed to what the 
>> syntax of the language should be, and what should be handled behind the 
>> scenes by automated tooling.
>> 
>> _
>> 
>> My opinion, in answering the above questions is in preference to a simple 
>> easy to read and write syntax, something like the following:
>> 
>> choices Breakfast {
>> Pancake, Waffle, Juice
>> }
>> 
>> If a "default" choice is desired, it is obvious to me that I would select 
>> the choice from the IDE, and it would be visually indicated that it was the 
>> default.
>> 
>> When changes occur, whether new choices are added, old ones are removed or 
>> changed, or a default is added, changed, or removed - a behind the scenes 
>> automated tool analyzes the changes and presents migration options through 
>> the IDE.
>> 
>> _
>> 
>> Sincerely,
>> Jason
>> 
>>> 
>> 
>> 
>> ___
>> 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] Happy new year Swift community.

[Goffredo Marocchi via swift-evolution]

Happy new year everybody :)!

Sent from my iPhone

> On 31 Dec 2017, at 23:43, David Hart via swift-evolution 
>  wrote:
> 
> Thank you very much and happy new Swift year to everybody.
> 
>> On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>> Well some of you guys have to wait a little longer, but I can already wish 
>> everyone a happy new year from Germany. 🎉🎊🎆🎇 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

+1 kind of eye opening looking at it from that angle :/.

Sent from my iPhone

> On 21 Dec 2017, at 18:02, Dave DeLong via swift-evolution 
>  wrote:
> 
> I realized further why we should not implement this proposal: It forces the 
> problem of binary compatibility on the app developer, when experience has 
> shown us that problem is better handled by the libraries.
> 
> Binary Compatibility
> 
> “Binary compatibility” is the notion that, even if the libraries you link 
> against change, your app will still behave as it did when it was first 
> compiled. For Swift apps these days, we don’t really have this problem, 
> *yet*. We do have the problem of “binary compatibility” with Apple-provided 
> frameworks, but those are all written in Objective-C, and so the question of 
> “Swift” binary compatibility is still up-in-the-air.
> 
> Post-ABI stability, we still won’t have much issue with swift binary 
> compatibility on Apple platforms, because there isn’t a mechanism to ship a 
> framework to your users independently of an app update. So from the app POV, 
> none of this will be a problem for Apple platform developers.
> 
> It will be a problem for non-Apple platform developers. As a simple example, 
> let’s say I write a web app in Swift, and deploy it to a server that has some 
> built-in Swift-on-the-server libraries. Here, my Swift app is decoupled from 
> the libraries, and either one can update independently of each other. If the 
> server owner decides to update from Swift 6 to Swift 6.1, that’s cool. But my 
> web app should continue to run and behave *as if* the server were still 
> running Swift 6, because it has not been re-compiled to use Swift 6.1 
> features.
> 
> This is the situation today on Apple platforms. Every app deployed to an 
> Apple device includes a little piece of information in the executable file 
> indicating which SDK was used to compile the app. At runtime, the system 
> frameworks read this value and then alter their behavior accordingly. This is 
> why apps written against the iOS 9 SDK continue to work on iOS 11 devices; 
> UIKit and friends are altering their behavior to provide iOS 9 semantics. 
> 
> This is “binary compatibility”: the binary (your app) continues to be 
> compatible with the dynamically linked frameworks present on the system, even 
> though those frameworks may change.
> 
> When you have a setup where the frameworks do NOT provide binary 
> compatibility, you end up in DLL Hell [1]. This is the same frustrating 
> scenario when you’re in when you’re doing stuff with homebrew and find that 
> this package you want has multiple dependencies, but these dependencies want 
> different versions of the same library. [2]
> 
> Exhaustive Enums
> 
> All of the discussion around exhaustive enums has been from the point-of-view 
> of “what should the behavior be when the libraries change”. Thinking back, 
> I’m actually surprised this is a question at all, because Apple answered this 
> *years* ago: THE BEHAVIOR SHOULD REMAIN UNCHANGED. It is up to the library 
> authors to ensure that they’re doing what the compiled-and-unchanging 
> application is expecting them to do.
> 
> This discussion around exhaustive enums is basically saying “can we force the 
> developers to deal with binary incompatibility?”. We absolutely should not. 
> There are far more app developers than library developers, and it would be a 
> massively wasteful expenditure of engineering effort to force each and every 
> app developer to deal with binary incompatibility, when the library can do it 
> for them. That is the entire *purpose* of having libraries: abstract out a 
> problem so that I, as an app developer, don’t have to spend the effort to do 
> it myself.
> 
> Where We Should Go
> 
> Instead of forcing developers to deal with incompatible libraries, we should 
> be discussing ways to make binary compatibility easier to implement in 
> libraries.
> 
> One of the major problems I struggled with as a UIKit engineer was the 
> presence of huge numbers of “if … else” checks in the code to deal with 
> binary compatibility. It exploded the cyclomatic complexity of the classes 
> and was a major source of technical debt that I struggled to not add to.
> 
> I would love to see some sort of formal API versioning that we could do 
> instead in libraries, along with easy runtime support for checking the linked 
> version of libraries, making it easy to strategize implementations based on 
> version, etc.
> 
> But forcing developers to deal with binary incompatibility is a solution 
> we’ve long known to be a bad one. We should not perpetuate that sin in Swift.
> 
> Dave
> 
> [1]: https://en.wikipedia.org/wiki/DLL_Hell
> [2]: https://en.wikipedia.org/wiki/Dependency_hell
> 
> 
>> On Dec 20, 2017, at 10:23 AM, Dave DeLong via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution 
>>>  wrote:
>>> 
>>> The review of "SE 0192 - Non-Exhaustive Enums"

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

[Goffredo Marocchi via swift-evolution]

+1 thanks for your response Chris, it seems to me that it addresses the need 
this PR is trying to address and it does make it so in a scalable way. I would 
strongly hope your feedback is added to the proposal and shapes the final 
solution.

Sent from my iPhone

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

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

[Goffredo Marocchi via swift-evolution]

> I am part of the people mentioned in "Preserve exhaustiveness diagnostics for 
> non-exhaustive enums" : I see the completeness check as a major feature of 
> enums, that makes a difference between it and a list of constants in multiple 
> cases.
> So much that in the coding rules of the company I work for, the use of 
> default case requires some specific justification at review time.

Standing ovation :), one of my most loved warnings in -Weverything was ensuring 
switches were exhaustive. 

I quite disagree with being unnecessarily strict with making classes closed by 
default and è una non exhaustive by default and potentially tons of unchecked 
changes ended up in the default case with the “hey, we can force it to be 
exhaustive in the unit tests”. I particularly dislike that line of reasoning in 
a language about strong static typing as “well, write unit tests to get your 
correctness and safety tests” is the JavaScript mantra (of those that see 
TypeScript as pure evil).


> I have a positive opinion on this evolution if it comes with a solution to 
> preserve exhaustiveness diagnostics. Otherwise, I think it lowers the ease of 
> maintenance of code using external libraries.
> 
> One of the risk I fear is that libraries builders might just forget to add 
> the @exhaustive keyword. So it might end up being a pretty common case to 
> have to specify "I want this switch to be exhaustive", just to not loose on 
> maintainability. This could lead to a situation similar to the "fileprivate", 
> that ended up being used much more than expected.
> 
> It is not exactly in the scope of that review, but in the two solution for 
> enforcing exhaustiveness drafted in that proposal, I would rather avoid the 
> second one (the switch!). It would contradict the fact that as of today, the 
> use of the exclamation mark in swift is a pretty clear sign that you are 
> disabling some compiler-provided security at your own risk, and that it might 
> lead to runtime crash (force unwrap, force cast, ...).
> Here, requesting a switch to be exhaustive is adding one more compiler check. 
> It cannot lead to a runtime crash.
> I will be happy to discuss it further in a future review.
> 
> Jerome
> ___
> 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] Add transformers to Codable

[Goffredo Marocchi via swift-evolution]

+1 this is missing functionality at the moment and what still puts tools like 
Mantle ahead.

Sent from my iPhone

> On 19 Dec 2017, at 04:18, Charlie Monroe via swift-evolution 
>  wrote:
> 
> For me definitely +1 as it's getting near to what I need to call the Decoding 
> usable.
> 
>> On Dec 18, 2017, at 5:51 PM, Arsen Gasparyan via swift-evolution 
>>  wrote:
>> 
>> Hello everyone,
>> 
>> I’m suggesting to add a new way to encode/decode JSON properties for 
>> relevantly complex data formats such as regular expressions, well-known 
>> text, hex colours, custom date formats.
>> 
>> The problem:
>> 
>> Image you have a struct called House
>> 
>> struct House {
>> let color: UIColor
>> }
>> 
>> and it has a properly called color and the color represented in JSON as hex 
>> value (#ff). Currently to make it working you have to extract the 
>> underline value (string with a hex value) and then try to make a UIColor 
>> from it. It works but it makes you to copy/past a lot of code and it leads 
>> to problems. Also it shifts focus from what to decode to how to decode.
>> 
>> The suggested solution:
>> 
>> I suggest that we have to introduce protocols for classes that will 
>> encapsulate transformation from a source data type to a destination data 
>> type. The source data types are all existing data that support of decoding. 
>> 
>> We will provide only protocols (one for decoding and one for encoding) and 
>> users will be able to create transformers for their own data types.
>> 
>> The implementation:
>> 
>> The implementation is fairly easy. We only need introduce two protocols 
>> (encoding/decoding) and add a method to KeyedEncodingContainerProtocol that 
>> will accept a key and a transformer. In the method we will extract source 
>> data from JSON and then will ask the transformer to try to convert it to the 
>> desire data type.
>> 
>> Example of the decoding protocol:
>> 
>> protocol DecodingTransformer {
>> associatedtype Input: Decodable
>> associatedtype Output
>> func transform(_ decoded: Input) throws -> Output
>> }
>> 
>> 
>> Inspired by: https://github.com/Hearst-DD/ObjectMapper#custom-transforms
>> 
>> Cheers,
>> Arsen
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Goffredo Marocchi via swift-evolution]

Well, mocking was effective and super easy to do proper unit testing with... 
that must count as a disaster or something ;).

Sent from my iPhone

> On 7 Dec 2017, at 15:32, C. Keith Ray via swift-evolution 
>  wrote:
> 
> Let's see what disasters were created by people abusing NSProxy, the ObjC 
> moral equivalent of a dynamic member lookup type.
> 
> I'm not aware of anything.
> 
> --
> C. Keith Ray
> 
> * https://leanpub.com/wepntk <- buy my book?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
> * http://agilesolutionspace.blogspot.com/
> 
>> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
>>> 
>>> 
 On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
  wrote:
 
> This seems marginally tolerable, but excessive.
> 
> Do we mark every usage of a type that can generate precondition failures 
> or fatal errors for reasons other than “no such method?” No, we don’t.
> 
 
 fatalError shouldn’t be used excessively. API surface areas for these 
 types are going to be massive (infinite technically). I assume many people 
 are going to be writing a lot of code would these types and calling many 
 methods and properties which would all essentially have a fatalError. 
 Would you consider it good code if the majority of all your types had 
 methods defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard library 
>>> methods check preconditions and trap on failure. That is how I write my 
>>> code as well.
 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError is 
>> something that goes out with production code while precondition is used for 
>> debugging. I think you would agree a shipped program that has many states of 
>> being unrecoverable is not a good design?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] proposal 0143-conditional-conformances

[Goffredo Marocchi via swift-evolution]

In many software projects in the real world the tests would have been gone not 
the code... *weeps as that is so true :/“...

Sent from my iPhone

On 20 Nov 2017, at 08:16, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Nov 19, 2017, at 4:11 PM, Matt Whiteside via swift-evolution 
>>  wrote:
>> 
>> Bosses at Apple: if you are reading this, please allow the swift compiler 
>> team the bandwidth to work on this.  Thanks.
> 
> They are. If you take a look at recent pull requests at 
> , you'll see all sorts 
> of conditional-conformance-related stuff is being worked on right now.
> 
> In fact, the first conditional conformances (making Array, Dictionary, and 
> Optional conform to Equatable) briefly landed a few days ago: 
>  Unfortunately, they had to be 
> backed out because they broke a couple tests, but that's software 
> development, right?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] proposal 0143-conditional-conformances

[Goffredo Marocchi via swift-evolution]

+1

Sent from my iPhone

> On 20 Nov 2017, at 00:11, Matt Whiteside via swift-evolution 
>  wrote:
> 
> Just wanted to upvote the conditional conformances proposal.
> 
> I was bummed to find out that I couldn’t do this:
> 
> extension Array:Drawable where Element == CGPoint{}
> 
> Bosses at Apple: if you are reading this, please allow the swift compiler 
> team the bandwidth to work on this.  Thanks.
> 
> -Matt
> ___
> 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] Introduce user-defined dynamically "callable" types

[Goffredo Marocchi via swift-evolution]

Very interesting indeed...

class VehicleUtilities {

int numberOfAxles(Vehicle v) { return 2;} // a plausible default

int numberOfAxles (Truck t){ return 3;}

}




Vehicle v = new Truck();

VehicleUtilities u = new VehicleUtilities();

u.numberOfAxles(v); // returns 2


--> this is a nice concise example of even simple code can suffer from a
nasty code issue such as this...

On Sat, Nov 11, 2017 at 4:32 PM, Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Le 11 nov. 2017 à 16:48, Joe Groff via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> That'd be great, but Swift violates Gilad Bracha's golden rule by having
> static overloading, and throws bidirectional type inference on top, so our
> static name resolution can't be treated as a specialization of a dynamic
> name lookup mechanism in all cases.
>
>
> I didn't know of Gilad Bracha, so you made me curious.
>
> I guess that the "golden rule" you refer to is here, for anyone curious:
> https://gbracha.blogspot.fr/2009/09/systemic-overload.html
>
> Gwendal Roué
>
>
> ___
> 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] Introduce user-defined dynamically "callable" types

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 10 Nov 2017, at 19:42, Joe Groff via swift-evolution 
>  wrote:
> 
> Through great pain and community anguish, we pushed ourselves to a model 
> where argument labels are parts of the declaration name, not part of the call 
> argument

Hey Joe, does this mean it is likely there is little to no chance to have 
argument labels for closures and stored functions back? Sorry to bring noise in 
here, but your words put a grim outlook on something the core team said it 
would be revisited last year in the next Swift iteration.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Abstract methods

[Goffredo Marocchi via swift-evolution]

I would say that you kind of already entered a slippery slope when the 
extension to a protocol can add code / not just declare a behavioural contract 
and how it changes OOP approach (hence: 
https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302  and 
https://bugs.swift.org/browse/SR-103  and  
https://bugs.swift.org/plugins/servlet/mobile#issue/SR-584)

References:
https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future 
https://www.raizlabs.com/dev/2016/12/swift-method-dispatch

Sent from my iPhone

> On 5 Nov 2017, at 01:08, Slava Pestov  wrote:
> 
> 
> 
>> On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Protocols define requirements, they don’t “add” things to the conforming 
>>> type
>> 
>> I agree with this, but then this warrants a change for protocol extensions 
>> too. Would you be happy with the restriction that default method 
>> implementations are only available for value types and not for classes (as 
>> structs cannot share code any other way, it is the argument for that I seem 
>> to recall)?
> 
> Protocol extensions are in some sense just syntax sugar for defining new 
> functions. Having a protocol conformance add storage to the conforming type 
> is fundamentally different.
> 
> Slava
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Abstract methods

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution 
>  wrote:
> 
> Protocols define requirements, they don’t “add” things to the conforming type

I agree with this, but then this warrants a change for protocol extensions too. 
Would you be happy with the restriction that default method implementations are 
only available for value types and not for classes (as structs cannot share 
code any other way, it is the argument for that I seem to recall)?


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

Re: [swift-evolution] Adding Result to the Standard Library

[Goffredo Marocchi via swift-evolution]

Key words: “if that is going to change” and I would add “even if it changes 
would all async use cases map to the new paradigm?”. I understand your 
concerns, but I am also wary of promised silver bullet solutions that promise 
or aim to take care of all use cases...

Sent from my iPhone

> On 2 Nov 2017, at 18:48, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
>> On Thu, Nov 2, 2017 at 11:32 AM Jon Shier  wrote:
>>  That’s been an argument against Result for 2 years now. The usefulness 
>> of the type, even outside of whatever asynchronous language support the core 
>> team comes up with, perhaps this year, perhaps next year, is still very 
>> high. Even as something that just wraps throwing functions, or otherwise 
>> exists as a local, synchronous value, it’s still very useful as way to 
>> encapsulate the value/error pattern.
> 
> This is one of the parts that concerns me, actually. The beauty of Swift's 
> error design is that function results denote expected/successful outcomes and 
> thrown errors denote unexpected/erroneous outcomes. Since they are different, 
> each is handled through its own language constructs, and since the language 
> itself supports it (rather than being entirely type-based), you don't have 
> the proliferation of unwrapping boilerplate that you have with Result<>.
> 
> In our own code bases, I actively discourage the use of Result<> in that way, 
> because it tries to cram both of those concepts into the expected/successful 
> outcomes slot in the language. For asynchronous APIs that's somewhat 
> unavoidable today, but if that's going to change, I'd rather the language 
> focus on a way that's consistent with other error handling already present in 
> Swift.
> 
> Adding an API to the standard library is the core team saying "this is 
> blessed as something around which we support APIs being designed." IMO, I'd 
> prefer it if the language did *not* bless two disparate ways of communicating 
> error outcomes but rather converged on one.
> 
> IMO, "things aren't happening fast enough" isn't great motivation for putting 
> something permanently into the standard library or the language without 
> considering the context of other things going on around it. If you're going 
> to propose something that overlaps with asynchronous APIs, it only helps your 
> case if you can discuss how it can integrate—rather than collide—with those 
> efforts.
> 
> 
>  
>> That pattern will likely never go away. Additionally, having the Result type 
>> in the standard library removes a source of conflict between all other 
>> Result implementations, which are becoming more common.
>> 
>> 
>>> On Nov 2, 2017, at 2:26 PM, Tony Allevato  wrote:
>>> 
>>> Given that the Swift team is currently working on laying the groundwork for 
>>> asynchronous APIs using an async/await model, which would presumably tie 
>>> the throwing cases more naturally into the language than what is possible 
>>> using completion-closures today, are we sure that this wouldn't duplicate 
>>> any efforts there or be made obsolete through other means?
>>> 
>>> In other words, while Result<> can be a very useful foundational component 
>>> on its own, I think any proposal for it can't be made in isolation, but 
>>> very much needs to consider other asynchronous work going on in the 
>>> language.
>>> 
>>> 
 On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution 
  wrote:
 You don’t lose it, it’s just behind `Error`. You can cast out whatever 
 strong error type you need without having to bind an entire type to it 
 generically. If getting a common error type out happens a lot, I usually 
 add a convenience property to `Error` to do the cast for me. Plus, having 
 to expose an entire new error wrapper is just a non starter for me and 
 doesn’t seem necessary, given how Result is currently used in the 
 community.
 
 
 Jon
 
 
> On Nov 2, 2017, at 2:12 PM, Dave DeLong  wrote:
> 
> I think I’d personally rather see this done with a generic error as well, 
> like:
> 
> enum GenericResult {
>   case success(T)
>   case failure(E)
> }
> 
> And a typealias:
> 
> typealias Result = GenericResult
> 
> This would require an “AnyError” type to type-erase a specific Error, but 
> I’ve come across many situations where a strongly-typed error is 
> incredibly useful, and I’d be reluctant to see that thrown away.
> 
> Dave
> 
>> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution 
>>  wrote:
>> 
>> Swift-Evolution:
>>  I’ve written a first draft of a proposal to add Result to the 
>> standard library by directly porting the Result type used in 
>> Alamofire to the standard library. I’d be happy to implement it (type 
>> and tests for free!) if someone could point me to the right place to do 
>> so. I’m not including it directly in this email, since it 

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Goffredo Marocchi via swift-evolution]

I like the IB use case :).

Sent from my iPhone

> On 31 Oct 2017, at 03:22, Adam Kemp via swift-evolution 
>  wrote:
> 
> This I actually support. In C# the same concept exists in the form of partial 
> classes. A class must be declared as partial everywhere in order to support 
> it. It only works within a single assembly (similar to a module).
> 
> There are a few important use cases for this in C#:
> 
> 1. Code generation. For instance, Interface Builder could modify a separate 
> file for things like outlets and actions, and it could freely wipe and 
> regenerate that file from scratch without touching any of your own code. Some 
> people also generate parts of classes from templates while filling in the 
> rest in another file. 
> 
> 2. Cross platform code. A common strategy in C# is to have a class split into 
> parts, where one part is compiled on all platforms, and the other files are 
> each specific to one platform or another. For instance, you may have 
> Foo.swift, Foo.macOS.swift, and Foo.iOS.swift. Foo.swift would be compiled on 
> both platforms, but then the iOS build would only include Foo.iOS.swift. This 
> is a preferred alternative to using #ifs.
> 
> 3. The use case Mike described. Sometimes we fail at making classes small, or 
> maybe someone else failed and we’re stuck with it. Splitting a single class 
> into pieces can be useful to organize cohesive chunks. That’s not something I 
> tend to encourage as a design pattern, but it still happens anyway. 
> 
> A related feature in C# is partial methods, which are just void-returning 
> methods that have been declared as partial without an implementation. If an 
> implementation is provided by another file (in another part of the partial 
> class) then it is used. If no file provides an implementation then calls to 
> that method are just stripped out by the compiler. This is also commonly used 
> for cross-platform code. Maybe one platform needs to do something at a 
> particular time but another doesn’t. Rather than using #ifs or having empty 
> stubs in other platforms you can declare it partial and provide an 
> implementation on just the one platform that needs it.
> 
>> On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution 
>>  wrote:
>> 
>> a general feeling that there are two very different use cases of extensions 
>> -- one to extend own classes and another to extend other people classes; a 
>> lengthy discussion in a nearby thread; a disparity of features of class and 
>> it's extensions and different access right treatment depending upon whether 
>> the extension is in the same with the main class or a different file lead me 
>> to the following idea. hopefully you will find this idea useful and we may 
>> even see it one day in swift.
>> 
>> introducing class / struct / enum continuations.
>> 
>> in a few words the are:
>> 
>> 1) "extensions on steroids". in fact very similar to Objective-C "class 
>> extensions" but can be more than one and in more than one file.
>> 
>> 2) as good as the classes they continue (or other continuations they 
>> continue)
>> 
>> 3) can declare variables
>> 
>> 4) have full access to "private" members of the class or other continuations
>> regardless whether they are in the same or in a different files. no need for 
>> "public/internal/module" fallbacks to pass though files boundaries. 
>> similarly the class itself can use private members of its continuations.
>> 
>> 5) "by invitation only" system. can only be written if declared by the class 
>> or some continuation of it.
>> 
>> 6) A particular continuation only defined once (of course). There can be an 
>> arbitrary number of different continuations to a class similar to extensions.
>> 
>> 7) alternative name considered: "extending" (as a noun). shall definitely be 
>> a different name than say, "extension" with some bracket-syntax variation - 
>> the two use cases are very different and shall be named differently.
>> 
>> 8) the particular syntax is preliminary of course. 
>> 
>> example:
>> 
>> = Some.swift ==
>> 
>> class Some {
>> 
>>private func private_method_of_class() {
>> 
>>// *** can use private methods of continuations even if they are in a 
>> different file
>>private_method_defined_in_a_continuation()
>>}
>> 
>>// *** "by invitation" system
>> 
>>continuation Feature// *** declaring a continuation
>>continuation SomethingElse// *** Capitalized names, like classes
>> }
>> 
>> = Some-Feature.swift ==
>> 
>> // *** similar naming convetion to "Some+Feature.swift"
>> // used for extensions, just with "-" instead
>> 
>> // *** this is merely a naming convention, no need to
>> necessarily follow it, can put more than one thing into
>> a file, the continuation can reside in the same file as
>> the main class fie, etc.
>> 
>> continuation Feature of Some {
>> 
>> // *** as good as class itself. first-class citizen
>> // *** same

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

[Goffredo Marocchi via swift-evolution]

Very well said, I kind of think that at this point in time you do much more for 
the language by investing into SPM properly than Actors/Coroutines if you had 
to choose.

Sent from my iPhone

> On 28 Oct 2017, at 14:26, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 23. Oct 2017, at 19:41, Jean-Christophe Pastant via swift-evolution 
>>  wrote:
>> 
>> Hi,
>> 
>> Is there any news about features that are willling to be integrated into SPM 
>> 5?
>> Those I see the most relevant:
>> - iOS support
>> - Some kind of configuration/settings support (debug, release, ...)
>> 
>> I'd like to hear about it from maintainers, especially if there's a priority 
>> order we should follow.
>> 
>> Regards,
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> Yup. My opinions here: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039885.html.
>  Basically, I think we need support for 1) resources (or ‘assets’) and 2) 
> cross-platform modules.
> 
> I think that a better package-manager would really accelerate the Swift 
> ecosystem. We’ve had lots of people complaining about the lack of quality 
> libraries (e.g. for maths and stats) during the Swift 3/4 phases. Personally, 
> I still think it’s too much effort to integrate 3rd-party library projects in 
> to my existing projects and to contribute to them, which is why I usually 
> don’t.
> 
> As for Xcode integration: Obviously only Apple can comment on the Xcode 
> roadmap - but I will point out that, like the rest of Swift and LLVM, the 
> package manager is open-source and designed with a library architecture. That 
> means that any IDE could integrate support for SwiftPM, not just Xcode. As 
> users, we can say what we’d like Apple to do with Xcode, but it’s all 
> academic - since SwiftPM doesn’t support bundled assets, it can’t support 
> graphical applications. Bundled assets aren’t just an issue for GUI 
> applications, though - localisation tables, prepared databases and test 
> resources are useful for any kind of package.
> 
> So, for me the issue with assets is that some platforms have unique compiled 
> formats (e.g. Apple’s asset catalogues) which support asset variants for 
> localisations and display resolution. Obviously I want my output App to 
> support all of these features. In fact, most modern platforms have support 
> for some kind of asset variants — Apple calls it a TraitCollection, Android 
> calls it a Context — so do we want to support this concept natively somehow 
> in SwiftPM?
> 
> I mean, let’s say I have this awesome cross-platform Swift 
> application/library, and I’ve listed some files in my Package.swift and I can 
> find them again at runtime on any platform - all cool. Now, I want to 
> localise my package - what do I do? I’m going to have to create some 
> middleware to translate platform-specific concepts in to a baseline which I 
> can look-up based on some mangling I’m going to create for the file names. 
> Localisation is a problem on servers, too (particularly for error messages), 
> so some idea of asset variants could be something universal-enough to include 
> in the package manager.
> 
> - Karl
> ___
> 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] Property Getter Return Statement

[Goffredo Marocchi via swift-evolution]

Will this finally bring labels back everywhere (closures and stored
functions too)? :D.

On Thu, Oct 12, 2017 at 3:03 PM, Jeremy Pereira via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> >
> > I’m minorly opposed, because it feels like a slippery slope. What about
> function bodies? etc
> >
> > func foo() -> Int { 3 } // should this be allowed?
>
> Yes, why not? What is fundamentally different about a function body
> compared to a getter body (or a closure body ;-)) that means, if we accept
> it for getters, we should not also accept it for function bodies.
>
>
>
> ___
> 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

[Goffredo Marocchi via swift-evolution]

Agreed, I am not seeing this change doing so much good because maybe it could 
prevent issues Library writers or developers updating libraries without 
checking things... not trying to be rude and/or non empathetic, but exhaustive 
enums never struck me as a bad thing and the reasons why they could be bad very 
quickly leads one to think “maybe you should not have been switching on enums 
there...”.


Sent from my iPhone

> On 28 Sep 2017, at 23:57, Jon Shier via swift-evolution 
>  wrote:
> 
>   Actually, since proper dependency management for Apple platforms has 
> existed outside of Apple for years now, this likely wouldn’t affect me at 
> all, as long as the libraries I was using properly followed semantic 
> versioning. I could keep using the compatible version of the libraries for 
> however long I needed before moving to the new version and updating my code 
> to exhaustively check for the new values. So please don’t make this change 
> thinking you’ll be helping non-Apple framework providers here. Aside from 
> actual binary compatibility I’m not sure there’s a compatibility case to be 
> made here. 
> 
> 
> 
> Jon
> 
>> On Sep 28, 2017, at 4:52 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Sep 27, 2017, at 16:48, Jessie Serrino  wrote:
>>> 
>>> Hi there,
>>> 
>>> Just want to circle back on a few things.
>>> 
>>> You mentioned that library vendors communicate deprecation notices, but 
>>> this is very prone to error. If someone misses the notice that a library 
>>> puts out to communicate that the contracts of the enum have changed, this 
>>> could break existing functionality they have already built. 
>>> 
>>> You also mention that it's really hard for a library developer to predict 
>>> how their enum will change, but it's even harder for a library developer to 
>>> fully predict how a different user will use their library. As a developer, 
>>> I don't want to have to look at the release notes to find out when a 
>>> library has changed its contracts-- I want it to alert me in the most 
>>> aggressive way possible to make sure that major changes to the library have 
>>> been captured in my own code.
>> 
>> Hi, Jessie. This is a reasonable view, but in our experience it's not the 
>> most important thing. What we've seen is that people want their code to keep 
>> building after an update, and in particular they want their dependencies to 
>> keep building. That is, if your app depends on HomeworkKit, and HomeworkKit 
>> adds a new case, you probably want to know about it. But if someone's app 
>> depends on CoreAcademia, and CoreAcademia depends on HomeworkKit, they're 
>> probably just going to be upset if CoreAcademia no longer builds. In 
>> practice, that person/team stops updating HomeworkKit until there's a 
>> CoreAcademia update available, or possibly stops working on their app 
>> altogether, to avoid editing someone else's library.
>> 
>> (Again, this becomes even more critical if HomeworkKit is a part of the OS, 
>> in which case there's not even a choice whether or not to update. But I can 
>> see that being handled separately.)
>> 
>> I'm not completely against having an additional notion of an 
>> "otherwise-exhaustive" switch, as discussed under "Preserve exhaustiveness 
>> diagnostics for non-exhaustive enums". But that's a feature we can add 
>> later, whereas differentiating exhaustive and non-exhaustive enums is 
>> something that must be done before Swift libraries can be part of the OS.
>> 
>> Jordan
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Goffredo Marocchi via swift-evolution]

I am still unsure why we are choosing again a default that protects library 
writers more than library users where it is reasonable to expect the former to 
have better mastery of the language, to architect a library with some 
scalability, and ability to add unit test to cover themselves from issues than 
the latter.

Exhaustive and open by default with keywords to close things down if the 
framework author wants them.

Sent from my iPhone

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

Re: [swift-evolution] Enums and Source Compatibility

[Goffredo Marocchi via swift-evolution]

Sorry for being naive, but aside from open (and the decision not to make it the 
default which again hurts the users of the library),  wouldn’t the playground 
library example be ok if the framework author had validated it with unit tests?

Sent from my iPhone

> On 16 Sep 2017, at 01:07, Jordan Rose via swift-evolution 
>  wrote:
> 
> Hi, Rex. I definitely agree that 'exhaustive' is the right model for a 
> multi-module app; indeed, there's no real reason for a single project to do 
> anything else. However, it is not always the right behavior for libraries 
> that actually get distributed, whether as source or as binary. In this case 
> we want to minimize the error of omission: in the app case, forgetting 
> "exhaustive" is an annoyance that you notice and fix once across your code 
> base, but in the library case forgetting the "default case" means putting out 
> a source-breaking release, and for libraries that have binary compatibility 
> constraints there's no recourse at all.
> 
> While most of the proposal deals with the experience we've had with the Apple 
> SDKs (as written in Objective-C), we actually have run into this case in 
> Swift already. The Swift Playgrounds app comes with a framework, 
> PlaygroundSupport, that can be used from within a playground. It's important 
> that when they upgrade the app, existing playgrounds don't break, since the 
> end user may not have access to the entire code of the playground. (Remember 
> that playgrounds are often authored by one developer or group, but then run 
> and modified by someone else with a much lower skill level!) That means that 
> PlaygroundSupport can't currently vend any enums that they expect playground 
> authors to exhaustively switch over.
> 
> (And to make it even more specific—and appealing—one of the enums they were 
> considering would be a representation of the Swift AST. This can obviously 
> change from release to release, but previous switch statements should stay 
> valid.)
> 
> Now, this is an example we know about, so we could certainly make it 
> explicitly non-exhaustive. But in general we're in the same situation as 
> 'open': if we want to be friendly to library authors, we need to make the 
> default thing be the one that promises less, even if it means a bit of extra 
> work in the "I-actually-own-everything" case.
> 
> Best,
> Jordan
> 
> 
>> On Sep 15, 2017, at 15:47, Rex Fenley  wrote:
>> 
>> Hey Jordan,
>> 
>> Thank you for the time writing this up. I've been following along to the 
>> discussion somewhat closely and have kept silent because `exhaustive` was 
>> originally set to be the default for enums. However, that changed and so I'd 
>> like to voice my opinion, I frankly don't like this idea.
>> 
>> At remind we use algebraic data types religiously for managing state and 
>> data and rely on exhaustive pattern matching to guarantee we're handling all 
>> states in our code. We're splitting out our code across modules and having 
>> this guarantee has been a joy to work with.
>> 
>> The benefit of making nonexhaustive the default for Swift 5 across all 
>> multi-module code (besides C code) seems minimal to me. If a developer feels 
>> like they're unnecessarily managing enum cases, they can simply add a 
>> `default` case whenever they please. This is already the case and I'm 
>> curious if there's every been any complaints about this and what they would 
>> be. I'd prefer to be cautious and force exhaustive pattern matching in all 
>> possible cases and leave it up to the developer to choose not to.
>> 
>> Ideally in my mind, these keywords won't be necessary. All Swift enums will 
>> remain as they are, exhaustively pattern matched by default. Enums from C 
>> code will be explicitly nonexhaustive in all cases.
>> 
>> -- 
>> Rex Fenley  |  IOS DEVELOPER
>> 
>> 
>> Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Persistent Collections with full COW support

[Goffredo Marocchi via swift-evolution]

No sure if this is they will make stdlib, but ai am sure people would like to 
take a look at it :).

Sent from my iPhone

> On 1 Sep 2017, at 17:26, Sebastian Bohmann via swift-evolution 
>  wrote:
> 
> Is swift evolution interested in a set of persistent collections (vector, 
> hashset, hashmap) with full cow support and extensive tests?
> 
> They are finished and in use.
> 
> I would adapt them to the current style &.
> 
> Best regards
> 
> ___
> 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] New async keyword usage

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 26 Aug 2017, at 18:36, Adam Kemp via swift-evolution 
>  wrote:
> 
> C# had futures (in the form of the Task Parallel Library) before it had 
> async/await. If you could see how much async/await has revolutionized C# 
> programming you would not be making this argument. It is night and day. 
> Asynchronous code is so much clearer with this feature than without. You can 
> write code the is simpler and safer at the same time.
> 
> This isn’t an either/or proposition. We should have both, and they should 
> work together. 
> 

+1

> --
> Adam Kemp
> 
>> On Aug 25, 2017, at 10:08 PM, Howard Lovatt via swift-evolution 
>>  wrote:
>> 
>> I just don't see that async/await adds enough to warrant a language change. 
>> You can write Future on top of GCD and a future type can do more, like 
>> having a cancel, having a timeout, and giving control over what thread is 
>> used.
>> 
>>   -- Howard.
>> 
>>> On 26 August 2017 at 10:57, Florent Vilmart via swift-evolution 
>>>  wrote:
>>> Isn’t async / await an evolution over Promises / Tasks / Futures? AFAIK in 
>>> JS, any function that returns a promise can be ‘await’ upon, and 
>>> underneath, to be able to await, a function has to return a promise. 
>>> Marking a function async in JS, tells the consumer that some await are 
>>> going on inside, and it’s impossible to use await outside of an async 
>>> marked function. I believe swift is going that direction too. Futures / 
>>> Promises are the foundation on which async / await can truly express as it 
>>> formalizes the boxing of the result types.
>>> What would be interesting is async being based on a protocol FutureType for 
>>> example, so you can bring your own library and yet, leverage async / await
>>> 
 On Aug 25, 2017, 20:50 -0400, Jonathan Hull , wrote:
 
> On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise 
>  wrote:
> 
> =
>> Jonathan Hull jhull at gbis.com 
> 
>> This looks somewhat similar to a future, but you can’t interact with it 
>> as a separate type of object.  The value above is just a UIImage, but 
>> with a compiler flag/annotation that forces me to call await on it 
>> before it can be accessed/used.  The compiler has a lot more freedom to 
>> optimize/reorganize things behind the scenes, because it doesn’t 
>> necessarily need to make an intermediate object.
> 
> 
> As for the message of Wallacy I'd be interested the pros and cons of 
> hiding the implementation details ! :)
> 
> 
>> To prove (or potentially disprove) my assertion that this is not just 
>> sugar, how would you accomplish the following under the current proposal?
>> 
>> let a = async longCalculationA()
>> let b = async longCalculationB() //b doesn’t wait for a to complete 
>> before starting
>> let c = async longCalculationC() //c doesn’t wait for a or b
>> let result = await combineCalculations(a: a, b: b, c: c) //waits until 
>> a, b, and c are all available
> 
> 
> Would this be implemented differently than with Futures? I don't have 
> much experience with concurrency, but I don't see how this would be 
> handled differently than by using Futures, internally ? (at least for 
> this case)
> 
 
 It looks/behaves very similar to futures, but would potentially be 
 implemented differently.  The main difference is that the resulting type 
 is actually the desired type (instead of Future) with a compiler 
 flag saying that it needs to call await to be used.  Behind the scenes, 
 this could be implemented as some sort of future, but the compiler has a 
 lot more freedom to rearrange things to be much more efficient because 
 there is no affordance for the user to introspect or cancel. So for 
 example, it might actually change:
 
 let image = async downloadImage()
 let size = await image.size
 
 to:
 
 let size = await downloadImage().size
 
 This would depend on the other code around it, but the compiler has much 
 more freedom to avoid creating intermediate values, or even to create 
 different types of intermediate values which are more efficient for the 
 situation at hand.
 
 Given that as a base, it would be trivial to create a framework offering 
 true Futures (which allow cancelling, etc…)
 
 Thanks,
 Jon
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.sw

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

[Goffredo Marocchi via swift-evolution]

With both he now built in promises in Node8 as well as libraries like Bluebird 
there was ample time to evaluate them and convert/auto convert at times 
libraries that loved callback pyramids of doom when the flow grows complex into 
promise based chains. Converting to Promises seems magical for the simple case, 
but can quickly descend in hard to follow flows and hard to debug errors when 
you move to non trivial multi path scenarios. JS is now solving it with their 
implementation of async/await, but the point is that without the full picture 
any single solution would break horribly in real life scenarios.

Sent from my iPhone

> On 26 Aug 2017, at 06:27, Howard Lovatt via swift-evolution 
>  wrote:
> 
> My argument goes like this:
> 
>   1. You don't need async/await to write a powerful future type; you can use 
> the underlying threads just as well, i.e. future with async/await is no 
> better than future without. 
> 
>   2. Since future is more powerful, thread control, cancel, and timeout, 
> people should be encouraged to use this; instead because async/await are 
> language features they will be presumed, incorrectly, to be the best way, 
> consequently people will get into trouble with deadlocks because they don't 
> have control.
> 
>   3. async/await will require some engineering work and will at best make a 
> mild syntax improvement and at worst lead to deadlocks, therefore they just 
> don't carry their weight in terms of useful additions to Swift.
> 
> Therefore, save some engineering effort and just provide a future library.
> 
> To turn the question round another way, in two forms:
> 
>   1. What can async/wait do that a future can't?
> 
>   2. How will future be improved if async/await is added?
> 
> 
>   -- Howard.
> 
>> On 26 August 2017 at 02:23, Joe Groff  wrote:
>> 
>>> On Aug 25, 2017, at 12:34 AM, Howard Lovatt  wrote:
>>> 
>>>  In particular a future that is cancellable is more powerful that the 
>>> proposed async/await.
>> 
>> It's not more powerful; the features are to some degree disjoint. You can 
>> build a Future abstraction and then use async/await to sugar code that 
>> threads computation through futures. Getting back to Jakob's example, 
>> someone (maybe the Clang importer, maybe Apple's framework developers in an 
>> overlay) will still need to build infrastructure on top of IBActions and 
>> other currently ad-hoc signalling mechanisms to integrate them into a more 
>> expressive coordination framework.
>> 
>> -Joe
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Concurrency] Async/Await

[Goffredo Marocchi via swift-evolution]

Just to get it out of the way and to put the issue down... assuming we could 
get something like Promises and Futures, how much experience do people have 
with how async and await + Promises are changing the asynchronous by nature 
JavaScript? What in there really does not work and should one of the layer we 
provide be similar to it?

Sent from my iPhone

> On 22 Aug 2017, at 17:32, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Aug 21, 2017, at 10:21 PM, David Hart  wrote:
>> 
>> Sorry for the shameless bump :-/ but I’d love to get some answers so I can 
>> better understand the proposal and participate in the discussions.
>> 
>>> On 21 Aug 2017, at 07:58, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Thanks for the great work on the async/await proposal! After reading it, I 
>>> have a few questions and comments about it, so I’m creating this thread to 
>>> concentrate on that topic (instead of Actors).
>>> 
>>> Generators
>>> 
>>> The proposal mentions in Problem 6 of the Motivation how generators can 
>>> help write sequences:
>>> 
>>> In contrast, languages that have generators allow you to write something 
>>> more close to this:
>>> 
>>> func getSequence() -> AnySequence {
>>> let seq = sequence {
>>> for i in 1...10 {
>>> yield(i*i)
>>> }
>>> }
>>> return AnySequence(seq)
>>> }
>>> 
>>> This feels very similar to me from C# where the yield keyword is used to 
>>> support the generator feature. But I fail to see how the coroutines as 
>>> described in this proposal resolve this problem. Can someone explain?
> 
> The feature provides general delimited continuations. You could write an 
> IteratorProtocol-conforming interface over a coroutine like this:
> 
> class Generator: IteratorProtocol {
>  var next: T? = nil
>  var resume: (() -> ())? = nil
> 
>  init(_ body: (_ yield: @escaping (T) async -> Void) -> Void) {
>self.resume = {
>  beginAsync {
>body(self.yield)
>  }
>  }
> 
>  func next() -> T? {
>if let resume = self.resume {
>  resume()
>  return self.next
>}
>return nil
>  }
> 
>  private func yield(_ value: T) async -> Void {
>self.next = value
>await suspendAsync { cont in
>  resume = cont
>}
>  }
> }
> 
> let fibs = Generator { yield in
>  var (a, b) = (0, 1)
>  while a < 1000 {
>await yield(a)
>(a, b) = (b, a + b)
>  }
> }
> 
> This isn't ideal in a number of ways (awkward, not particularly efficient, 
> and has the gotcha that the generator's `body` could suspend itself with 
> something other than the `yield` operation, doesn't integrate with ownership 
> in the way John proposes in the ownership manifesto), so it may not be a good 
> idea, of course.
> 
>>> beginAsync
>>> 
>>> The documentation of the beginAsync and suspendAsync functions state:
>>> 
>>> // NB: Names subject to bikeshedding. These are low-level primitives that 
>>> most
>>> // users should not need to interact with directly, so namespacing them
>>> // and/or giving them verbose names unlikely to collide or pollute code
>>> // completion (and possibly not even exposing them outside the stdlib to 
>>> begin
>>> // with) would be a good idea.
>>> 
>>> But I don’t understand how they can be kept private to the standard library 
>>> when they are used for the important pattern of spawning off an async 
>>> operation from a non-async function:
> 
> beginAsync provides raw material for starting an async process, but I think 
> you'd often want to wrap it up in something more interesting, like a 
> DispatchQueue method that enqueues the coroutine on a specific queue, a 
> Future constructor that captures the eventual result, etc. Nonetheless, I 
> removed this statement from the proposal.
> 
>>> Despite these problems, it is essential that the model encompasses this 
>>> pattern, because it is a practical necessity in Cocoa development. With 
>>> this proposal, it would look like this:
>>> 
>>> @IBAction func buttonDidClick(sender:AnyObject) {
>>>   // 1
>>>   beginAsync {
>>> // 2
>>> let image = await processImage()
>>> imageView.image = image
>>>   }
>>>   // 3
>>> Futures
>>> 
>>> When discussing futures, the proposal states:
>>> 
>>> The exact design for a future type deserves its own proposal, but a proof 
>>> of concept could look like this:
>>> 
>>> Does that sentence imply that the Core Team would welcome a Future 
>>> implementation into the Standard Library?
> 
> It's worth discussing. My personal feeling is that a lot of the things people 
> do with futures can potentially be done better with other coordination 
> primitives, but we'll see.
> 
>>> async as a subtype of throws instead of orthogonal to it
>>> 
>>> I’ve been thinking a lot about this since the proposal came out and I see a 
>>> few serious disadvantages at making async a subtype of throws which might 
>>> benefit from being discussed or/and mentioned in the proposal.
>>> 
>>> 1. We loose the automatic document

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

[Goffredo Marocchi via swift-evolution]

Sorry, I thought that the default implementation in the protocol extension was 
how this was provided.

> Providing Default Implementations
> You can use protocol extensions to provide a default implementation to any 
> method or computed property requirement of that protocol
> 

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html#//apple_ref/doc/uid/TP40014097-CH25-ID521

Sent from my iPhone

>> On 19 Aug 2017, at 19:28, Xiaodi Wu  wrote:
>> 
>> On Sat, Aug 19, 2017 at 1:13 PM, Goffredo Marocchi  wrote:
>> We can override the protocol default implementation in the extension, but 
>> the issue I see with default implementation in Swift is that if I pass the 
>> object created this way around in a type erased container (Any : Protocol1   
>> like it was common for many to pass id around in the Objective-C 
>> days, a good practice IMHO) then my overrode would not be called, but the 
>> default implementation will be used instead. I would be far more comfortable 
>> with this “magic” provided for free of default implementations were 
>> dynamically dispatched.
> 
> Are you referring to protocol extension methods? Those are not default 
> implementations, do not have a corresponding protocol requirement that can be 
> overridden, and are not what's being discussed here.
> 
> 
>> Sent from my iPhone
>> 
 On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution 
  wrote:
 
 
 On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution 
  wrote:
 
>> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote:
>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution 
>> :
>> For me the whole point of a basic protocol is that it forces me to 
>> implement some requirements in order to conform; I can throw a bunch of 
>> protocols onto a type and know that it won't compile until I've finished 
>> it, developers get distracted, leave things unfinished to go back to 
>> later, make typos etc. etc. To me declaring a conformance is a 
>> declaration of "my type will meet the requirements for this make, sure I 
>> do it", not "please, please use some magic to do this for me"; there 
>> needs to be a clear difference between the two.
> 
> My conclusion isn't as pessimistic as yours, but I share your objections: 
> Mixing a normal feature (protocols) with compiler magic doesn't feel 
> right to me — wether it's Equatable, Hashable, Codable or Error.
> It's two different concepts with a shared name*, so I think even 
> AutoEquatable wouldn't be the right solution, and something like 
> #Equatable would be a much better indicator for what is happening.
> 
> Besides that specific concern, I can't fight the feeling that the 
> evolution process doesn't work well for proposals like this:
> It's a feature that many people just want to have as soon as possible, 
> and concerns regarding the long-term effects are more or less washed away 
> with eagerness.
> 
> - Tino
> 
> * for the same reason, I have big concerns whenever someone proposes to 
> blur the line between tuples and arrays
 
 Agreed. To be clear though; in spite of my pessimism this is a feature 
 that I do want, but I would rather not have it at all than have it 
 implemented in a way that hides bugs and sets a horrible precedent for the 
 future.
>>> 
>>> This was already touched upon during review, but to reiterate, the analogy 
>>> to default protocol implementations is meant specifically to address this 
>>> point about "hiding bugs." Yes, this feature cannot currently be 
>>> implemented as a default protocol implementation without magic; with better 
>>> reflection facilities there's a good chance that one day it might be, but 
>>> that's not the reason why it's being compared to default protocol 
>>> implementations. The reason for the comparison is that this feature only 
>>> "hides bugs" like a default protocol implementation "hides bugs" (in the 
>>> I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore
>>>  sense of "hiding bugs"), and the addition of default protocol 
>>> implementations, unless I'm mistaken, isn't even considered an API change 
>>> that requires Swift Evolution review.
>>> 
>>> Given Swift's emphasis on progressive disclosure, I'm fairly confident that 
>>> once reflection facilities and/or code-generation facilities improve, many 
>>> boilerplate-y protocol requirements will be given default implementations 
>>> where they cannot be written today. With every advance in expressiveness, 
>>> more protocol requirements that cannot currently have a default 
>>> implementation will naturally acquire them. Since the degree to which the 
>>> compiler will cease to give errors about non-implementation is directly in 
>>> proportion to the boilerplate reduced, it's not a defect

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

[Goffredo Marocchi via swift-evolution]

We can override the protocol default implementation in the extension, but the 
issue I see with default implementation in Swift is that if I pass the object 
created this way around in a type erased container (Any : Protocol1   like it 
was common for many to pass id around in the Objective-C days, a good 
practice IMHO) then my overrode would not be called, but the default 
implementation will be used instead. I would be far more comfortable with this 
“magic” provided for free of default implementations were dynamically 
dispatched.

Sent from my iPhone

> On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution 
>>  wrote:
>> 
 On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote:
 Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution 
 :
 For me the whole point of a basic protocol is that it forces me to 
 implement some requirements in order to conform; I can throw a bunch of 
 protocols onto a type and know that it won't compile until I've finished 
 it, developers get distracted, leave things unfinished to go back to 
 later, make typos etc. etc. To me declaring a conformance is a declaration 
 of "my type will meet the requirements for this make, sure I do it", not 
 "please, please use some magic to do this for me"; there needs to be a 
 clear difference between the two.
>>> 
>>> My conclusion isn't as pessimistic as yours, but I share your objections: 
>>> Mixing a normal feature (protocols) with compiler magic doesn't feel right 
>>> to me — wether it's Equatable, Hashable, Codable or Error.
>>> It's two different concepts with a shared name*, so I think even 
>>> AutoEquatable wouldn't be the right solution, and something like #Equatable 
>>> would be a much better indicator for what is happening.
>>> 
>>> Besides that specific concern, I can't fight the feeling that the evolution 
>>> process doesn't work well for proposals like this:
>>> It's a feature that many people just want to have as soon as possible, and 
>>> concerns regarding the long-term effects are more or less washed away with 
>>> eagerness.
>>> 
>>> - Tino
>>> 
>>> * for the same reason, I have big concerns whenever someone proposes to 
>>> blur the line between tuples and arrays
>> 
>> Agreed. To be clear though; in spite of my pessimism this is a feature that 
>> I do want, but I would rather not have it at all than have it implemented in 
>> a way that hides bugs and sets a horrible precedent for the future.
> 
> This was already touched upon during review, but to reiterate, the analogy to 
> default protocol implementations is meant specifically to address this point 
> about "hiding bugs." Yes, this feature cannot currently be implemented as a 
> default protocol implementation without magic; with better reflection 
> facilities there's a good chance that one day it might be, but that's not the 
> reason why it's being compared to default protocol implementations. The 
> reason for the comparison is that this feature only "hides bugs" like a 
> default protocol implementation "hides bugs" (in the 
> I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore
>  sense of "hiding bugs"), and the addition of default protocol 
> implementations, unless I'm mistaken, isn't even considered an API change 
> that requires Swift Evolution review.
> 
> Given Swift's emphasis on progressive disclosure, I'm fairly confident that 
> once reflection facilities and/or code-generation facilities improve, many 
> boilerplate-y protocol requirements will be given default implementations 
> where they cannot be written today. With every advance in expressiveness, 
> more protocol requirements that cannot currently have a default 
> implementation will naturally acquire them. Since the degree to which the 
> compiler will cease to give errors about non-implementation is directly in 
> proportion to the boilerplate reduced, it's not a defect but a feature that 
> these compiler errors go away. At the moment, it is a great idea to enable 
> some of these improvements for specific common use cases before the general 
> facilites for reflection and/or code-generation are improved in later 
> versions of Swift, since the user experience would be expected to remain the 
> same once those full facilities arrive.
> 
>> I realise I may seem to be overreacting, but I really do feel that strongly 
>> about what I fully believe is a mistake. I understand people's enthusiasm 
>> for the feature, I do; I hate boilerplate as much as the next developer, but 
>> as you say, it's not a reason to rush forward, especially when this is not 
>> something that can be easily changed later.
>> 
>> That's a big part of the problem; the decisions here are not just about 
>> trimming boilerplate for Equatable/Hashable, it's also about the potential 
>> overreach of every synthesised feature now and in the 

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] Inconsistencies related to prepositions

[Goffredo Marocchi via swift-evolution]

Thank you for the long reply, I do agree that I could have been more
constructive and what I said could have been more on point with the thread
at hand and better argued. I do like a complete and well written rebuttal,
chance for me to learn from it :).

On Thu, Aug 3, 2017 at 5:14 PM, Austin Zheng  wrote:

>
>
> On Thu, Aug 3, 2017 at 8:13 AM, Goffredo Marocchi 
> wrote:
>
>> Because what is the current idiomatic Swift of today may not be the Swift
>> of tomorrow if people are allowed to keep shaping it as it gets used in the
>> real world. Ideas can be imported from other languages and today's ideas
>> and philosophy are not dogmas.
>>
>
> The problem I see with your email is that it does not contribute anything
> to the discussion.
>
> - We _know_ Swift has an expressivity problem compared to Objective-C,
> many people have made this point loud and clear.
> - There are no useful concrete proposals or suggestions of design
> directions expressed in this email besides the rehashing of a point that
> has been made ad nauseaum on these lists, especially in places more
> appropriate for it (e.g. in proposal reviews that involved strengthening
> the type system).
>
>
>> Swift does value expressiveness, see the use of argument labels which is
>> perhaps more pervasive than it was in Objective-C (even more before the
>> change in argument labels that hit closures and callbacks).
>>
>
> Here is the crux of my disagreement with your email.
>
> Method naming conventions and static typing can be adjusted nearly
> independently of one another, and bringing up the latter in a discussion
> about the former is _not helpful_.
>
> You could remove Swift's type system tomorrow and still improve how
> methods are named. In fact, Swift's current naming conventions are quite
> suited for a dynamic language. You could also strengthen Swift's type
> system and improve method naming conventions. The two do not march in
> lockstep. "Expressiveness" is a huge, vague, and wide-reaching topic.
> Claiming that static typing is an expressiveness concern and therefore that
> complaining about it in a thread that deals with an almost completely
> unrelated feature strikes me as disingenuous. Help me out here.
>
>
>>
>>
>
>> I do not want to add noise to useful discussions so please do not assume
>> the worst in my statements, but I also do not think that the idea of "if
>> you do not like , go back to your  country" has merit
>> or is helpful to the evolution of the language.
>>
>
> Please.
>
> The issue at hand is not "go back to your country", it is "use the right
> tool for the job at hand".
>
> Engineering, like every field of human endeavor, has political elements,
> but it is not itself a fundamentally political endeavor. This gross
> anthropomorphization is beneath both you and I, and is better avoided for
> the happiness of all.
>
> As for contributing to the evolution of the language, your post is not the
> first of its quality, specific form, and sentiment that I've seen on the
> list, but only the first that I've been moved to respond to. So if I can
> steer future discussion in a more productive direction, I will consider
> this email chain to be a net positive, even if I have to send out quite a
> few more of these emails in reply :).
>
> With the utmost respect,
> Austin
>
>
>
>
>> On Thu, Aug 3, 2017 at 3:16 PM, Austin Zheng 
>> wrote:
>>
>>> If you want to use Objective-C you're free to use Objective-C, or more
>>> generally any of the wonderful languages that choose a different tradeoff
>>> regarding convenience over expressiveness. Otherwise, I'm not really sure
>>> what productive forward movement bringing up complaints about a fundamental
>>> philosophical underpinning of Swift that's not realistically going to
>>> change is supposed to achieve. As was mentioned in a message earlier this
>>> week, swift-evolution is a list to discuss making changes to the Swift
>>> language, not a list for ranting about things in Swift you don't like but
>>> cannot change.
>>>
>>> Regards,
>>> Austin
>>>
>>> On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution <
>>&g

[swift-evolution] Fwd: Inconsistencies related to prepositions

[Goffredo Marocchi via swift-evolution]

-- Forwarded message --
From: Goffredo Marocchi 
Date: Thu, Aug 3, 2017 at 4:13 PM
Subject: Re: [swift-evolution] Inconsistencies related to prepositions
To: Austin Zheng 


Because what is the current idiomatic Swift of today may not be the Swift
of tomorrow if people are allowed to keep shaping it as it gets used in the
real world. Ideas can be imported from other languages and today's ideas
and philosophy are not dogmas.
Swift does value expressiveness, see the use of argument labels which is
perhaps more pervasive than it was in Objective-C (even more before the
change in argument labels that hit closures and callbacks).

I do not want to add noise to useful discussions so please do not assume
the worst in my statements, but I also do not think that the idea of "if
you do not like , go back to your  country" has merit
or is helpful to the evolution of the language.

On Thu, Aug 3, 2017 at 3:16 PM, Austin Zheng  wrote:

> If you want to use Objective-C you're free to use Objective-C, or more
> generally any of the wonderful languages that choose a different tradeoff
> regarding convenience over expressiveness. Otherwise, I'm not really sure
> what productive forward movement bringing up complaints about a fundamental
> philosophical underpinning of Swift that's not realistically going to
> change is supposed to achieve. As was mentioned in a message earlier this
> week, swift-evolution is a list to discuss making changes to the Swift
> language, not a list for ranting about things in Swift you don't like but
> cannot change.
>
> Regards,
> Austin
>
> On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Sent from my iPhone
>
> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Brent had a draft proposal to revise the names of collection methods to
> improve the situation here. There is room for improvement.
>
>
> It didn't change `remove(at:)`, though. (Well, it might have affected its
> return value or something, I don't remember.) It mostly addressed the
> `dropLast()`, `prefix(_:)` etc. calls.
>
> To respond to the original post:
>
> Some of the APIs you cite are not very well named, but I think your
> diagnosis is incorrect and so your prescription isn't going to help.
>
> The reason for this is, whenever a preposition is used in English, it
> almost always takes a dyadic form, relating a subject to the preposition's
> object. The two most common dyadic formats are:
>
> * [ ]*
>  [ ] crossed the street.
>
> *[ <** object of preposition**>] *
> [ ],  can hear you scream.
> [ ] are .
>
> Now, in Objective C through Swift 1 and 2, prepositions' dyadic nature
> were generally respected in method signatures. However, Swift 3's migration
> of the preposition inside the parentheses also seems to have been
> accompanied by the stripping away of either the subject, the prepositional
> object, or both—according to no discernible pattern. For example:
>
> (1) CloudKit:
>
> old: myCKDatabase.fetchRecordWithID(recordID)
> new: myCKDatabase.fetch(withRecordID: recordID)
> *(subject "Record" got removed)*
>
>
> (2) String:
>
> old: myString.capitalizedStringWithLocale(_: myLocale)
> new: myString.capitalized(with: myLocale)
> *(subject "String" and prep. object "Locale" both got removed)*
>
>
> (3) Dictionary:
>
> old: myDict.removeAtIndex(myIndex)
> new: myDict.remove(at: myIndex)
> *(subject "element" already missing from both; prep. object "Index" got
> removed)*
>
>
> The thing is, the subjects and prepositional objects *are* present in all
> of these—they are the parameters and targets of the calls.
>
> In your own example, you say "In space, no one can hear you scream", not
> "In location space, group-of-people no one can hear you scream". So why is
> it a problem that we say "myString, capitalized with myLocale" instead of
> "myString, string capitalized with locale myLocale"? These are redundancies
> that we would never tolerate in natural language; I don't see why you think
> code should be different.
>
> (4) Date:
>
> old: myDate.timeIntervalSinceDate(myDate)
> new: myDate.timeIntervalSince(date: myDate)
> *(subject "timeInterval" and object "Date" both still present; but oddly,
> preposition "since" got left outside of the parentheses)*
>
>
> This is actually inaccurate—the paramet

Re: [swift-evolution] Inconsistencies related to prepositions

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Brent had a draft proposal to revise the names of collection methods to 
>> improve the situation here. There is room for improvement.
> 
> It didn't change `remove(at:)`, though. (Well, it might have affected its 
> return value or something, I don't remember.) It mostly addressed the 
> `dropLast()`, `prefix(_:)` etc. calls.
> 
> To respond to the original post:
> 
> Some of the APIs you cite are not very well named, but I think your diagnosis 
> is incorrect and so your prescription isn't going to help.
> 
>> The reason for this is, whenever a preposition is used in English, it almost 
>> always takes a dyadic form, relating a subject to the preposition's object. 
>> The two most common dyadic formats are:
>> 
>>  [ ]
>>  [ ] crossed the street. 
>> 
>> [ < object of preposition>] 
>> [ ],  can hear you scream.
>> [ ] are .
>> 
>> Now, in Objective C through Swift 1 and 2, prepositions' dyadic nature were 
>> generally respected in method signatures. However, Swift 3's migration of 
>> the preposition inside the parentheses also seems to have been accompanied 
>> by the stripping away of either the subject, the prepositional object, or 
>> both—according to no discernible pattern. For example: 
>> 
>> (1) CloudKit:
>> 
>> old: myCKDatabase.fetchRecordWithID(recordID)
>> new: myCKDatabase.fetch(withRecordID: recordID)
>> (subject "Record" got removed)
>> 
>> (2) String:
>> 
>> old: myString.capitalizedStringWithLocale(_: myLocale)
>> new: myString.capitalized(with: myLocale)
>> (subject "String" and prep. object "Locale" both got removed)
>> 
>> (3) Dictionary:
>> 
>> old: myDict.removeAtIndex(myIndex)
>> new: myDict.remove(at: myIndex)
>> (subject "element" already missing from both; prep. object "Index" got 
>> removed)
> 
> The thing is, the subjects and prepositional objects *are* present in all of 
> these—they are the parameters and targets of the calls. 
> 
> In your own example, you say "In space, no one can hear you scream", not "In 
> location space, group-of-people no one can hear you scream". So why is it a 
> problem that we say "myString, capitalized with myLocale" instead of 
> "myString, string capitalized with locale myLocale"? These are redundancies 
> that we would never tolerate in natural language; I don't see why you think 
> code should be different.
> 
>> (4) Date:
>> 
>> old: myDate.timeIntervalSinceDate(myDate)
>> new: myDate.timeIntervalSince(date: myDate)
>> (subject "timeInterval" and object "Date" both still present; but oddly, 
>> preposition "since" got left outside of the parentheses)
> 
> This is actually inaccurate—the parameter to `timeIntervalSince(_:)` is 
> unlabeled, so it's:
> 
>   new: myDate.timeIntervalSince(myDate)
> 
>> (5) Array:
>> 
>>  old: myArray.forEach({ thing in code})
>> new: myArray.forEach() { thing in //code }
>> (preposition “for” is outside of the parentheses)
> 
> Yes, because the preposition does not apply to the parameter—it applies to 
> the operation as a whole. I'll have more to say on this in a moment.
> 
>> The inconsistency between the examples is shown in the bold text of each 
>> example, but lets go over why this matters. It matters because any language 
>> is easier to learn the more consistently it sticks to its own rules.
> 
> 
> This is true, but you aren't just proposing sticking more closely to our 
> existing standards—you're proposing *changing* our standards. And I don't 
> think the changes you propose are an improvement. In fact, I'd say each of 
> these examples is worse:
> 
>> (1) myCKDatabase.fetchRecord(withRecordID:)
> 
> "Fetch record with record ID"? I mean, you could at least remove the `Record` 
> before `ID`. What other ID do you suppose it would be?
> 
> I *can* see the case for going back to `fetchRecord` instead of just `fetch`, 
> though. On the other hand, I do think that, if you know it's a database, the 
> most obvious thing for `fetch` to be fetching is a record from that database. 
> It's not a dog—it won't be fetching a stick.
> 
>> (2) myString.stringCapitalized(withLocale:)
> 
> Let's translate this to an actual use site, which is what we care about.
> 
>   func tableView(_: UITableView, titleForHeaderInSection section: Int) -> 
> String? {
>   return sections[section].title.stringCapitalized(withLocale: 
> .current)
>   }
> 
> What is `string` contributing here? We already know it's a "title", which 
> sounds a lot like a string. If you asked for a "capitalized" string, what 
> else would you get back if not another string?
> 
> The locale parameter is a little more tricky. You're right that `(with: 
> .current)` is vague, but I can imagine plenty of call sites where `with` 
> wouldn't be:
> 
>   title.capitalized(with: german)
>   title.capitalized(with: docLoc

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 Aug 2017, at 01:09, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 'required' initializers are like methods: they may require dynamic dispatch. 
> That means that they get an entry in the class's dynamic dispatch table, 
> commonly known as its vtable. Unlike Objective-C method tables, vtables 
> aren't set up to have entries arbitrarily added at run time.
> 
> (Aside: This is one of the reasons why non-@objc methods in Swift extensions 
> can't be overridden; if we ever lift that restriction, it'll be by using a 
> separate table and a form of dispatch similar to objc_msgSend. I sent a 
> proposal to swift-evolution about this last year but there wasn't much 
> interest.)

If I missed replying to that originally I also missed the chance to say that it 
would be a lovely idea and dynamic dispatch in some cases is just what the 
doctor ordered (runtime editable method tables).
This is especially especially important with extensions for classes and default 
methods (and the current rules for overriding methods in the implementing 
class), please resubmit the proposal :).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 31 Jul 2017, at 08:40, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution 
>>  wrote:
>> > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution 
>> >  wrote:
>> >
>> >> On Jul 30, 2017, at 11:43 PM, Daryle Walker  wrote:
>> >> The parameters for a fixed-size array type determine the type's 
>> >> size/stride, so how could the bounds not be needed during compile-time? 
>> >> The compiler can't layout objects otherwise.
>> >
>> > Swift is not C; it is perfectly capable of laying out objects at run time. 
>> >  It already has to do that for generic types and types with resilient 
>> > members.  That does, of course, have performance consequences, and those 
>> > performance consequences might be unacceptable to you; but the fact that 
>> > we can handle it means that we don't ultimately require a semantic concept 
>> > of a constant expression, except inasmuch as we want to allow users to 
>> > explicitly request guarantees about static layout.
>> 
>> Doesn't this defeat the purpose of generic value parameters? We might as 
>> well use a regular parameter if there's no compile-time evaluation involved. 
>> In that case, fixed-sized arrays will be useless, because they'll be normal 
>> arrays with resizing disabled.
> 
> OTOH, if the compiler can prove that a local array is never resized, why 
> *shouldn't* it get all the benefits of a fixed-sized array without having to 
> use a special syntax? Put another way, why shouldn't fixed-size be one of 
> those optional attributes for arrays, like ownership will be for variables, 
> that users can opt into for more performance but is otherwise automatically 
> worked out by the compiler?

Because in some cases humans may make an easier judgement call than the 
compiler? Because the compiler complexity is already growing and compile time 
is not exactly showing massive reductions and people are worried that as Swift 
gains more features and complexity with genetics and reflection and other 
features that compilation time will grow even more?

> 
>> As far as I know, the pinnacle of uses for fixed-size arrays is having a 
>> compile-time pre-allocated space of the necessary size (either literally at 
>> compile-time if that's a static variable, or added to the pre-computed 
>> offset of the stack pointer in case of a local variable).
>> 
>> > Value equality would still affect the type-checker, but I think we could 
>> > pretty easily just say that all bound expressions are assumed to 
>> > potentially resolve unequally unless they are literals or references to 
>> > the same 'let' constant.
>> 
>> Shouldn't the type-checker use the Equatable protocol conformance to test 
>> for equality? Moreover, as far as I know, Equatable is not recognized by the 
>> compiler in any way, so it's just a regular protocol. What would make it 
>> special? Some types would implement operator == to compare themselves to 
>> other types, that's beyond the scope of Equatable. What about those? And how 
>> are custom operator implementations going to serve this purpose at 
>> compile-time? Or will it just ignore the semantics of the type and reduce it 
>> to a sequence of bits? Or maybe only a few hand-picked types will be 
>> supported?
>> 
>> The seemingly simple generic value parameter concept gets vastly complicated 
>> and/or poorly designed without an elaborate compile-time execution system... 
>> Unless I'm missing an obvious way out.
>> 
>> > The only hard constraint is that types need to be consistent, but that 
>> > just means that we need to have a model in which bound expressions are 
>> > evaluated exactly once at runtime (and of course typically folded at 
>> > compile time).
>> 
>> What exactly would it take to be able to execute select piece of code at 
>> compile-time? Taking the AST, converting it to LLVM IR and feeding it to the 
>> MCJIT engine seems to be easy enough. But I'm pretty sure it's more tricky 
>> than that. Is there a special assumption or two made about the code that 
>> prevents this from happening?
>> 
>> > John.
>> >
>> >> Or do you mean that the bounds are integer literals? (That's what I have 
>> >> in the design document now.)
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Jul 30, 2017, at 8:51 PM, John McCall  wrote:
>> >>
>>  On Jul 29, 2017, at 7:01 PM, Daryle Walker via swift-evolution 
>>   wrote:
>>  The “constexpr” facility from C++ allows users to define constants and 
>>  functions that are determined and usable at compile-time, for 
>>  compile-time constructs but still usable at run-time. The facility is a 
>>  key step for value-based generic parameters (and fixed-size arrays if 
>>  you don’t want to be stuck with integer literals for bounds). Can 
>>  figuring out Swift’s story here be part of Swift 5?
>> >>>
>> >>> Note that there's no particular reason that value-based generic 
>> >>> parameters, includin

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

[Goffredo Marocchi via swift-evolution]

> They are _not_ meant to reopen the floor for anyone who already voiced their 
> opinion on the original proposal simply to restate their opposition to 
> particular changes.


Yes, Xiaodi I understand you are trying to help, but I find that sometimes you 
do talk down to other posters a bit vocally policing what should or not be said.

Sent from my iPhone

> On 21 Jul 2017, at 21:04, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Over the last months, I started two threads to discuss revisions to SE-0104; 
> these received essentially no reply. I’m quite sure others have touched on 
> these topics too. This is a thread to formally _review_ certain changes, not 
> a thread to “talk about” revisions generally.
> 
> With respect to the specific issues raised: revisions are opportunities, as 
> was well said, to apply new insights gained from experience. They are _not_ 
> meant to reopen the floor for anyone who already voiced their opinion on the 
> original proposal simply to restate their opposition to particular changes. 
> While every_one_ should certainly be welcomed to the community, that does not 
> mean that every kind of participation should be. I don’t think we should be 
> shy about saying, “I’m sorry, this is not a helpful comment at this time and 
> place.”
> On Fri, Jul 21, 2017 at 11:47 David Hart via swift-evolution 
>  wrote:
>>> On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution 
>>>  wrote:
>>> 
>>> The updates look fine and reasonable to me.
>>> 
>>> That said, I think it is highly important that we have clarity regarding 
>>> what *is* the proper time, method, and process for raising issues with and 
>>> suggesting modifications to approved proposals. If there is one thing we 
>>> have learned recently it is that sometimes a proposed change sounds good 
>>> and gets approved (110, 25, etc.) which subsequently turns out to have 
>>> unintended detrimental consequences.
>>> 
>>> We are not infallible, and there will certainly be times in the future when 
>>> we think a change is good in theory, but then after experiencing it in 
>>> practice we recognize it has problems. When that happens—and happen it 
>>> will—we need to be able to correct our course. And it is far better to fix 
>>> such things before they are released to the wider world.
>>> 
>>> I don’t know if the issues Howard raises rise to that level. I haven’t 
>>> tested out the new integer protocols, so I am not in a position to weigh 
>>> the merits of the claim. Certainly in the abstract “signum” sounds like it 
>>> is asking for a property of the number, and not asking the number to do 
>>> something function-like, but I defer to those who use it in practice.
>>> 
>>> The point is, rather than shutting down discussion by saying “it has 
>>> already been approved” and “this is not the place for discussing that”, it 
>>> would greatly behoove the Swift Evolution process to have an established 
>>> method for recommending changes to already-approved proposals. We have this 
>>> time interval between when a proposal is accepted and when it appears in a 
>>> public release of the language, and it seems only natural to use it as a 
>>> beta-testing period.
>> 
>> I think it also important that we encourage people to participate and not 
>> drive them away. If we decide that a thread talking about revisions to a 
>> proposal is not the right place to discussion other grievances about the 
>> same proposal, perhaps a new thread is the right place.
>> 
>>> That way we can fix problems we encounter before they become permanent, and 
>>> similarly we can make minor changes which are obvious improvements we 
>>> somehow overlooked during the initial review.
>>> 
>>> Nevin
>>> 
>>> 
 On Fri, Jul 21, 2017 at 7:50 AM, Xiaodi Wu via swift-evolution 
  wrote:
 I understand you feel this way, but this thread is a formal review of 
 specific amendments to SE-0104. Those amendments are, again, the following:
 
 * Reorganizing shift operators
 * Removing the ArithmeticOverflow type in favor of using a simple Bool
 * Changing BinaryInteger's initializers that convert from floating point 
 values
 * Renaming BinaryInteger's init(extendingOrTruncating:)
 
> On Fri, Jul 21, 2017 at 02:08 Haravikk via swift-evolution 
>  wrote:
> 
>> On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Hi Howard,
>> 
>> The removal of BitwiseOperations is not under review here; that, like 
>> signum(), has been considered twice and approved twice, and has not been 
>> revised.
>> 
>> On Thu, Jul 20, 2017 at 19:36 Howard Lovatt via swift-evolution 
>>  wrote:
 The revised version of the proposal can be found here:
 https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
 
• What is your evaluation of the proposal?
>>> 
>>> 
>>> Overall +1. Two re

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

[Goffredo Marocchi via swift-evolution]

Mmh, I think like the do while -> repeat while change it makes sense, but not 
enough to displace the obvious meaning of the original... but then again, I 
lost back then...

Sent from my iPhone

Begin forwarded message:

> From: Andrew Trick via swift-evolution 
> Date: 18 July 2017 at 21:33:31 BST
> To: Taylor Swift 
> Cc: swift-evolution 
> Subject: Re: [swift-evolution] Pitch: Improved Swift pointers
> Reply-To: Andrew Trick 
> 
> 
>>> On Jul 18, 2017, at 11:36 AM, Taylor Swift  wrote:
>>> 
>>> > fix the ordering of the arguments in 
>>> > initializeMemory(as:at:count:to:)
>>> 
>>> I think this ordering was an attempt to avoid confusion with binding
>>> memory where `to` refers to a type. However, it should be consistent
>>> with `UnsafePointer.initialize`, so we need to pick one of those to
>>> change.
>> 
>> This would be a non-issue had we just been consistent with the rest of the 
>> stdlib and named this argument `repeating:` instead of `to:`. But 
>> `ptr.initialize(repeating: 255, count: 100)` doesn’t read quite as naturally 
>> in English as `ptr.initialize(to: 255, count: 100)` which is why I left this 
>> idea out of the proposal. Now that you mention the problem with 
>> `initializeMemory(as:at:count:to:)`, it might be a good idea to add 
>> this rename back into it.
> 
> I think `repeating` is much more clear.
> 
> -Andy
> ___
> 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] ability to derive a class from a struct or other value type

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 23 Jun 2017, at 21:08, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 23 Jun 2017, at 16:20, Mike Kluev  wrote:
>> 
>> on Fri Jun 23 05:26:11 CDT 2017 Haravikk swift-evolution at haravikk.me 
>> wrote:
>> 
>> > Not sure what you mean by added indirection here, the following seems 
>> > perfectly straightforward to me:
>> > 
>> >protocol Foo {
>> >var someValue:Int { get set }
>> >func a() -> Any?
>> >}
>> > 
>> >extension Foo {
>> >func a() -> Any? { return self.someValue }
>> >}
>> > 
>> >struct ValueSemantics:Foo { var someValue:Int }
>> >class ReferenceSemantics:Foo {
>> >var someValue:Int { return nil }
>> >}
>> > 
>> > There is no added access overhead here, the only difference is that the 
>> > protocol itself leaves it up to 
>> > implementations whether someValue is stored or computed.
>> 
>> in real cases there would be more variables:
>> 
>> //
>> protocol P1 {   // #noise
>> var var1: Int { get set }   // #noise
>> var var2: Int { get set }   // #noise
>> // ...  // #noise x 100
>> var var100: Int { get set } // #noise
>> 
>> func foo1() -> Int  // #noise
>> func foo2() -> Int  // #noise
>> // ...  // #noise x 100
>> func foo100() -> Int// #noise
>> }
>> 
>> extension P1 {  // #noise
>> func foo1() -> Int { return var1 * 2 }
>> func foo2() -> Int { return var2 * 2 }
>> // ...
>> func foo100() -> Int { return var100 * 2 }
>> }
>> 
>> struct S1: P1 {
>> var var1: Int   // #noise
>> var var2: Int   // #noise
>> // ...  // #noise x 100
>> var var100: Int // #noise
>> }
>> 
>> class C1: P1 {
>> var var1: Int = 0   // #noise
>> var var2: Int = 0   // #noise
>> // ...  // #noise x 100
>> var var100: Int = 0 // #noise
>> }
>> //
>> 
>> 
>> lots of noise and violations of DRY. you may try to mitigate it by putting 
>> all those storage into another struct, that was the indirection i was 
>> thinking about:
> 
> Maybe, but the whole point of the protocol is that it's a contract

... and this is why I do not like code in then (see default method in protocol 
extensions essentially just to allow code sharing across structs) :P.


> , it's up to the implementing types how the properties are actually stored 
> (if at all); in that respect it's not noise, as it's necessary.
> 
> The shorthand you're proposing is effectively masquerading delegation as 
> extension; I'm not sure making it look like extension is the right way togo, 
> but delegation is absolutely something I support, just not in this style.
> 
> Currently there is a lot of boilerplate around things like type-erased 
> wrappers, where you might get a class that looks like:
> 
>   class MyWrapper:Foo {
>   struct foo:S
> 
>   func someMethodOfFoo() { foo.someMethodOfFoo() }
>   func someOtherMethodOfFoo() { foo.someOtherMethodOfFoo() }
>   }
> 
> It's the same basic problem, except that I don't necessarily want everything 
> to be implemented by my enclosed struct. This is why I'd prefer a solution 
> that's more explicit about the fact that there's delegation going on, and 
> more flexible about how things are delegated. This is what I mean:
> 
>   protocol Foo {
>   var someValue:Int { get set }
>   func someMethod() -> Int
>   }
> 
>   struct ValueType:Foo {
>   var someValue:Int
>   func someMethod() { return self.someValue }
>   }
> 
>   class ReferenceType:Foo {
>   var foo:ValueType implements Foo // This is the important bit
>   }
> 
> It's got one extra step, but is explicit that there's delegation involved, 
> and without suggesting some kind of hierarchy that doesn't exist. In this 
> case ValueType needn't even conform to Foo at all, just as long it has 
> properties and methods that are a match; in this way we could potentially 
> conform to Foo using multiple delegates that each implement a little bit of 
> the protocol.
> 
> Another possible syntax is:
> 
>   class ReferenceType:Foo {
>   delegate(Foo) var foo:ValueType
>   }
> 
> This may be slightly better as it explicitly references to delegation, but 
> it's the same idea; in the brackets you put one or more types, or members of 
> types, that the property is a delegate for.
> ___
> 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.swif

Re: [swift-evolution] Revisiting SE-0110

[Goffredo Marocchi via swift-evolution]

It seems to me that we have a general problem with labels and every time we 
have to push things around they break and we simply rip them out: first with 
argument labels in closures and stores functions (sigh... :/, but we may get 
labels back somehow there one day not too far from now hopefully) and now with 
tuples.

P.S.:
I keep on thinking the urge of moving so much real world code over to it before 
the language matured (were Swift 1 and 2 the right point to move production 
code en masse?) did not leave enough time for breaking changes and discussions 
about fixing remnants of choices made with Swift 1,2, and 3 may make big 
discussions like this (and access control) here more and more prevalent, but I 
may just be a laggard/Luddite ;).

Sent from my iPhone

> On 16 Jun 2017, at 07:04, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, Jun 16, 2017 at 12:17 AM, David Hart  wrote:
>> 
>> 
>>> On 16 Jun 2017, at 01:55, Xiaodi Wu  wrote:
>>> 
>>> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>> On 16 Jun 2017, at 00:41, David Hart  wrote:
>> 
>> 
>> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>> 
>> 
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
>>  o
>> >
>> >   let (a : Int, b : Float) = foo()
>> 
>> 
>> I think it would be better if the compiler raised a warning whenever 
>> you tried to redefine a builtin type.
> 
> That’s essentially my preferred solution as well, as it gets to the 
> root of the confusion.
> 
> Naming a variable the same as a type should be similar to naming a 
> variable the same as a reserved keyword and require backticks. (A 
> previous suggestion to enforce capitalization falls down with full 
> Unicode support and complicates interop where imported C structures 
> might be lowercase and constants might be all caps.) No need to treat 
> built-in types specially; it’s equally a problem with types imported 
> from other libraries, which can be shadowed freely today. For full 
> source compatibility this can be a warning instead of an error–should 
> be sufficient as long as it’s brought to the user’s attention. In 
> fact, probably most appropriate as a warning, since the _compiler_ 
> knows exactly what’s going on, it’s the human that might be confused.
 
 I kind of agree with all you say. But I also feel that tuple element 
 names in patterns are very rarely used and not worth the added 
 complexity and confusing. Going back to the old: “Would be add it to 
 Swift if it did not exist?”, I would say no.
>>> 
>>> That was the standard for removing features before Swift 3, but with 
>>> source compatibility the bar is now much higher.
>> 
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 
>> type system capability that no one uses.  I have no data to show that 
>> though.
>> 
>>> Is the feature harmful?
>> 
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is 
>> that swift has a meaning for that very syntax in other contexts, and 
>> that this is completely different meaning.  People absolutely would get 
>> confused by this if they encountered it in real code that they 
>> themselves didn't write, and I'm not aware of any good (non theoretical) 
>> use for it.
>> 
>>> My point is, not on its own it isn’t: warning on variables shadowing 
>>> types is sufficient to resolve the problems shown here.
>> 
>> Again, my concern is that this is a confusing and misleading feature 
>> which complicates and potentially prevents composing other features in 
>> the future.
>> 
>> 
>>> 
>>> How strange that we’re talking about this issue in a thread about 
>>> SE-0110.
>> 
>> This came up in the discussion about 110 because we were exploring 
>> whether it was plausible to expand the function parameter grammar to 
>> support destructuring in the position where a name goes.  There are many 
>> concerns about whether this is a good idea, but he existence of this in 
>> the tuple destructuring pattern grammar is pretty much a showstopper.
>> 
>>> If anything, the response to that proposal should be a cautionary tale 
>>> that users can take poorly to removing features, sometimes in 
>>> unanticipated ways.
>> 
>> Agreed, it may be too late to correct this (certainly we can't outright 
>> remove it in Swift 4 if someone is using it for something important).  
>> However if it turns out that it really isn't used, then warning about it 
>> in 4 and removing it shortly after may be possible.
> 
> And I think its difficult to make the parallel between the two. SE-0110 
> basically impacted everybody calling higher

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 15 Jun 2017, at 05:41, Paul Cantrell via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution 
>>>  wrote:
>>> 
>>> On 14.06.2017 21:23, Haravikk via swift-evolution wrote:
> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>Sorry, initially sent off-list:
> 
>I think this proposal is a great idea. But I would vote for the 
> alternative of
>only having default and implicitly deducing extend when default is not 
> specified:
> 
> 
> This wouldn't work with the fundamental design decision that these are 
> optional keywords, which IMO is absolutely key.
>>> 
 Hmm, I'm inclined to agree with David that only the default keyword really 
 seems like it's necessary, and that extend can be implied.
>>> …
>> 
>> I think a good plan would be to make default required in a later Swift 
>> version (Swift 5) for example, and only warn for now.
> 
> I like only having “default,” and I like David’s plan for achieving that.
> 
> • • •
> 
> It seems that this proposal could help mitigate the problems described in the 
> classic “Ghost of Swift Bugs Future” 
> (https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future). There’s a 
> nice new convention (I think?) of:
> 
> `extend` / no modifier in extension → static dispatch
> `default`  in extension → dynamic dispatch
> 
> (Does this always hold in an extensions?)
> 
> Knowing whether the extension’s author •intended• static or dynamic dispatch 
> could also allow the compiler to give better warnings: about shadowing at 
> declaration sites, and also also potentially at call sites where multiple 
> extension methods could match depending on the compile-time type of the 
> receiver.

+1

To me static dispatch is an optimisation over dynamic one, but it should only 
be applied when it cannot introduce side effects or when the programmer is 
asking for it explicitly: code path execution should never change no matter how 
we are casting a reference (base type or subclass) and users should know if 
they are implementing a method that will never be called as it shadows a 
default method only declared in a protocol extension.

Thanks for reminding the list of this article: 
https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future 

These problems should be addressed.

> 
> Might it be worth describing some of these warnings out in the proposal? I 
> realize warnings don’t require full swift-evo treatment, but it would be nice 
> to at least sketch out in the “Impact on Existing Code” section what the 
> warnings might look like.
> 
> Cheers,
> 
> Paul
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 14 Jun 2017, at 21:41, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Wed, Jun 14, 2017 at 3:37 PM, Vladimir.S via swift-evolution 
>>  wrote:
>>> On 14.06.2017 21:23, Haravikk via swift-evolution wrote:
>>> 
 On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Sorry, initially sent off-list:
 
 I think this proposal is a great idea. But I would vote for the 
 alternative of
 only having default and implicitly deducing extend when default is not 
 specified:
 
 
 This wouldn't work with the fundamental design decision that these are 
 optional keywords, which IMO is absolutely key.
>>> 
>>> Hmm, I'm inclined to agree with David that only the default keyword really 
>>> seems like it's necessary, and that extend can be implied.
>>> 
>> 
>> I'm not so sure. If they are optional, then it depends on developer if 
>> he/she wants to explicitly mark some func to avoid possible errors. Please 
>> look here :
>> 
>> 1. First we have this
>> 
>> protocol A {
>>   func foo() {}
>> }
>> 
>> and we  write extension (possible in another file)
>> 
>> extension A {
>>   extent func bar() {} // I'm sure currently I want *additional* 'bar' method
>> }
>> 
>> 2. Then 'A' protocol has been changed for some reason :
>> 
>> protocol A {
>>   func foo() {}
>>   func bar() {}
>> }
>> 
>> Now, if we have 'extent' - we(compiler) can detect the problem here('bar' 
>> was not the default implementation for A's requirement). Without 'extent' - 
>> 'bar' will be default implementation without our intent for this.
>> 
>> So, in case suggested keywords are both optional - IMO we need both.
>> In case 'default' is required - then yes, we need only it.
> 
> Yes, I think we are all in vigorous agreement about this. The question is 
> whether, at this point in Swift's evolution, a wide-ranging migration due to 
> a new required keyword will be well tolerated. If not, then the solution is 
> constrained.
> 

I personally vote to accept such a migration at this point, but I am not sure 
how others feel.

>> 
>>> My preference would be to just add the default keyword, and have breaches 
>>> treated as warnings using the current behaviour, which we can eliminate and 
>>> elevate to an error in future once people have had a chance to change their 
>>> code.
>>> 
>>> 
>>> ___
>>> 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] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

[Goffredo Marocchi via swift-evolution]

If it is low cost and people do not come up with regressions/high cost + 
negative impact scenarios then I would say go full steam ahead. It does address 
an annoying scenario.

Sent from my iPhone

> On 10 Jun 2017, at 12:04, Gor Gyolchanyan  wrote:
> 
> Not much, I think. The `where` clause already exists, conditional `let` and 
> `var` binding already exists. It'd take loosening up conditional binding 
> rules a bit and expanding the lexical structure to include `let` and `var` 
> bindings in `repeat`.
> 
>> On Jun 10, 2017, at 2:01 PM, Goffredo Marocchi  wrote:
>> 
>> Quite interesting :), what impact would it have on the compiler?
>> 
>> Sent from my iPhone
>> 
>>> On 10 Jun 2017, at 11:46, Gor Gyolchanyan via swift-evolution 
>>>  wrote:
>>> 
>>> I think a better way of achieving this would be to use the already existing 
>>> `where` keyword in loops. The way it works right now is as follows:
>>> 
>>> let many = [1, 2, 3, 4, 5]
>>> for each in many where each % 2 == 0 {
>>> print("found an even number: \(each)")
>>> }
>>> 
>>> Unfortunately, unlike all other conditional scopes, `where` does not allow 
>>> `let` and `var` bindings in it, so I'd suggest we add ability to do that:
>>> 
>>> let many: [Int?] = [1, 2, nil, 3, 4, nil, 5]
>>> for each in many where let number = each {
>>> print("found a non-nil number: \(number)")
>>> }
>>> 
>>> Or, more interestingly:
>>> 
>>> for each in many where let number = each, number % 2 == 0 {
>>> print("found a non-nil even number: \(number)")
>>> }
>>> 
>>> And in case of a while loop:
>>> 
>>> var optional: Int? = 1
>>> while let nonoptional = optional {
>>> if nonoptional >= 10 {
>>> optional = nil
>>> }
>>> optional = nonoptional + 1
>>> }
>>> 
>>> But this is only for optional unpacking, so another addition would be to 
>>> allow any `let` and `var` bindings in conditional scopes without them 
>>> contributing to the condition itself:
>>> 
>>> while let a = 0, a < 10 {
>>> a += 1
>>> print(a)
>>> }
>>> 
>>> And finally, allow these bindings in `repeat`:
>>> 
>>> repeat let a = 0 {
>>> a += 1
>>> print(0)
>>> } while a < 10
>>> 
>>> I think **if** the core team would consider this a worthwhile addition, 
>>> this would be a less invasive and more intuitive way of achieving what you 
>>> want.
>>> 
 On Jun 10, 2017, at 1:31 PM, Haravikk via swift-evolution 
  wrote:
 
 Not sure if my e-mail didn't go through or if discussion just fizzled out; 
 one other benefit if we ever move to a proper message board is we might 
 gain the ability to bump topics. Anyway, I'll resend my message just in 
 case:
 
 
 
 Just to add my thoughts, as I like the idea of adding the variables to the 
 start somehow, but was wondering if might make sense to have a keyword 
 such as "using", but allow it on all block statements, like-so:
 
// Original use-case of repeat … while
repeat using (var i = 0) {
// Do something
} while (i < 20)
 
// for … in demonstrating combination of using and where
for eachItem in theItems using (var i = 0) where (i < 20) {
// Do something either until theItems run out or i reaches 20
}
 
// Standard while loop
while let eachItem = it.next() using (var i = 0) where (i < 20) {
// As above, but with an iterator and a while loop and 
 conditional binding to also stop on nil
}
 
// Closure with its own captured variable
let myClosure:(Int) -> Int = using (var i = 0) { i += 1; return i * $0 }
 
// If statements as well
if somethingIsTrue() using (var i = 0) where (i < 20) {
// Do something
}
 
// Or even a do block; while it does nothing functionally new, I quite 
 like it aesthetically
do using (var i = 0) {
// Do something
}
 
 Unifying principle here is that anything created in the using clause 
 belongs to the loop, conditional branch etc. only, but exists outside the 
 block itself (thus persisting in the case of loops and closures). I quite 
 like the possible interaction with where clauses here as a means to avoid 
 simple inner conditionals as well.
 
 Basically the two clauses can work nicely together to avoid some common 
 inner and outer boilerplate, as well as reducing pollution from throwaway 
 variables.
 
 Only one I'm a bit iffy on is the closure; I'm trying to avoid declaring 
 the captured variable externally, but I'm not convinced that having using 
 on its own is clear enough?
 
 Anyway, just an idea!
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> __

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

[Goffredo Marocchi via swift-evolution]

Quite interesting :), what impact would it have on the compiler?

Sent from my iPhone

> On 10 Jun 2017, at 11:46, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> I think a better way of achieving this would be to use the already existing 
> `where` keyword in loops. The way it works right now is as follows:
> 
> let many = [1, 2, 3, 4, 5]
> for each in many where each % 2 == 0 {
>   print("found an even number: \(each)")
> }
> 
> Unfortunately, unlike all other conditional scopes, `where` does not allow 
> `let` and `var` bindings in it, so I'd suggest we add ability to do that:
> 
> let many: [Int?] = [1, 2, nil, 3, 4, nil, 5]
> for each in many where let number = each {
>   print("found a non-nil number: \(number)")
> }
> 
> Or, more interestingly:
> 
> for each in many where let number = each, number % 2 == 0 {
>   print("found a non-nil even number: \(number)")
> }
> 
> And in case of a while loop:
> 
> var optional: Int? = 1
> while let nonoptional = optional {
>   if nonoptional >= 10 {
>   optional = nil
>   }
>   optional = nonoptional + 1
> }
> 
> But this is only for optional unpacking, so another addition would be to 
> allow any `let` and `var` bindings in conditional scopes without them 
> contributing to the condition itself:
> 
> while let a = 0, a < 10 {
>   a += 1
>   print(a)
> }
> 
> And finally, allow these bindings in `repeat`:
> 
> repeat let a = 0 {
>   a += 1
>   print(0)
> } while a < 10
> 
> I think **if** the core team would consider this a worthwhile addition, this 
> would be a less invasive and more intuitive way of achieving what you want.
> 
>> On Jun 10, 2017, at 1:31 PM, Haravikk via swift-evolution 
>>  wrote:
>> 
>> Not sure if my e-mail didn't go through or if discussion just fizzled out; 
>> one other benefit if we ever move to a proper message board is we might gain 
>> the ability to bump topics. Anyway, I'll resend my message just in case:
>> 
>> 
>> 
>> Just to add my thoughts, as I like the idea of adding the variables to the 
>> start somehow, but was wondering if might make sense to have a keyword such 
>> as "using", but allow it on all block statements, like-so:
>> 
>>  // Original use-case of repeat … while
>>  repeat using (var i = 0) {
>>  // Do something
>>  } while (i < 20)
>> 
>>  // for … in demonstrating combination of using and where
>>  for eachItem in theItems using (var i = 0) where (i < 20) {
>>  // Do something either until theItems run out or i reaches 20
>>  }
>> 
>>  // Standard while loop
>>  while let eachItem = it.next() using (var i = 0) where (i < 20) {
>>  // As above, but with an iterator and a while loop and 
>> conditional binding to also stop on nil
>>  }
>> 
>>  // Closure with its own captured variable
>>  let myClosure:(Int) -> Int = using (var i = 0) { i += 1; return i * $0 }
>> 
>>  // If statements as well
>>  if somethingIsTrue() using (var i = 0) where (i < 20) {
>>  // Do something
>>  }
>> 
>>  // Or even a do block; while it does nothing functionally new, I quite 
>> like it aesthetically
>>  do using (var i = 0) {
>>  // Do something
>>  }
>> 
>> Unifying principle here is that anything created in the using clause belongs 
>> to the loop, conditional branch etc. only, but exists outside the block 
>> itself (thus persisting in the case of loops and closures). I quite like the 
>> possible interaction with where clauses here as a means to avoid simple 
>> inner conditionals as well.
>> 
>> Basically the two clauses can work nicely together to avoid some common 
>> inner and outer boilerplate, as well as reducing pollution from throwaway 
>> variables.
>> 
>> Only one I'm a bit iffy on is the closure; I'm trying to avoid declaring the 
>> captured variable externally, but I'm not convinced that having using on its 
>> own is clear enough?
>> 
>> Anyway, just an idea!
>> 
>> ___
>> 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] Ownership on protocol property requirements

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 8 May 2017, at 08:44, Xiaodi Wu  wrote:
> 
>> On Mon, May 8, 2017 at 2:40 AM, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> I can understand that, I am just wary of "let's do a partially detrimental 
>> change
> 
> The key here is that there is no detriment to this change. There's no 
> functionality that's being removed, only misleading syntax.

Why is it misleading? Because it is not enforced, but protocol extension 
default methods being shadowable but not overridable and presenting no warning 
is a very similar issue... if the answer is the same there (at least for 
classes), I am more than happy to get both changes ;).

>  
>> no... we will... we will make it proper someday" kind of changes as they 
>> seldom work out. Argument labels for stored closures and callbacks are still 
>> lost for example :/...
> 
> That's a totally different issue. Someone needs to write the proposal and 
> implementation for that. 

Would you and some other be willing to help me (Erica?)? A lot to ask, but it 
would be important although a bit beyond the scope for "dweller's first 
proposal" especially the implementation and grammar side. I do not think it has 
a iota of chance for it to get integrate in time though :/.

> 
>> Also, while here we keep pushing things Core Team's way, Ted K. is asking 
>> for devs' help on swift-dev as there is concern that the currently accepted 
>> proposals may not make it with this year's new Swift version (second year in 
>> a row). Should we discuss features in scope for Swift 4.1+ only now?
>> 
>> Sent from my iPhone
>> 
>>> On 8 May 2017, at 08:12, David Hart  wrote:
>>> 
>>> 
>>>> On 8 May 2017, at 09:03, Goffredo Marocchi  wrote:
>>>> 
>>>> Over my dead body --random list dweller ;)
>>>> 
>>>> Seriously though, I think the labels should be made to matter not removed 
>>>> if they do not matter now. I think this goes to a path where we should not 
>>>> take protocols as they should be true contracts for the API in question 
>>>> (default method in protocols make me think we have to write unit tests for 
>>>> a protocol which sounds mad... oh well) although some may argue the 
>>>> ownership info is implementation detail and on that point I may agree with 
>>>> you ;).
>>> 
>>> Agreed. But we don’t have the time to bring meaning to them in time for 
>>> Swift 4. Its better to make the language consistent now (disallowing a 
>>> keyword which currently has no meaning) and allow ourselves to reintroduce 
>>> later with correct semantics.
>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 8 May 2017, at 07:57, David Hart via swift-evolution 
>>>>>  wrote:
>>>>> 
>>>>> Sounds great! It should be an easy one to get through,
>>>>> 
>>>>>> On 8 May 2017, at 08:35, Greg Spiers  wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution 
>>>>>>  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On 7 May 2017, at 20:12, Xiaodi Wu via swift-evolution 
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> Today these keywords have no meaning inside a protocol, so clearly it 
>>>>>>>> should be an error to use it in that context. I agree with Jordan that 
>>>>>>>> the error should be on the protocol.
>>>>>>>> 
>>>>>>>> It's entirely a different conversation whether the keyword should have 
>>>>>>>> meaning or not. If it should, it seems to me it should be limited to 
>>>>>>>> protocols that are limited to classes. But that's an additive feature 
>>>>>>>> we can discuss later.
>>>>>>>> 
>>>>>>>> The source-breaking bug fix that is more pressing today is removing 
>>>>>>>> meaningless keywords that can be misleading to users, because they 
>>>>>>>> have no effect but look like they should.
>>>>>> Exactly the trap I fell into when I found this issue.
>>>>>>  
>>>>>>> 
>>>>>>> Yup, +1. Who wants to write a proposal?
>>>>>> 
>>>>>> I'd like to give it a try. I

Re: [swift-evolution] Ownership on protocol property requirements

[Goffredo Marocchi via swift-evolution]

I can understand that, I am just wary of "let's do a partially detrimental 
change no... we will... we will make it proper someday" kind of changes as they 
seldom work out. Argument labels for stored closures and callbacks are still 
lost for example :/...

Also, while here we keep pushing things Core Team's way, Ted K. is asking for 
devs' help on swift-dev as there is concern that the currently accepted 
proposals may not make it with this year's new Swift version (second year in a 
row). Should we discuss features in scope for Swift 4.1+ only now?

Sent from my iPhone

> On 8 May 2017, at 08:12, David Hart  wrote:
> 
> 
>> On 8 May 2017, at 09:03, Goffredo Marocchi  wrote:
>> 
>> Over my dead body --random list dweller ;)
>> 
>> Seriously though, I think the labels should be made to matter not removed if 
>> they do not matter now. I think this goes to a path where we should not take 
>> protocols as they should be true contracts for the API in question (default 
>> method in protocols make me think we have to write unit tests for a protocol 
>> which sounds mad... oh well) although some may argue the ownership info is 
>> implementation detail and on that point I may agree with you ;).
> 
> Agreed. But we don’t have the time to bring meaning to them in time for Swift 
> 4. Its better to make the language consistent now (disallowing a keyword 
> which currently has no meaning) and allow ourselves to reintroduce later with 
> correct semantics.
> 
>> Sent from my iPhone
>> 
>>> On 8 May 2017, at 07:57, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> Sounds great! It should be an easy one to get through,
>>> 
>>>> On 8 May 2017, at 08:35, Greg Spiers  wrote:
>>>> 
>>>> 
>>>> 
>>>> On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution 
>>>>  wrote:
>>>>> 
>>>>> 
>>>>>> On 7 May 2017, at 20:12, Xiaodi Wu via swift-evolution 
>>>>>>  wrote:
>>>>>> 
>>>>>> Today these keywords have no meaning inside a protocol, so clearly it 
>>>>>> should be an error to use it in that context. I agree with Jordan that 
>>>>>> the error should be on the protocol.
>>>>>> 
>>>>>> It's entirely a different conversation whether the keyword should have 
>>>>>> meaning or not. If it should, it seems to me it should be limited to 
>>>>>> protocols that are limited to classes. But that's an additive feature we 
>>>>>> can discuss later.
>>>>>> 
>>>>>> The source-breaking bug fix that is more pressing today is removing 
>>>>>> meaningless keywords that can be misleading to users, because they have 
>>>>>> no effect but look like they should.
>>>> Exactly the trap I fell into when I found this issue.
>>>>  
>>>>> 
>>>>> Yup, +1. Who wants to write a proposal?
>>>> 
>>>> I'd like to give it a try. I can write up the proposal to remove the 
>>>> keywords in protocols and will post a draft here for further discussion.
>>>>  
>>>>> 
>>>>>>> On Sun, May 7, 2017 at 11:00 Goffredo Marocchi via swift-evolution 
>>>>>>>  wrote:
>>>>>>> It would be useful to have a longer discussion on this as... I think 
>>>>>>> that weak has a place there and should be enforced as a protocol is the 
>>>>>>> public facing interface/api for the types who decide to adopt it.
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>> > On 7 May 2017, at 15:41, Adrian Zubarev via swift-evolution 
>>>>>>> >  wrote:
>>>>>>> >
>>>>>>> > browse
>>>>>>> ___
>>>>>>> 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] Ownership on protocol property requirements

[Goffredo Marocchi via swift-evolution]

Over my dead body --random list dweller ;)

Seriously though, I think the labels should be made to matter not removed if 
they do not matter now. I think this goes to a path where we should not take 
protocols as they should be true contracts for the API in question (default 
method in protocols make me think we have to write unit tests for a protocol 
which sounds mad... oh well) although some may argue the ownership info is 
implementation detail and on that point I may agree with you ;).

Sent from my iPhone

> On 8 May 2017, at 07:57, David Hart via swift-evolution 
>  wrote:
> 
> Sounds great! It should be an easy one to get through,
> 
>> On 8 May 2017, at 08:35, Greg Spiers  wrote:
>> 
>> 
>> 
>> On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution 
>>  wrote:
>>> 
>>> 
>>>> On 7 May 2017, at 20:12, Xiaodi Wu via swift-evolution 
>>>>  wrote:
>>>> 
>>>> Today these keywords have no meaning inside a protocol, so clearly it 
>>>> should be an error to use it in that context. I agree with Jordan that the 
>>>> error should be on the protocol.
>>>> 
>>>> It's entirely a different conversation whether the keyword should have 
>>>> meaning or not. If it should, it seems to me it should be limited to 
>>>> protocols that are limited to classes. But that's an additive feature we 
>>>> can discuss later.
>>>> 
>>>> The source-breaking bug fix that is more pressing today is removing 
>>>> meaningless keywords that can be misleading to users, because they have no 
>>>> effect but look like they should.
>> Exactly the trap I fell into when I found this issue.
>>  
>>> 
>>> Yup, +1. Who wants to write a proposal?
>> 
>> I'd like to give it a try. I can write up the proposal to remove the 
>> keywords in protocols and will post a draft here for further discussion.
>>  
>>> 
>>>>> On Sun, May 7, 2017 at 11:00 Goffredo Marocchi via swift-evolution 
>>>>>  wrote:
>>>>> It would be useful to have a longer discussion on this as... I think that 
>>>>> weak has a place there and should be enforced as a protocol is the public 
>>>>> facing interface/api for the types who decide to adopt it.
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> > On 7 May 2017, at 15:41, Adrian Zubarev via swift-evolution 
>>>>> >  wrote:
>>>>> >
>>>>> > browse
>>>>> ___
>>>>> 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] Ownership on protocol property requirements

[Goffredo Marocchi via swift-evolution]

It would be useful to have a longer discussion on this as... I think that weak 
has a place there and should be enforced as a protocol is the public facing 
interface/api for the types who decide to adopt it.

Sent from my iPhone

> On 7 May 2017, at 15:41, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> browse
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Goffredo Marocchi via swift-evolution]

That is weird indeed, there is need of more argument labels, like argument 
labels back in stored closures and callbacks, not even less argument labels all 
around :/.

-1 as a corner case of the language throws the baby out with the bathwater.

Sent from my iPhone

> On 5 May 2017, at 05:53, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Ah, I see from your proposed grammar update: you're proposing to prohibit the 
> use of labels entirely in a tuple pattern.
> 
> This is much more than just prohibiting tuple shuffling, and I'm rather 
> disappointed that you described such a dramatic change using a corner case. 
> There are very good reasons why someone finds 'let (y: x, x: y) = (x: 1, y: 
> 2)' confusing and would support its removal, but it is entirely another 
> ballgame to remove labels from tuple patterns altogether.
> 
> 
>> On Thu, May 4, 2017 at 23:47 Xiaodi Wu  wrote:
>> Now I'm confused. The ordinary meaning of the word "shuffle" is not changing 
>> but rather reordering, and all of your examples are of reordering.
>> 
>> To be clear, are you proposing the prohibition of *adding or removing* 
>> labels as well? A previous discussion on tuple shuffling on this list saw 
>> consensus that assigning a value of type (label1: T, label2: U) to a 
>> variable of type (T, U) and vice versa should absolutely be supported, 
>> whether or not reordering is permitted.
>> 
>> And how about *restating* existing labels without any adding or removing? To 
>> be clear:
>> 
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>> 
>> ...involves absolutely no changes in labels whatsoever. The return type is 
>> (partialValue: Int, overflow: ArithmeticOverflow).
>> 
>> Either one of these scenarios is commonly used, and it is astonishing to me 
>> that they would be eliminated.
>> 
>>> On Thu, May 4, 2017 at 23:28 Robert Widmann  
>>> wrote:
>>> That doesn't involve a parameter reordering, but because it changes 
>>> argument labels it's a shuffle.
>>> 
>>> ~Robert Widmann
>>> 
>>> 2017/05/05 0:16、Xiaodi Wu  のメッセージ:
>>> 
 Robert,
 
 As I mentioned on Twitter, getting rid of tuple shuffles would not cure 
 your example, which does not involve a shuffle. Unless you're proposing to 
 disallow the use of labels during destructuring entirely, which I would 
 think to be very much unacceptable. Example:
 
 ```
 let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
 ```
 
 This involves no shuffling and should absolutely remain allowed.
 
 
> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution 
>  wrote:
> Hi all,
> 
> So sorry that this proposal comes so late in the game, but I feel it’s 
> too important not to bring it to the attention of the community now.  
> Attached is a proposal to deprecate a language feature many of you will 
> probably have never had the chance to use: Tuple Shuffles.  I’ve attached 
> a copy of the first draft of the proposal below, but the latest copy can 
> be read on Github.
> 
> Thanks!
> 
> ~Robert Widmann
> 
> Deprecate Tuple Shuffles
> Proposal: SE-
> Authors: Robert Widmann
> Review Manager: TBD
> Status: Awaiting review
> Introduction
> 
> This proposal seeks the deprecation of a little-known feature of Swift 
> called a "Tuple Shuffle".
> 
> Motivation
> 
> A tuple-shuffle is an undocumented feature of Swift in which one can 
> re-order the indices of a tuple by writing a pattern that describes a 
> permutation in a syntax reminiscent of adding type-annotations to a 
> parameter list:
> 
> let a = (x: 1, y: 2)
> var b: (y: Int, x: Int)
> b = a
> It can be used to simultaneously destructure and reorder a tuple:
> 
> let tuple = (first: 0, second: (x: 1, y: 2))
> let (second: (x: b, y: c), first: a) = tuple
> It can also be used to map parameter labels out of order in a call 
> expression:
> 
> func foo(_ : (x : Int, y : Int)) {}
> foo((y: 5, x: 10)) // Valid
> Note that a tuple shuffle is distinct from a re-assignment through a 
> tuple pattern. For example, this series of statements will continue to 
> function as before:
> 
> var x = 5
> var y = 10
> var z = 15
> (z, y, x) = (x, z, y)
> Their inclusion in the language complicates every part of the compiler 
> stack, uses a syntax that can be confused for type annotations, 
> contradicts the goals of earlier SE's (see SE-0060), and makes 
> non-sensical patterns possible in surprising places.
> 
> Take switch-statements, for example:
> 
> switch ((0, 0), 0){ 
> case (_ : let (y, z), _ : let s): () // We are forbidden from giving 
> these patterns names other than "_" 
> default: () 
> }
> This proposal seeks to deprecate them in Swift 3 compatibility mode and 
>>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 May 2017, at 02:05, Howard Lovatt via swift-evolution 
>  wrote:
> 
> My experience with languages that have generalised existential is that they 
> are superior in many circumstances; not just for collections, e.g. I gave the 
> example of the comparison protocol. 

I think generalised existential is where we want to get to, is it not?

> I don't think methods called on a returned generalised existential have to be 
> called via a Vtable. If the return type is Self then the compiler can 
> eliminate the Vtable for selfs that are value types. For selfs that are 
> classes it would still have to use a Vtable though, because classes always 
> use Vtables! In most cases the return type will be Self and in most cases 
> the Self will be a value type, so I would argue that in most cases a Vtable 
> won't be used. 
> 
> -- Howard.
> 
>> On 2 May 2017, at 8:57 pm, Anders Ha  wrote:
>> 
>> I would like to add that generalized existential is not really a better 
>> solution than letting the collection optionally and statically supply one. 
>> It consequentially forces all calls to the filtered collections 
>> virtual/dynamic.
>> 
>> Higher kinded type would ideally help, but we all know it is not coming 
>> anytime soon, or perhaps ever. 
>> 
>> Regards
>> Anders
>> 
>>> On 2 May 2017, at 08:41, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Howard, this is also mentioned in the generics manifesto under "Opening 
>>> existentials," and it's received plentiful discussion and will surely 
>>> receive more as these issues become addressed in future proposals. Let's 
>>> not divert the conversation here about map and filter.
 On Mon, May 1, 2017 at 19:36 Howard Lovatt  wrote:
 Yes, I know the change I suggested involves making generalised 
 existentials. I am suggesting not making *any* changes until such effort 
 is available. I understand that this would be after Swift 4. I think the 
 wait would be worthwhile.
 
 As an aside: Currently one of the big issues with generalised existentials 
 in Swift is with Self (which you can think of as a form of generic 
 argument). Currently:
 
 protocol Equatable {
 static func ==(lhs: Self, rhs: Self) -> Bool
 ...
 }
 struct Int: Equatable { ... }
 let e1: Equatable = 1
 let e2: Equatable = 2
 if e1 == e2 { ... } // error: e1 and e2 don't necessarily have the 
 same dynamic type
 
 I would replace this with:
 
 protocol Equatable { // Use T instead of Self
 static func ==(lhs: T, rhs: T) -> Bool
 ...
 }
 struct Int: Equatable { ... }
 let e1: Equatable = 1
 let e2: Equatable = 2
 if e1 == e2 { ... } // No longer an error since they are both 
 Equatable
 
 As an aside on the aside, even better:
 
 protocol Equatable { // T defaults to Self
 static func ==(lhs: T, rhs: T) -> Bool
 ...
 }
 struct Int: Equatable { ... } // T is Int, the default is Self
 let e1: Equatable = 1  // T is Int, the default is Self
 let e2: Equatable = 2 // T is Int, the default is Self
 if e1 == e2 { ... } // No longer an error since they are both 
 Equatable
 
 Everything I am suggesting is done in other languages and from my personal 
 experience works out better.
 
 
   -- Howard.
 
> On 2 May 2017 at 09:53, Xiaodi Wu  wrote:
> Howard, take a look at the generics manifesto section on generic 
> protocols:
> 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
> 
> It explains very nicely how what you're really asking for is not generic 
> protocols but generalized existentials. This would be nice to have, but 
> it's clearly not happening within the next month and it wouldn't change 
> the solution for filter, for which this proposal is the obvious fix.
> 
> On Mon, May 1, 2017 at 18:09 Howard Lovatt via swift-evolution 
>  wrote:
>>> review of SE-0174 "Change `filter` to return an associated type" 
>>> 
>> 
>>> What is your evaluation of the proposal?
>> I think a change in this 'area' is valuable because currently always 
>> returning an array from collection operations is limiting. However I 
>> think this proposal feels like 'papering' over problems rather than 
>> fixing the root cause. I think it would be better to reject this and do 
>> two more adventurous proposals instead:
>> 
>>   1. Allow protocols to be generic, instead of associated types, so that 
>> you can write Sequence
>>   2. Allow Self to accept a generic argument, so that you can write 
>> Self
>> 
>> With these to, admittedly much more major changes, you can then write:
>> 
>> protocol Sequence {
>> func filter(_ isIncluded: (

Re: [swift-evolution] [pitch] Comparison Reform

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 28 Apr 2017, at 01:51, Jonathan Hull via swift-evolution 
>  wrote:
> 
> To be clear, the big downside is the current lack of hardware support. There 
> are apparently some chips in the pipeline, but nothing for Apple platforms 
> that I know of.

Synergy between HW and SW... fully custom ARMv8 cores... wink wink... nudge 
nudge ;). Maybe if they become super important for Swift there is an economic 
advantage for their own chips to push for them (Desktop and MacBook are more of 
an issue and depend on a whole other set of factors to happen).

> We are likely to see them first in GPUs and neural network processors (since 
> they allow effective neural networks using only 8-bit values, and the binary 
> representation dramatically simplifies some standard neural network 
> calculations). Most language implementations currently use a backing Int as 
> storage.
> 
> That said, I think it is still a worthwhile pursuit, especially for those of 
> us interested in accurate numerical calculations.  According to the author, 
> they should also be able to be used interchangeably with Floats in any 
> generic algorithm, though the results would differ (because of the increased 
> accuracy/range).  I am still reading to find the details.
> 
> If we are interested, I think the first step would be making a third party 
> library...
> 
> Thanks,
> Jon
> 
> 
>> On Apr 27, 2017, at 4:35 PM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> There have been a bunch of updates since then (currently under peer review), 
>> which deal with implementation on current systems.  Reading the new/updated 
>> paper now…
>> 
>> Here is a video of the author speaking about some of the general ideas:
>> https://www.youtube.com/watch?v=aP0Y1uAA-2Y
>> 
>> I doubt we would get rid of Double/Float, but I would love to see it used as 
>> a core type in Swift 5.  In addition to the increase in accuracy/expressible 
>> range, and the simplification of exception handling, apparently the results 
>> when used in neural networks are amazing.  It also allows you to simplify a 
>> bunch of numerical algorithms, because you don’t have to worry about some of 
>> the things that go wrong with traditional floats/doubles.
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Apr 27, 2017, at 2:35 PM, Matthew Johnson  wrote:
>>> 
>>> I mentioned unums on the list about a year ago.  Steve Canon replied with 
>>> some thoughts: 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016889.html.
>>> 
 On Apr 27, 2017, at 4:26 PM, Jonathan Hull via swift-evolution 
  wrote:
 
 I have read it, and it is a truly brilliant work.  I would love to see 
 some (or all) of it make it into Swift (most likely Swift 5 or 6).  The 
 author is related to a friend of mine, so I can see if he is available to 
 answer questions if there is interest...
 
 
> On Apr 27, 2017, at 5:14 AM, Björn Forster via swift-evolution 
>  wrote:
> 
> Hi all together, 
> I was just looking quickly over an article from Wolfram which covers new 
> books covering Mathematica and tripped over this book:
> 
> https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/p/book/9781482239867
> 
> 
> From the reviews:
> "This book is an extraordinary reinvention of computer arithmetic and 
> elementary numerical methods from the ground up. Unum arithmetic is an 
> extension of floating point in which it is also possible to represent the 
> open intervals between two floating point numbers. This leads to 
> arithmetic that is algebraically much cleaner, without rounding error, 
> overflow underflow, or negative zero, and with clean and consistent 
> treatment of positive and negative infinity and NaN. These changes are 
> not just marginal technical improvements. As the book fully demonstrates, 
> they lead to what can only be described as a radical re-foundation of 
> elementary numerical analysis, with new methods that are free of rounding 
> error, fully parallelizable, fully portable, easier for programmers to 
> master, and often more economical of memory, bandwidth, and power than 
> comparable floating point methods. The book is exceptionally well written 
> and produced and is illustrated on every page with full-color diagrams 
> that perfectly communicate the material. Anyone interested in computer 
> arithmetic or numerical methods must read this book. It is surely 
> destined to be a classic."
> —David Jefferson, Center for Advanced Scientific Computing, Lawrence 
> Livermore National Laboratory 
> 
> I haven't read it myself, as said I stepped just over it, but *MAYBE* it 
> covers the NaN problem in depth and the current state of art how to deal 
> with it. 
> Maybe someone has free access to an online library (maybe via some 
> university enrollment) and can have a look

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

[Goffredo Marocchi via swift-evolution]

Hello Itai,

Sorry for the confusion, but I understood that the following

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

meant it would actually hinder that kind of transformation or make it more 
difficult to write custom decoders and encoders. Sorry if I misunderstood that.

One follow up question: what would happen if inside the JSON mock object you 
posted I were to remove the 'address' key (in terms of the produced object and 
how to access its inner properties)? 

What would happen if I remove the 'name' one or better if I add another key to 
the JSON object?

Sent from my iPhone

> On 26 Apr 2017, at 21:28, Itai Ferber  wrote:
> 
> Hi Goffredo,
> 
> Unless I'm misunderstanding what you mean here, this is exactly what we're 
> proposing with the API — anything Encodable can encode any type that is 
> Encodable as a nested value:
> 
> struct Person : Codable {
> let name: String
> let address: Address
> }
> 
> struct Address : Codable {
> let street: String
> let city: String
> let state: String
> let zipCode: Int
> let country: String
> }
> 
> let address = Address(street: "1 Infinite Loop", city: "Cupertino", state: 
> "CA", zipCode: 95014, country: "United States")
> let person = Person(name: "John Doe", address: address)
> 
> let encoder = JSONEncoder()
> let payload = try encoder.encode(person)
> print(String(data: payload, encoding: .utf8)!) // => {"name": "John Doe", 
> address: {"street": "1 Infinite Loop", ... } }
> 
> let decoder = JSONDecoder()
> let decoded = try decoder.decode(Person.self, from: payload) // => 
> Person(name: "John Doe", address: ...)
> Or have I misunderstood you?
> 
> — Itai
> 
> On 26 Apr 2017, at 13:11, Goffredo Marocchi via swift-evolution wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On 26 Apr 2017, at 17:24, Tony Parker via swift-evolution 
>>  wrote:
>> 
>> Hi Riley,
>> 
>>> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution 
>>>  wrote:
>>> 
>>> I’m sure this has already been discussed, but why are the methods throwing 
>>> NSErrors and not Enums? If I’m remembering correctly, the original reason 
>>> for this was because this was meant to be a part of Foundation. Now that 
>>> this is in the Standard Library, however, it seems strange that we’re still 
>>> using NSError.
>>> 
>>> Second question that again I’m sure was asked and answered already, but: 
>>> why do we require implementations for each concrete numeric type (Int, 
>>> Int8, Int16, Float, etc), instead of using protocols (such as the new 
>>> Integer protocols)?
>> 
>> To answer your second question, the reason is that using the protocol 
>> implies that all encoders and decoders must support anything that conforms 
>> to that protocol.
> 
> Would this make it easier to transform nested JSON into a nested 
> object/struct? If so it could be useful, very useful.
> 
>> We’re not sure this is a reasonable requirement. Many formats do not have 
>> any kind of support for arbitrary size integers, for example. Therefore, we 
>> felt it was best to limit it to a set of concrete types.
>> 
> 
> I honk we would be missing a trick, unless I am missing something here, that 
> was very powerful in libraries like Mantle for iOS: the ability to translate 
> a nested JSON object (some keys in the JSON object having a JSON object as 
> value, etc...) in an MTLModel subclass composed of other MTLModel subclasses 
> where doing the transformation of the root object would call the right model 
> needed to transform for the child JSON objects.
> Working with Mantle is safe, rugged (it does not cause crashes if the JSON 
> file changes), and allows you to break the problem into chunks and present a 
> coherent simple view to the code that makes use of the instance you created 
> out of the JSON input. Reference: 
> https://github.com/Mantle/Mantle/blob/master/README.md
> 
> 
>> We could change our minds on this before we ship Swift 4, if we feel it was 
>> the wrong decision. Now that the proposals are accepted we will be landing 
>> these branches in master soon, which means everyone has a great chance to 
>

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

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

Would this make it easier to transform nested JSON into a nested object/struct? 
If so it could be useful, very useful.

> We’re not sure this is a reasonable requirement. Many formats do not have any 
> kind of support for arbitrary size integers, for example. Therefore, we felt 
> it was best to limit it to a set of concrete types.
> 

I honk we would be missing a trick, unless I am missing something here, that 
was very powerful in libraries like Mantle for iOS: the ability to translate a 
nested JSON object (some keys in the JSON object having a JSON object as value, 
etc...) in an MTLModel subclass composed of other MTLModel subclasses where 
doing the transformation of the root object would call the right model needed 
to transform for the child JSON objects.
Working with Mantle is safe, rugged (it does not cause crashes if the JSON file 
changes), and allows you to break the problem into chunks and present a 
coherent simple view to the code that makes use of the instance you created out 
of the JSON input. Reference: 
https://github.com/Mantle/Mantle/blob/master/README.md


> We could change our minds on this before we ship Swift 4, if we feel it was 
> the wrong decision. Now that the proposals are accepted we will be landing 
> these branches in master soon, which means everyone has a great chance to try 
> it out and see how it feels in real world usage before it’s final.
> 
> - Tony
> 
>> 
>>> On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Proposal Link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>> 
>>> Hello Swift Community,
>>> 
>>> The review of SE-0166 “Swift Archival & Serialization” ran from April 
>>> 6...12, 2017. The proposal is accepted with some minor modifications. 
>>> Specifically, the core protocols and types will be sunk down into the Swift 
>>> standard library for more tight integration with the Swift language and 
>>> compiler, and the operations specifically involving Foundation’s “Data” 
>>> type will be removed. The proposal document has been updated with more 
>>> detail. Thank you everyone for participating in this review!
>>> 
>>> - Doug
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Comparison Reform

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 23 Apr 2017, at 05:58, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Apr 22, 2017, at 6:06 PM, Xiaodi Wu  wrote:
>> but my quick reaction to `&==` is that it would make me quite nervous to 
>> have `==` not bound to 754-equals as it is in essentially every other 
>> language. In particular, I worry about the risk of people porting numerical 
>> code that depends on isnan(x) <—> !(x < y) in non-obvious ways that they are 
>> unlikely to test. I’ll try to follow up with more detailed thoughts tomorrow.
>> 
>> Indeed, it makes me a little nervous too. That said, `==` being either bound 
>> or not bound to 754 depending on the context is what makes me even more 
>> nervous.
>> 
>> I was once adamantly against a new spelling for `==`, but on reconsideration 
>> it's clear to me that few if any numerical recipes can be ported verbatim 
>> from C-like languages and we should probably not encourage people to do so. 
>> Already, `+` needs to be rewritten as `&+`, `<<` probably should be 
>> rewritten as `&<<` (I still haven't had enough time to think about this), 
>> and the bitwise operators have differing precedences that require careful 
>> proofreading.
> 
> 
> I haven’t been following this proposal or discussion closely, but it seems to 
> me that there are a few workable approaches with different tradeoffs:
> 
> 1. The strictly correct but user hostile approach:
> 
> * == and != are tied to the Equatable protocol, which is essentially the == 
> operation.
> * <, <=, >, >= are tied to the Comparable protocol, which is essentially the 
> <=> operation.
> * Hashable doesn’t require equatable, it requires a related StrictlyEquatable 
> protocol.
> * StrictlyEquatable refines Equatable (with no other requirements, it is just 
> a marker protocol), in which case FP types can’t conform to it, and thus 
> can’t participate as dictionary keys
> 
> => This approach sucks because you can’t have Set, or 
> Dictionary.
> 
> 2. The strictly correct but somewhat user hostile approach:
> 
> * == and != are tied to the Equatable protocol, which is essentially the == 
> operation.
> * <, <=, >, >= are tied to the Comparable protocol, which is essentially the 
> <=> operation.
> * Hashable doesn’t require equatable, it requires a related StrictlyEquatable 
> protocol.
> * StrictlyEquatable doesn’t refine Equatable: it has a different requirement, 
> and FP types can therefore implement both Equatable and StrictlyEquatable.
> 
> => This approach is suboptimal because implementing your own type requires 
> you to implement the <=> operation, as well as the StrictlyEquatable 
> protocol, both.
> 
> 3. The user friendly but incorrect model:
> 
> * == and != are tied to the Equatable protocol, which is essentially the == 
> operation.
> * <, <=, >, >= are tied to the Comparable protocol, which is essentially the 
> <=> operation.
> * Hashable is defined in terms of Equatable.
> 
> => This is easy (types just have to define <=>), but fails for FP types.
> 
> 
> I don’t think that this proposal is acceptable as written.  I think it is 
> really bad that abstracting a concrete algorithm would change its behavior so 
> substantially.  

Agreed, it seems a bit more like changing behaviour and adding side effects in 
order to allow a generic abstraction instead of the generic abstraction 
servicing the user and language needs and improving the status quo.

> I don’t care about SNaNs, but I do care about the difference between +0/-1 
> and secondarily that of NaN handling.  It seems really bad that generalizing 
> something like:
> 
> func doThing(a : Double, b : Double) -> Bool {
>   ….
>   return a != b
> }
> 
> to:
> 
> func doThing (a : T, b : T) -> Bool {
>   ….
>   return a != b
> }
> 
> would change behavior (e.g. when a is -0.0 and b is +0.0).   Likewise, "T : 
> Equatable".
> 
> -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] [Accepted] SE-0155: Normalize Enum Case Representation

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 20 Apr 2017, at 23:15, John McCall  wrote:
> 
> 
>> On Apr 20, 2017, at 5:50 PM, Goffredo Marocchi  wrote:
>> 
>> One thing I wanted to point out and that was a non trivial issue last year 
>> and that the core team did discuss and agreed to revisit (if I remember the 
>> thread update by Chris Lattner last year):
>> 
>> 
>>> Note that since the labels aren't part of a tuple, they no longer 
>>> participate in type checking, behaving consistently with functions.
>>> 
>>> let f = Expr.elet // f has type ([(String, Expr)], Expr) -> Expr f([], 
>>> anExpr) // Okay! f(locals: [], body: anExpr) // Won't compile.
>> I appreciate effort for consistency, but I hope this is not going to be used 
>> against the effort to bring labels in functions/stored closures/callbacks.
> 
> It will not.  The issues are unrelated.  Whatever rules we use for supporting 
> argument labels on indirect calls to functions will also apply to indirect 
> calls to enum case constructors.
> 

Thanks for your reply :).

> John.
> 
>> Swift, as we discussed last year, made a conscious, intentional effort to 
>> double down on the self documentation and call site readability of argument 
>> labels in general and the status quo after Swift 3/3.1 is not reflecting 
>> that whenever functions are stored in variables and/or passed to other 
>> functions as arguments.
>> 
>> I would like not to miss the Swift 4.0 deadline for this and we should 
>> discuss it sooner rather than later. I brought this up here because, for 
>> consistency, we are doubling down on something we should really be 
>> discussing to improve in my opinion.
> 
>> 
>> Sent from my iPhone
>> 
>>> On 20 Apr 2017, at 21:39, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution 
  wrote:
 Proposal Link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
 
 Hello Swift Community,
 
 The review of SE-0155 "Normalize Enum Case Representation” ran from March 
 31st through April 10th, 2017. The proposal is accepted with revisions.
 
 Feedback from the community was positive about most aspects of the 
 proposal.  However, there was substantial disagreement about the right 
 direction for pattern matching.  The core team discussed this issue in 
 depth.
 
 Pattern matching is central to the use of enum types.  It's the only way 
 you can use an enum value, besides general operations like passing it to a 
 function or the special affordances for Optionals.  Pattern matching is as 
 central to enums as stored property access is to structs, and it's fair to 
 be worried about anything that would make it substantially more onerous.  
 Unconditionally requiring associated-value labels in case patterns would 
 certainly do that, and several members of the core team expressed concern 
 that it would be bad enough to discourage the use of associated-value 
 labels completely — in effect, subverting the entire language feature 
 being proposed.
 
 It is true that including associated-value labels in case patterns does 
 preserve a great deal of information in the source code:
 
   - This information can usefully contribute to the clarity of the code 
 following the pattern.
 
   - Hiding this information can lead to bugs that would be self-evident if 
 the case labels were always included.  For example, if a case payload 
 included a number of different boolean flags, it would be easy for a 
 pattern to accidentally label them in the wrong order.
 
   - Finally, this information may be necessary in order to determine which 
 case is being matched, since the proposal adds the ability to distinguish 
 cases purely by the labels on associated values.
 
 However, the core team feels that there are counter-arguments which weaken 
 the force of these considerations:
 
   - While an associated-value label can indeed contribute to the 
 readability of the pattern, the programmer can also choose a meaningful 
 name to bind to the associated value.  This binding name can convey at 
 least as much information as a label would.
 
   - The risk of mis-labelling an associated value grows as the number of 
 associated values grows.  However, very few cases carry a large number of 
 associated values.  As the amount of information which the case should 
 carry grows, it becomes more and more interesting to encapsulate that 
 information in its own struct — among other reasons, to avoid the need to 
 revise every matching case-pattern in the program.  Furthermore, when a 
 case does carry a significant number of associated values, there is often 
 a positional conventional between them that lowers the risk of 
 re-ordering: for example, the 

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

[Goffredo Marocchi via swift-evolution]

One thing I wanted to point out and that was a non trivial issue last year and 
that the core team did discuss and agreed to revisit (if I remember the thread 
update by Chris Lattner last year):

> Note that since the labels aren't part of a tuple, they no longer participate 
> in type checking, behaving consistently with functions.
> 
> let f = Expr.elet // f has type ([(String, Expr)], Expr) -> Expr f([], 
> anExpr) // Okay! f(locals: [], body: anExpr) // Won't compile.
I appreciate effort for consistency, but I hope this is not going to be used 
against the effort to bring labels in functions/stored closures/callbacks.

Swift, as we discussed last year, made a conscious, intentional effort to 
double down on the self documentation and call site readability of argument 
labels in general and the status quo after Swift 3/3.1 is not reflecting that 
whenever functions are stored in variables and/or passed to other functions as 
arguments.

I would like not to miss the Swift 4.0 deadline for this and we should discuss 
it sooner rather than later. I brought this up here because, for consistency, 
we are doubling down on something we should really be discussing to improve in 
my opinion.

Sent from my iPhone

> On 20 Apr 2017, at 21:39, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution 
>>  wrote:
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0155 "Normalize Enum Case Representation” ran from March 
>> 31st through April 10th, 2017. The proposal is accepted with revisions.
>> 
>> Feedback from the community was positive about most aspects of the proposal. 
>>  However, there was substantial disagreement about the right direction for 
>> pattern matching.  The core team discussed this issue in depth.
>> 
>> Pattern matching is central to the use of enum types.  It's the only way you 
>> can use an enum value, besides general operations like passing it to a 
>> function or the special affordances for Optionals.  Pattern matching is as 
>> central to enums as stored property access is to structs, and it's fair to 
>> be worried about anything that would make it substantially more onerous.  
>> Unconditionally requiring associated-value labels in case patterns would 
>> certainly do that, and several members of the core team expressed concern 
>> that it would be bad enough to discourage the use of associated-value labels 
>> completely — in effect, subverting the entire language feature being 
>> proposed.
>> 
>> It is true that including associated-value labels in case patterns does 
>> preserve a great deal of information in the source code:
>> 
>>   - This information can usefully contribute to the clarity of the code 
>> following the pattern.
>> 
>>   - Hiding this information can lead to bugs that would be self-evident if 
>> the case labels were always included.  For example, if a case payload 
>> included a number of different boolean flags, it would be easy for a pattern 
>> to accidentally label them in the wrong order.
>> 
>>   - Finally, this information may be necessary in order to determine which 
>> case is being matched, since the proposal adds the ability to distinguish 
>> cases purely by the labels on associated values.
>> 
>> However, the core team feels that there are counter-arguments which weaken 
>> the force of these considerations:
>> 
>>   - While an associated-value label can indeed contribute to the readability 
>> of the pattern, the programmer can also choose a meaningful name to bind to 
>> the associated value.  This binding name can convey at least as much 
>> information as a label would.
>> 
>>   - The risk of mis-labelling an associated value grows as the number of 
>> associated values grows.  However, very few cases carry a large number of 
>> associated values.  As the amount of information which the case should carry 
>> grows, it becomes more and more interesting to encapsulate that information 
>> in its own struct — among other reasons, to avoid the need to revise every 
>> matching case-pattern in the program.  Furthermore, when a case does carry a 
>> significant number of associated values, there is often a positional 
>> conventional between them that lowers the risk of re-ordering: for example, 
>> the conventional left-then-right ordering of a binary search tree.  
>> Therefore this risk is somewhat over-stated, and of course the programmer 
>> should remain free to include labels for cases where they feel the risk is 
>> significant.
>> 
>>   - It is likely that cases will continue to be predominantly distinguished 
>> by their base name alone.  Methods are often distinguished by argument 
>> labels because the base name identifies an entire class of operation with 
>> many possible variants.  In contrast, each case of an enum is a kind of 
>> data, and its name is 

Re: [swift-evolution] [pitch] Comparison Reform

[Goffredo Marocchi via swift-evolution]

Ok, if you can name and shame the inventor of the CGFloat type ;)

Sent from my iPhone

> On 18 Apr 2017, at 17:58, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Apr 18, 2017, at 9:47 AM, Gwendal Roué  wrote:
>> 
>> 
>>> Le 18 avr. 2017 à 17:40, Joe Groff  a écrit :
>>> 
>>> 
> On Apr 18, 2017, at 1:34 AM, Gwendal Roué  wrote:
> 
> 
>> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution 
>>  a écrit :
>> 
>> 
>> On Apr 17, 2017, at 9:40 PM, Chris Lattner  wrote:
>> 
>> 
>>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 For example, I expect `XCTAssertEqual(_:_:)` to be 
 vended as part of XCTest, in order to make sure that 
 `XCTAssertEqual(resultOfComputation, Double.nan)` always fails.
>>> 
>>> Unit tests strike me as an example of where you really *don't* want 
>>> level 1 comparison semantics. If I'm testing the output of an FP 
>>> operation, I want to be able to test that it produces nan when I expect 
>>> it to, or that it produces the right zero.
>> 
>> I find it very concerning that == will have different results based on 
>> concrete vs generic type parameters.  This can only lead to significant 
>> confusion down the road.  I’m highly concerned about situations where 
>> taking a concrete algorithm and generalizing it (with generics) will 
>> change its behavior.
> 
> In this case, I think we're making == do exactly what you want it to do 
> based on context. If you're working concretely with floats, then you get 
> floating-point behavior like you'd expect. If you're working with 
> generically Equatable/Comparable things, then you're expecting the 
> abstract guarantees of interchangeability and total ordering that 
> implies, and you don't want to have to think about the edge cases of 
> weird types that violate those constraints. I also doubt that this will 
> cause problems in practice.
 
 "then you're expecting the abstract guarantees of interchangeability and 
 total ordering that implies"
 
 Joe, please: I'm very glad that you are expert in so many subject - I'd 
 love to have your job - but please keep track of average joes that have to 
 scratch their heads whenever they have to deal with nans and infinites and 
 subnormals and all those weird floating beasts. They already scratch their 
 heads with the idiosyncrasies of Swift protocols.
 
 Please keep equality simple.
>>> 
>>> I would argue that keeping equality simple is exactly what this proposal 
>>> achieves, since you *don't* need to worry about nans or positive/negative 
>>> zero or other floating-point strangeness every place you use == abstractly. 
>>> You have to opt in to the idiosyncratic behavior by working concretely with 
>>> floats.
>> 
>> Cool, a brand new Swift chapter added to "What Every Computer Scientist 
>> Should Know About Floating-Point Arithmetic" :-)
> 
> IMO, it will be a victory if the Swift edition can be titled "What Every 
> Computer Scientist *Who Uses Floats* Should Know About Them", and everyone 
> else who doesn't think about floating-point every day can sleep easy at night 
> without Kahan's ghost hiding under their bed.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Fwd: [Review] SE-0172: One-sided Ranges

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

Begin forwarded message:

> From: Goffredo Marocchi 
> Date: 18 April 2017 at 07:33:54 BST
> To: Douglas Gregor 
> Subject: Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
> 
> +1 seems like a slam dunk of a proposal. Far superior to the method syntax 
> option and not unnecessarily verbose.
> 
> Sent from my iPhone
> 
>> On 18 Apr 2017, at 05:40, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0172 "One-sided Ranges" begins now and runs through April 
>> 23, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution 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-0169: Improve Interaction Between private Declarations and Extensions

[Goffredo Marocchi via swift-evolution]

+1

Sent from my iPhone

> On 13 Apr 2017, at 08:15, Tino Heth via swift-evolution 
>  wrote:
> 
>> No change
>> Benefit: No change to the language.
>> Drawback: Must use “fileprivate” to build up a type through extensions.
>> 
>> SE–0159
>> Benefit: Simplifies the access control model.
>> Drawback: Cannot protect invariants within a file.
>> 
>> SE–0169
>> Benefit: Cross-type sharing is clearly marked.
>> Drawback: Must use a helper type to protect invariants within a file.
>> 
>> Rename
>> Benefit: No change to semantics.
>> Drawback: Two separate keywords are changed.
> 
> 
> As the dedicated thread was highjacked ;-), imho it's just fair to add 
> another option here...
> 
> Nested extensions
> Benefit: Expressive power, no breaking change (and more…)
> Drawback: More indentation
> 
> The table is quite boring:
> Nested Extensions
> Simple file   private
> Extensionsprivate
> Sharing   private
> Helper visibleprivate
> Helper hidden private
> Invariantsprivate
> Multi-typeprivate
> Multi-type + ext  private
> 
> I'm not sure about the colour, but if I wasn't to lazy to edit raw HTML, imho 
> there would a lot of green ;-)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 12 Apr 2017, at 01:18, Jakub Suder via swift-evolution 
>  wrote:
> 
> I'm honestly having trouble believing that this is being seriously 
> proposed... I always saw type inference as one of the most important 
> advantages of Swift over some older languages, the Swift ebook mentions many 
> times how smart Swift is that it can infer types for you so that you don't 
> have to type too much boilerplate.

I think Swift and its compiler have. A lot of other strong points beyond type 
inference and emphasis on static typing too, but type inference has a very very 
real cost and sooner or later the language and its community will have to deal 
with compile times that are a lot slower (some people were reporting about 2+ 
times slower) than a similar project in Objective-C... that is a very real 
productivity cost.

> And here we're talking about removing this feature that was advertised from 
> the beginning as Swift's strong point, in order to make the compilation 
> faster? The compiler speeds will be improved, the syntax will stay with us.
> 
> Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: 
> Bool = true". But that's my choice, not something I should be forced to do. 
> It's something to put in style guides, not to enforce with the compiler.
> 
> 
>> On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution 
>>  wrote:
>> I agree with the sentiment of the proposal, it does add value to overall 
>> efficiency of swift and make things simpler for the swift team, but as 
>> Matthew said a blanket ban will add noise to the code. Also this particular 
>> feature is one of those niceties about swift which makes it very welcoming 
>> to new adopters.
>> 
>> If some middle ground can be proposed to this problem then I think we will 
>> be making a lot of people happy.
>> 
>>> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution 
>>> >  wrote:
>>> >
>>> > Hi all,
>>> >
>>> > In a discussion about inferring parameter types from default value, Slava 
>>> > brought up some performance problems caused by type inference for stored 
>>> > properties in side types:
>>> >
>>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>> >
>>> > Towards the end, the post mentioned that some Swift team members 
>>> > contemplated requiring types for stored properties in type declarations. 
>>> > I think this idea deserves some more attention. Hence this last minute 
>>> > idea-floating.
>>> >
>>> > In addition to solving a performance headache in implementation, there're 
>>> > always the general benefit of making type declartion more explicit and 
>>> > readable (clarity for reader should out-weigh pleasure of the author). 
>>> > Making the
>>> > language slightly more consistent (we are not inferring types for default 
>>> > parameter values in function anyways).
>>> >
>>> > The cons for doing this are obvious too: the inference makes the language 
>>> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
>>> > would be a source breaking change.
>>> >
>>> > Just thought I'd float the idea to gather some quick reaction. What do 
>>> > y'all think?
>>> 
>>> I’m willing to keep an open mind on this topic but I don’t think wholesale 
>>> banning of inference is the right thing to do.  Here is an example of a 
>>> case where I do not want to give up inference.  When a property is 
>>> initialized inline by calling an initializer of a non-generic type (very 
>>> common) any annotation is strictly redundant.
>>> 
>>> struct {
>>> let foo = Foo()
>>> }
>>> 
>>> Requiring a type annotation here feels very unnecessary and boilerplate-y.  
>>> I adds no additional clarity to a reader of the code, only noise.  Noise 
>>> reduces clarity.  Small amounts of unnecessary or redundant information 
>>> such as in an individual stored property declaration are not that big a 
>>> deal.  But on balance they add up quickly and have an undesirable impact on 
>>> the overall clarity of code.
>>> 
>>> >
>>> > Daniel Duan
>>> > ___
>>> > 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
>> 
>> 
>> 
>> -- 
>> Pranshu Goyal
>> iOS Developer
>> tlkn
>> 
>> ___
>> 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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

We currently pay a dear cost in compilation time for all the features Swift 
brings and this in itself harm productivity quite a bit, the gulf between Swift 
and Objective-C projects compile time wise is massive and right nowt seems like 
we are ignoring it sometimes. Type inference can be a non trivial component of 
that and while it is a wow factor feature initially, it has never been clear as 
a practical big win when code being self documenting and easy to debug and 
maintain is concerned... 

Sent from my iPhone

> On 11 Apr 2017, at 00:26, David Beck via swift-evolution 
>  wrote:
> 
> This seems like something a linter should handle.
> 
> > Hi all,
> > 
> > In a discussion about inferring parameter types from default value, Slava 
> > brought up some performance problems caused by type inference for stored 
> > properties in side types:
> > 
> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> > 
> > Towards the end, the post mentioned that some Swift team members 
> > contemplated requiring types for stored properties in type declarations. I 
> > think this idea deserves some more attention. Hence this last minute 
> > idea-floating.
> > 
> > In addition to solving a performance headache in implementation, there're 
> > always the general benefit of making type declartion more explicit and 
> > readable (clarity for reader should out-weigh pleasure of the author). 
> > Making the
> > language slightly more consistent (we are not inferring types for default 
> > parameter values in function anyways).
> > 
> > The cons for doing this are obvious too: the inference makes the language 
> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
> > would be a source breaking change.
> > 
> > Just thought I'd float the idea to gather some quick reaction. What do 
> > y'all think?
> > 
> > Daniel Duan
> > 
> > 
> >  
> 
> 
> David Beck
> http://davidbeck.co
> http://twitter.com/davbeck
> http://facebook.com/davbeck
> 
> ___
> 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-0169

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution 
>  wrote:
> 
> All -
> 
> I am not in favor of this change.  While I agree that the implementation of 
> fileprivate and open as well as the changes to private had some unintended 
> by-products, they can easily be accommodated.  Sometimes the language by its 
> nature dictates style.  I say at this point, we all just need to deal with it 
> and move on.  We have bigger and more impactful language features to fry.  
> 
> IMHO the changes in this proposal create a host of complications in the 
> understanding of what can already be a hard to understand topic.  We are 
> greatly increasing the surface area of what must be learned in order to 
> completely grok private and fileprivate.

The goal of progressive disclosure is NOT to reduce the amount of learning you 
need to get COMPLETE understanding of a topic like access control, but being 
able to get started easily with a small subset of info and go deeper if you 
need it and on your terms which this proposal achieves.

>  This added complexity does not justify what I feel are just cosmetic 
> improvements to suit a particular coding style.  
> 
> Changes such as this to suit a particular coding style, need to be avoided or 
> we risk losing focus on the definition and implementation of more critical 
> changes.
> 
> I don’t comment on many proposals, but this one stood out as antithetical to 
> the stated goals of the Swift evolution.
> 
> Regards, Michael
> 
> ==
> Michael M. Mayer
> Hanover, MD
> m.may...@gmail.com
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

Type inference sounds nice initially then you face the costs in compilation 
time and reduced ability to debug and reason about the code months after the 
fact... and you start to rethink things (not every programmer keeps 
maintainability over pretty smart haiku code).

Sent from my iPhone

> On 8 Apr 2017, at 07:35, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Apr 7, 2017, at 22:40, Pranshu Goyal via swift-evolution 
>>  wrote:
>> 
>> I agree with the sentiment of the proposal, it does add value to overall 
>> efficiency of swift and make things simpler for the swift team, but as 
>> Matthew said a blanket ban will add noise to the code. Also this particular 
>> feature is one of those niceties about swift which makes it very welcoming 
>> to new adopters.
>> 
>> If some middle ground can be proposed to this problem then I think we will 
>> be making a lot of people happy.
> 
> I don't think I'd mind a flag that disables type inference for properties or 
> something. Really, though, this seems like a linter's job to me.
> 
> Maybe the Swift manual should have a chapter about the trade-offs between 
> code that's quick to write, quick to run, and quick to compile?
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 7 Apr 2017, at 09:56, Jonathan Hull via swift-evolution 
>  wrote:
> 
>> What is your evaluation of the proposal?
> 
> Strong -1.  Just rename ‘fileprivate’ to be less annoying.

So, we keep being told it won't happen and our current Bly suggestion 
discussing this proposal cannot be to just keep asking for it, can it?

> 
> This proposal will make things even worse than they are currently.  We will 
> regret it just as much, if not more than, 0025.  As others have mentioned, it 
> is actively harmful:
> • It once again changes the meaning of private
> • It takes away most of the actual power of private (vs fileprivate). (I was 
> for returning to the simpler Swift 2 access, but when I did use private, I 
> used it to limit access to just a few lines of code. This proposal gets rid 
> of the last ounce of usefulness of ‘private’ for me, and only has the virtue 
> of a less annoying name).
> • It is the camel’s nose in the tent for type-based access (people will ask 
> for future versions to be available in the type in the submodule, module, and 
> then public… but we will be unable to give it to them)
> • It breaks the same code that 0159 would have broken
> • It will be a nightmare to teach/learn
> 
> Also, the idea that we should limit the use of ‘fileprivate’ is incorrect. 
> Fileprivate is the best access levels for a lot of cases, it just has an 
> annoying name.  Given our constraints, I now believe the only sane choice 
> left to us is to make fileprivate easier to use (as opposed to making private 
> more like it) and to get rid of the cognitive dissonance of having similar 
> names/concepts by renaming ‘fileprivate’ to something like ‘local’.  
> ‘fileprivate’ (whatever it is called) should be the soft-default. ‘private’ 
> should be the one being used explicitly.
> 
> We are likely going to have to rename ‘fileprivate’ anyway to work with 
> submodules (that or add another access level), and ‘local’ has connotations 
> of visible nearby… so I think it works well enough.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Yes, access controls are a mess… but this will make them more of a mess.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> No.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> No. I have used languages with type-based private, and I have used languages 
> with file-based private… but never type-based that was limited to a file.  
> You got shrimp in my chocolate (not all great tastes go well together).
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> I have followed the discussion closely and spent a great deal of time 
> thinking about it.
> 
> Thanks,
> Jon
> 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

We should evaluate the proposal in terms of what it can do not in "we are upset 
we are not getting that old proposal reverted" or "I want something else which 
I know I am not going to get".

Sorry if this is a bit direct, meant no offence.

Sent from my iPhone

> On 7 Apr 2017, at 01:05, Vladimir.S via swift-evolution 
>  wrote:
> 
> If you don't want to resolve the mistake of SE-0025 by proposing a really 
> solution but not a workaround, then just leave the things where they are 
> currently. Proposed "improvement" IMO is more confusing than helping.
> 
> Sorry, I don't buy <<..most of those proposals are not in scope for 
> discussion in Swift 4 (or any later release), given the significant impact on 
> source compatibility>>, because SE-0169 is also a source breaking change, and 
> the problem of access modifiers is important enough to relax the rule of 
> source compatibility for it, *especially if this is the last chance*.
> Also, it seems like core team was ready to accept SE-0159(Fix Private Access 
> Levels) which also has impact on source compatibility(given it suggested to 
> remove scoped-private).
> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.
> 
> So, -1 from me.
> 
>> On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
>> Hello Swift community,
>> 
>> The review of SE-0169 "Improve Interaction Between private Declarations and
>> Extensions" begins now and runs through April 11, 2017. The proposal is
>> available here:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>> 
>>https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review
>> manager. When replying, please try to keep the proposal link at the top of
>> the message:
>> 
>>Proposal link:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> 
>>Reply text
>> 
>>Other replies
>> 
>> 
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine the direction of
>> Swift. When writing your review, here are some questions you might want to
>> answer in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change
>>to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature,
>>how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick
>>reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 7 Apr 2017, at 00:25, Slava Pestov via swift-evolution 
>  wrote:
> 
> Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
> over.

Considering the importance of access control for a lot of people and the rare 
chance to do something about it, that looks a bit like a technicality Slava, no 
offence meant :)

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

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

[Goffredo Marocchi via swift-evolution]

+1 this is perhaps the best compromise between the two views on access control 
I have seen in a while and the change is actually very tiny yet meaningful. 
Thanks David and Chris!

Sent from my iPhone

> On 7 Apr 2017, at 00:10, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
+1 this is something that would make the language more pleasing to use and 
easier to learn and code well in.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, we have a rare chance to adjust something that represented a pain point 
and brought lots of arguing back and forth in the community. It is time to move 
past it and give it the help it needs.

> Does this proposal fit well with the feel and direction of Swift?
I think it does yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
It makes private and fileprivate belong in the language and help it stay true 
to its progressive disclosure and architecture goals while being more inviting 
to users coming from other super mainstream programming languages which 
facilitate the cross pollination of ideas and talent.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Followed all the scoped and regular access controls discussions.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 4 Apr 2017, at 03:20, Shawn Erickson via swift-evolution 
>  wrote:
> 
> Yeah I think the best course of action is to leave things alone until such 
> time as we can more holistically work things as you outline.

Considering how small this private rule relaxation is, it seems strange to swat 
away this proposal... (especially from the perspective which did want to 
reverse the previous proposal if I have to be honest). I am not seeing why we 
should wait.

> 
> Folks can strive to use private as the default lesser then module access 
> level with fileprivate remaining available for those code patterns that 
> require it for now (e.g. falling back on using the IMHO crutch of file 
> co-residency).
> 
>> On Mon, Apr 3, 2017 at 1:28 PM Austin Zheng via swift-evolution 
>>  wrote:
>> I am a reluctant -1. If rejecting 159 was the right course of action to 
>> avoid unnecessary churn, I think that any further modification to the access 
>> control system should come as part of a comprehensive 
>> modules/namespaces/code organization proposal. Extracting a bit of 
>> progressive disclosure from yet another change in the rules really doesn’t 
>> seem worth the cost of developers having to relearn what access control does 
>> yet again.
>> 
>> Best,
>> Austin
>> 
>> 
>>> On Apr 3, 2017, at 2:34 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift Community,
>>> 
>>> In rejecting SE-0159, the core team described a potential direction we 
>>> would like to investigate for “private” access control that admits a 
>>> limited form of type-based access control within files. The core team is 
>>> seeking some discussion here and a motivated volunteer to put together a 
>>> proposal along these lines for review in the Swift 4 time-frame (i.e., very 
>>> soon). To be clear, the core team it’s sure this is the right direction to 
>>> go… but it appears promising and we would *love* to be able to settle the 
>>> access-control issue.
>>> 
>>> The design, specifically, is that a “private” member declared within a type 
>>> “X” or an extension thereof would be accessible from:
>>> 
>>> * An extension of “X” in the same file
>>> * The definition of “X”, if it occurs in the same file
>>> * A nested type (or extension thereof) of one of the above that occurs 
>>> in the same file
>>> 
>>> This design has a number of apparent benefits:
>>> + “private” becomes the right default for “less than whole module” 
>>> visibility, and aligns well with Swift coding style that divides a type’s 
>>> definition into a number of extensions.
>>> + “fileprivate” remains for existing use cases, but now it’s use it 
>>> more rare, which has several advantages:
>>> + It fits well with the "progressive disclosure” philosophy 
>>> behind Swift: you can use public/internal/private for a while before 
>>> encountering and having to learn about “fileprivate”   (note: we thought 
>>> this was going to be true of SE-0025, but we were clearly wrong)
>>> + When “fileprivate” occurs, it means there’s some interesting 
>>> coupling between different types in the same file. That makes fileprivate a 
>>> useful alert to the reader rather than, potentially, something that we 
>>> routinely use and overlook so that we can separate implementations into 
>>> extensions.
>>> + “private” is more closely aligned with other programming languages 
>>> that use type-based access control, which can help programmers just coming 
>>> to Swift. When they reach for “private”, they’re likely to get something 
>>> similar to what they expect—with a little Swift twist due to Swift’s heavy 
>>> use of extensions.
>>> + Loosening the access restrictions on “private” is unlikely to break 
>>> existing code.
>>> 
>>> There are likely some drawbacks:
>>> - Developers using patterns that depend on the existing 
>>> lexically-scoped access control of “private” may find this new 
>>> interpretation of “private” to be insufficiently strict
>>> - Swift’s access control would go from “entirely lexical” to “partly 
>>> lexical and partly type-based”, which can be viewed as being more 
>>> complicated
>>> 
>>> Thoughts? Volunteer?
>>> 
>>> - Doug
>>> ___
>>> 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] Type-based ‘private’ access within a file

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 4 Apr 2017, at 02:16, Jonathan Hull via swift-evolution 
>  wrote:
> 
> This is very disappointing.  We can’t realistically get access controls 
> correct until we have a story around submodules, etc.  Those things are out 
> of scope for Swift 4, and we can’t change access controls after Swift 4. 
> Catch-22.
> 
> We should hold off on doing anything now, and redesign holistically when we 
> do the rest.
> 
> -1. This just adds tires to the tire fire.  I feel like it only adds to the 
> confusion between private and fileprivate by making them less distinct from 
> one another.  If we have to make a change now (because we won’t be able to 
> later… which I would strongly ask you to reconsider), then I would go with 
> the renaming proposal.  It is not at all ideal, but it would at least make 
> things a little better long-term if we are to be stuck with the design. 

I actually think this good slight enhancement to private makes sense and brings 
it in line with many requests we have gotten during our earlier discussion. I 
think that we are making a mountain out of a molehill by pushing back against 
this as if it would rush submodules or a holistic design sooner... Also, it is 
a minor non source breaking extension, not something huge and potentially 
damaging to the language.

> 
> I regret pretty much all of the proposals in Swift 3 which were accepted 
> based on “We have to do this now. or else…”   Pretty much universally, it 
> would have been better to wait.
> 
> 
>>> On Apr 3, 2017, at 2:22 PM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Apr 3, 2017, at 5:21 PM, David Hart  wrote:
 
 
> On 3 Apr 2017, at 23:19, John McCall  wrote:
> 
> 
>> On Apr 3, 2017, at 5:11 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 3 Apr 2017, at 22:54, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Apr 3, 2017, at 1:13 PM, Matthew Johnson  
 wrote:
 
 
 On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution 
  wrote:
 
 I’m concerned that we will have access control changes in a future 
 version yet again, when light-weight modules, or other type of 
 enforced namespace is introduced. Does the core team have any 
 foresight on how this change would interact with such things? I had 
 the same concern for SE-0159 as well. 
 
 There’s a implicit drawback to all access control changes that 
 migrator/fix-its cannot fix: we organize our code with tools in the 
 language. Some colleague of mine had came up with schemes that 
 combines file scope and Swift 3 `private` to hide details among 
 separate protocol extensions, for example. Code ends up in certain 
 places for a reason and updating access control invalidate those 
 reasons.
 
 I hesitate to support any changes until we have some ideas for what 
 “ultimate glory” looks like.
>>> 
>>> +1.  
>>> 
>>> If we must make a change in Swift 4, the only change I can support for 
>>> Swift 4 is renaming the existing access levels.  
>> 
>> We don’t have to make a change in Swift 4. If there’s a change that can 
>> resolve this issue, great…
> 
> I still think this is a worthwhile goals.
> 
>>> That would cause some churn but can be automated and has no semantic 
>>> impact.  I feel strongly that the semantics of access control should 
>>> remain the same until submodules and access control can be considered 
>>> together as part of the theme of a larger Swift release.  I believe the 
>>> churn caused by continuing to poke at the semantics of access control 
>>> without addressing the broader issues would be a mistake that would 
>>> cause further frustration in the community.  
>> 
>> … but if not, then let’s shelve access control changes until some time 
>> when we can considered it holistically with something like submodules, 
>> as you note above.
> 
> Won’t making big modifications later be even more problematic than now, 
> in the name of source stability?
 
 Yes.  Big changes along these lines will not be considered later.  At 
 best, it would be possible to "re-cast" existing behaviors in light of new 
 features — that is, significantly changing *how we talk about those 
 behaviors*, and changing how we understand them in the broader language, 
 but not actually changing the behaviors themselves.
>>> 
>>> That’s why I don’t buy the “lets postpone this discussion to a future 
>>> submodule design” argument. Let’s get this in a reasonable state now :)
>> 
>> I agree.  This is why we asked swift-evolution to consider this last tweak: 
>> it is realistically the last opportunity to do it.
>> 
>> John.
>> 
>>> 
 John.
 
 
> 
>>

Re: [swift-evolution] Type-based ‘private’ access within a file

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 4 Apr 2017, at 01:01, David Waite via swift-evolution 
>  wrote:
> 
> Soft -1 for four reasons:
> 
> 1. I would expect private to be used to hide implementation details and type 
> invariants from all code, to encapsulate and protect the unsafe bits. Think 
> the possibility to put the instance into an illegal state, or to modify its 
> state outside of its defined threading model. Why would an extension be 
> trusted to do this? This smacks of a ‘protected’ mode for extensions.

Not everybody would hate that ;), but seriously it seemed a strong request in 
all our discussions about this and it comes at a very small cost.

> 
> 2. This makes the model more confusing, and increases overlap with file 
> private. It seems this is here just to appease the people who think 
> “fileprivate” is an ugly wart, while not having time to formulate a strategy 
> to eliminate file private. The real issue is that there isn’t a level between 
> fileprivate and internal.
> 
> 3. This seems to make the issue of large files even worse, by encouraging the 
> use of ‘private’ as a way of exposing an extension-specific API of a type 
> that is only accessible by putting extensions in the same file
> 
> 4. From discussions on migration, I believe we can leave the option open of 
> widening private later as part of a tasked redesign of access control after 
> Swift 4.0. I’d prefer to not widen private before we have evaluated access 
> control as a whole, as I believe private as it is today is the lowest, most 
> restrictive-but-usable level of access control.

I am not sure this kind of change will easily happen for Swift 5, I say let's 
not waste this chance.

> 
> -DW
> 
>> On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift Community,
>> 
>> In rejecting SE-0159, the core team described a potential direction we would 
>> like to investigate for “private” access control that admits a limited form 
>> of type-based access control within files. The core team is seeking some 
>> discussion here and a motivated volunteer to put together a proposal along 
>> these lines for review in the Swift 4 time-frame (i.e., very soon). To be 
>> clear, the core team it’s sure this is the right direction to go… but it 
>> appears promising and we would *love* to be able to settle the 
>> access-control issue.
>> 
>> The design, specifically, is that a “private” member declared within a type 
>> “X” or an extension thereof would be accessible from:
>> 
>>  * An extension of “X” in the same file
>>  * The definition of “X”, if it occurs in the same file
>>  * A nested type (or extension thereof) of one of the above that occurs 
>> in the same file
>> 
>> This design has a number of apparent benefits:
>>  + “private” becomes the right default for “less than whole module” 
>> visibility, and aligns well with Swift coding style that divides a type’s 
>> definition into a number of extensions.
>>  + “fileprivate” remains for existing use cases, but now it’s use it 
>> more rare, which has several advantages:
>>  + It fits well with the "progressive disclosure” philosophy 
>> behind Swift: you can use public/internal/private for a while before 
>> encountering and having to learn about “fileprivate”   (note: we thought 
>> this was going to be true of SE-0025, but we were clearly wrong)
>>  + When “fileprivate” occurs, it means there’s some interesting 
>> coupling between different types in the same file. That makes fileprivate a 
>> useful alert to the reader rather than, potentially, something that we 
>> routinely use and overlook so that we can separate implementations into 
>> extensions.
>>  + “private” is more closely aligned with other programming languages 
>> that use type-based access control, which can help programmers just coming 
>> to Swift. When they reach for “private”, they’re likely to get something 
>> similar to what they expect—with a little Swift twist due to Swift’s heavy 
>> use of extensions.
>>  + Loosening the access restrictions on “private” is unlikely to break 
>> existing code.
>> 
>> There are likely some drawbacks:
>>  - Developers using patterns that depend on the existing 
>> lexically-scoped access control of “private” may find this new 
>> interpretation of “private” to be insufficiently strict
>>  - Swift’s access control would go from “entirely lexical” to “partly 
>> lexical and partly type-based”, which can be viewed as being more complicated
>> 
>> Thoughts? Volunteer?
>> 
>>  - Doug
>> ___
>> 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-ev

Re: [swift-evolution] Type-based ‘private’ access within a file

[Goffredo Marocchi via swift-evolution]

+1

Sent from my iPhone

> On 3 Apr 2017, at 22:21, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 3 Apr 2017, at 23:19, John McCall  wrote:
>>> 
>>> 
 On Apr 3, 2017, at 5:11 PM, David Hart via swift-evolution 
  wrote:
 
 
> On 3 Apr 2017, at 22:54, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Apr 3, 2017, at 1:13 PM, Matthew Johnson  
>> wrote:
>> 
>> 
>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> I’m concerned that we will have access control changes in a future 
>> version yet again, when light-weight modules, or other type of enforced 
>> namespace is introduced. Does the core team have any foresight on how 
>> this change would interact with such things? I had the same concern for 
>> SE-0159 as well. 
>> 
>> There’s a implicit drawback to all access control changes that 
>> migrator/fix-its cannot fix: we organize our code with tools in the 
>> language. Some colleague of mine had came up with schemes that combines 
>> file scope and Swift 3 `private` to hide details among separate protocol 
>> extensions, for example. Code ends up in certain places for a reason and 
>> updating access control invalidate those reasons.
>> 
>> I hesitate to support any changes until we have some ideas for what 
>> “ultimate glory” looks like.
> 
> +1.  
> 
> If we must make a change in Swift 4, the only change I can support for 
> Swift 4 is renaming the existing access levels.  
 
 We don’t have to make a change in Swift 4. If there’s a change that can 
 resolve this issue, great…
>>> 
>>> I still think this is a worthwhile goals.
>>> 
> That would cause some churn but can be automated and has no semantic 
> impact.  I feel strongly that the semantics of access control should 
> remain the same until submodules and access control can be considered 
> together as part of the theme of a larger Swift release.  I believe the 
> churn caused by continuing to poke at the semantics of access control 
> without addressing the broader issues would be a mistake that would cause 
> further frustration in the community.  
 
 … but if not, then let’s shelve access control changes until some time 
 when we can considered it holistically with something like submodules, as 
 you note above.
>>> 
>>> Won’t making big modifications later be even more problematic than now, in 
>>> the name of source stability?
>> 
>> Yes.  Big changes along these lines will not be considered later.  At best, 
>> it would be possible to "re-cast" existing behaviors in light of new 
>> features — that is, significantly changing *how we talk about those 
>> behaviors*, and changing how we understand them in the broader language, but 
>> not actually changing the behaviors themselves.
> 
> That’s why I don’t buy the “lets postpone this discussion to a future 
> submodule design” argument. Let’s get this in a reasonable state now :)
> 
>> John.
>> 
>> 
>>> 
> As others have already pointed out, code has been developed and organized 
> with the new scoped access model in mind.  I think the frustration over a 
> semantically neutral, fully automated migration to new names would be 
> pretty minimal 
 
 The core team felt strongly that we couldn’t change these keywords. Source 
 stability is important to Swift 4, and “don’t break source compatibility 
 so much” is one of the top requests we hear from Swift developers, much 
 more so than requests for specific new language features.
 
> and certainly much less than the frustration over the suggested semantic 
> change.  
 
 This isn’t clear to me. There could certainly be frustration over the 
 suggested semantic change, for a number of reasons:
 
 * It’s not as “tight” a meaning of private as the current scope-based 
 private.
 * It means we have a hybrid type-based/scope-based model.
 * It’s the third meaning of ‘private’ in three years.
 
 However, it is unlikely to break code (one would need to construct an 
 ambiguity between two private declarations in different extensions of the 
 same type in the same file), and causes zero code churn, because it’s 
 widening the meaning of “private”, not changing it.
 
- Doug
 
> 
>> 
>>> On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift Community,
>>> 
>>> In rejecting SE-0159, the core team described a potential direction we 
>>> would like to investigate for “private” access control that admits a 
>>> limited form of type-based access control within files. The core team 
>>> is seeking some discussion here and a motivated volunteer to put 
>>> together a proposal along these lines for review in the Swift 4 

[swift-evolution] Fwd: Type-based ‘private’ access within a file

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

Begin forwarded message:

> From: Goffredo Marocchi 
> Date: 3 April 2017 at 22:39:25 BST
> To: Douglas Gregor 
> Subject: Re: [swift-evolution] Type-based ‘private’ access within a file
> 
> +1 this brings some of the best points brought on both side of the private 
> and fileprivate arguments while also thinking of users approaching Swift from 
> other major programming language and fitting in with Swift's goal of 
> progressive disclosure.
> 
> I like this idea very much (off-topic: almost as much as bringing back 
> argument labels in function/closure types ;)).
> 
> Sent from my iPhone
> 
>> On 3 Apr 2017, at 19:34, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift Community,
>> 
>> In rejecting SE-0159, the core team described a potential direction we would 
>> like to investigate for “private” access control that admits a limited form 
>> of type-based access control within files. The core team is seeking some 
>> discussion here and a motivated volunteer to put together a proposal along 
>> these lines for review in the Swift 4 time-frame (i.e., very soon). To be 
>> clear, the core team it’s sure this is the right direction to go… but it 
>> appears promising and we would *love* to be able to settle the 
>> access-control issue.
>> 
>> The design, specifically, is that a “private” member declared within a type 
>> “X” or an extension thereof would be accessible from:
>> 
>>  * An extension of “X” in the same file
>>  * The definition of “X”, if it occurs in the same file
>>  * A nested type (or extension thereof) of one of the above that occurs 
>> in the same file
>> 
>> This design has a number of apparent benefits:
>>  + “private” becomes the right default for “less than whole module” 
>> visibility, and aligns well with Swift coding style that divides a type’s 
>> definition into a number of extensions.
>>  + “fileprivate” remains for existing use cases, but now it’s use it 
>> more rare, which has several advantages:
>>  + It fits well with the "progressive disclosure” philosophy 
>> behind Swift: you can use public/internal/private for a while before 
>> encountering and having to learn about “fileprivate”   (note: we thought 
>> this was going to be true of SE-0025, but we were clearly wrong)
>>  + When “fileprivate” occurs, it means there’s some interesting 
>> coupling between different types in the same file. That makes fileprivate a 
>> useful alert to the reader rather than, potentially, something that we 
>> routinely use and overlook so that we can separate implementations into 
>> extensions.
>>  + “private” is more closely aligned with other programming languages 
>> that use type-based access control, which can help programmers just coming 
>> to Swift. When they reach for “private”, they’re likely to get something 
>> similar to what they expect—with a little Swift twist due to Swift’s heavy 
>> use of extensions.
>>  + Loosening the access restrictions on “private” is unlikely to break 
>> existing code.
>> 
>> There are likely some drawbacks:
>>  - Developers using patterns that depend on the existing 
>> lexically-scoped access control of “private” may find this new 
>> interpretation of “private” to be insufficiently strict
>>  - Swift’s access control would go from “entirely lexical” to “partly 
>> lexical and partly type-based”, which can be viewed as being more complicated
>> 
>> Thoughts? Volunteer?
>> 
>>  - Doug
>> ___
>> 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] Type-based ‘private’ access within a file

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 Apr 2017, at 22:03, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 3, 2017, at 3:54 PM, Douglas Gregor  wrote:
>>> 
>>> 
 On Apr 3, 2017, at 1:13 PM, Matthew Johnson  wrote:
 
 
 On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution 
  wrote:
 
 I’m concerned that we will have access control changes in a future version 
 yet again, when light-weight modules, or other type of enforced namespace 
 is introduced. Does the core team have any foresight on how this change 
 would interact with such things? I had the same concern for SE-0159 as 
 well. 
 
 There’s a implicit drawback to all access control changes that 
 migrator/fix-its cannot fix: we organize our code with tools in the 
 language. Some colleague of mine had came up with schemes that combines 
 file scope and Swift 3 `private` to hide details among separate protocol 
 extensions, for example. Code ends up in certain places for a reason and 
 updating access control invalidate those reasons.
 
 I hesitate to support any changes until we have some ideas for what 
 “ultimate glory” looks like.
>>> 
>>> +1.  
>>> 
>>> If we must make a change in Swift 4, the only change I can support for 
>>> Swift 4 is renaming the existing access levels.  
>> 
>> We don’t have to make a change in Swift 4. If there’s a change that can 
>> resolve this issue, great…
>> 
>>> That would cause some churn but can be automated and has no semantic 
>>> impact.  I feel strongly that the semantics of access control should remain 
>>> the same until submodules and access control can be considered together as 
>>> part of the theme of a larger Swift release.  I believe the churn caused by 
>>> continuing to poke at the semantics of access control without addressing 
>>> the broader issues would be a mistake that would cause further frustration 
>>> in the community.  
>> 
>> … but if not, then let’s shelve access control changes until some time when 
>> we can considered it holistically with something like submodules, as you 
>> note above.
> 
> This is certainly what I would prefer.  I only mention renaming because there 
> is such strong interest in changing something.  I would be happy to defer 
> this topic and have been arguing for that approach ever since your note that 
> only SE-0159 would be considered in scope for Swift 4.
> 
>> 
>>> As others have already pointed out, code has been developed and organized 
>>> with the new scoped access model in mind.  I think the frustration over a 
>>> semantically neutral, fully automated migration to new names would be 
>>> pretty minimal 
>> 
>> The core team felt strongly that we couldn’t change these keywords. Source 
>> stability is important to Swift 4, and “don’t break source compatibility so 
>> much” is one of the top requests we hear from Swift developers, much more so 
>> than requests for specific new language features.
> 
> That’s fair.
> 
>> 
>>> and certainly much less than the frustration over the suggested semantic 
>>> change.  
>> 
>> This isn’t clear to me. There could certainly be frustration over the 
>> suggested semantic change, for a number of reasons:
>> 
>> * It’s not as “tight” a meaning of private as the current scope-based 
>> private.
>> * It means we have a hybrid type-based/scope-based model.
>> * It’s the third meaning of ‘private’ in three years.
>> 
>> However, it is unlikely to break code (one would need to construct an 
>> ambiguity between two private declarations in different extensions of the 
>> same type in the same file), and causes zero code churn, because it’s 
>> widening the meaning of “private”, not changing it.
> 
> I’m speculating based on my read of the community here as well as other Swift 
> developers I know.  I could be wrong, but my sense is that the items you list 
> would cause more frustration than renaming, especially if the name change 
> purged `fileprivate`.  I don’t know anyone outside the evolution community 
> who I think would complain if access control was left alone for a while.  

I would quite like the model proposed here actually as it does make private a 
very very sane default, fits with Swift's progressive disclosure goals and its 
architecture, as well as eases the transition of developers from other major 
languages which is a massive boon to this community too without nasty side 
effects or sacrifices to Swift's ideals. +1 to this change :).

I think this proposal is worth acting upon rather than waiting another year for 
something which, looking ahead, is not sure to be overhauled so much before 
Swift 5 is finalised.

> Some were not happy with the changes in Swift 3 but I don’t hear too much 
> about it off the list anymore now that the migration is over and people have 
> adapted.
> 
>> 
>>  - Doug
>> 
>>> 
 
> On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> H

Re: [swift-evolution] [Proposal] Factory Initializers

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 1 Apr 2017, at 00:35, Riley Testut via swift-evolution 
>  wrote:
> 
> 
>> On Mar 20, 2017, at 8:07 PM, Greg Parker  wrote:
>> 
>> This needs more explanation. It is allowed for a subclass to implement a 
>> convenience initializer that has the same signature as a superclass 
>> convenience initializer or a superclass designated initializer. The 
>> convenience-over-convenience case is not technically overriding, but it is 
>> misleading to say only that a convenience initializer cannot be overridden. 
>> Do factory initializers follow exactly the same rules here as convenience 
>> initializers?
> 
> Yes, that is what I meant. For simplicity, I think the factory initializer 
> inheritance rules should match exactly that of convenience initializers.
> 
>> In addition: designated initializers and convenience initializers have rules 
>> about which other initializers can be called from an implementation. These 
>> rules are intended to guarantee that the chain of designated initializers is 
>> called correctly. What are the precise rules for factory initializers 
>> calling other initializers? What are the precise rules for non-factory 
>> initializers calling factory initializers?
> 
> Factory initializers can call any other initializers. Since calling 
> convenience initializers would still call required initializers, the chain 
> would be correct (unless I’m missing something). As for other initializers 
> calling factory initializers, my gut says this should not be allowed. Factory 
> initializers are supposed to initialize and return a value, whereas other 
> initializers implicitly assign to self. Therefore calling a factory 
> initializer from a self-assigning initializer wouldn’t do much, and I don’t 
> see any benefit to allowing this.
> 
> 
>> On Mar 21, 2017, at 8:49 AM, David Rönnqvist  
>> wrote:
>> 
>> Forgive me if that has already been discussed in the email threads prior to 
>> the proposal, but what I’m missing from this proposal is a discussion of the 
>> problems factory initializers solve (other than the examples at the end) and 
>> an explanation of why factory initializers are the right solution to 
>> that/those problems in Swift.
> 
> I can answer this anecdotally; when learning iOS development and Objective-C, 
> it was (in my opinion) hard to know whether an Objective-C class was meant to 
> be initialized via [[Class alloc] initWithParameters:] or [Class 
> classWithParameters:]. Pre-ARC this did actually have meaning, but post 
> ARC/iOS 5 it just seemed to be whatever the framework developer preferred 
> (not to mention that [Class new] was also another option…).
> 
> When Swift combined all these forms into one common Class(parameters:) 
> format, this greatly reduced this cognitive load. However, as outlined in the 
> proposal, this meant that the factory pattern had to be moved out of the 
> initializers and back into class methods. Because of this, now if you want to 
> implement the factory pattern, you’re bringing back this same confusion from 
> Objective-C; the client has to remember whether your class is initialized via 
> standard Class(parameters:) syntax, or by calling a class method 
> Class.classWithParameters(). Ultimately, I don’t believe there should be a 
> difference between the two for the average programmer. You want an instance 
> of the class, so you should retrieve one by calling an initializer. They 
> don’t need to know or care whether the initializer is directly assigning to 
> self or returning a value, as long as they get the value they need.
> 
> Beyond this, however, I think the factory initializers on protocols is one of 
> this proposal’s biggest wins. For protocol oriented programming, it’s nice to 
> be apply to supply a default implementation so client’s don’t need to declare 
> their own type. However, if you come across a new codebase/framework, you 
> might not know the difference between the specific type you’re using and the 
> protocol itself (or even which one is which). I’ve personally encountered 
> this many times with Apple’s frameworks, such as UIActivityItemProvider and 
> UIActivityItemSource (which one is the protocol and which one is the type? 
> Hard to know and remember when first using them). With factory initializers 
> on protocol extensions, the initializer can return a private type conforming 
> to the protocol, so again there’s no need to worry about what is the concrete 
> type and what is the protocol.
> 
> P.S. Phase 2 End Question
> 
> I didn’t realize until today that apparently Swift 4 Phase 2 ends tomorrow. 
> Is this true, and does that mean this is now too late to make it into Swift 4?

Did not realise it either... does this mean that we are not getting argument 
labels in closures passed to functions back as it was promised last year? :(

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 26 Mar 2017, at 06:54, John McCall via swift-evolution 
>  wrote:
> 
>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
>>  wrote:
>> Yes, it would change my opinion of it. I wouldn't become a strong supporter 
>> because I don't see any value in it, but a rigorous proof that this proposal 
>> could not possibly introduce regressions to any existing codebases would 
>> change my opinion from "strongly against" to "doesn't matter to me, I'll 
>> stop arguing against it and go get my real work done".
>> 
> Speaking just for myself, this was a key part of why I was attracted to this 
> proposal: it seemed to me to be extremely unlikely to cause regressions in 
> behavior.  Even without any special behavior in the migrator, code will 
> mostly work exactly as before: things that would have been invalid before 
> will become valid, but not the other way around.  The exception is that 
> old-private declarations from scopes in the same file can now be found by 
> lookups in different scopes (but still only within the same file).  It should 
> be quite straightforward for the migrator to detect when this has happened 
> and report it as something for the programmer to look at.  The proposal 
> causes a small regression in functionality, in that there's no longer any way 
> to protect scopes from accesses within the file, but (1) it's okay for Swift 
> to be opinionated about file size and (2) it seems to me that a workable 
> sub-module proposal should solve that more elegantly while simultaneously 
> addressing the concerns of the people who dislike acknowledging the existence 
> of files.

The opinionated flag sometimes, like being Swifty, is being used to swath away 
disagreement, but opinions should be reasonable and pragmatic too... 
opinionated as "you will code this way and you will like it" seems hardly ideal 
too if abused constantly. Programming is a creative endeavour too.

Also, removing a feature that is used and is useful because "maybe" a year or 
more away there could be a feature that may address the concerns of the people 
we are stripping away the current feature from seems quite harsh and unfriendly 
at best... not very logical either.

> 
> John.
>> -Carl
>> 
>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>> > 
>> From: Xiaodi Wu 
>> To: Carl Brown1/US/IBM@IBM
>> Cc: Drew Crawford , Jonathan Hull , 
>> swift-evolution 
>> Date: 03/25/2017 12:33 AM
>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>> 
>> 
>> 
>> 
>> Would it change your opinion on the proposal?
>> 
>> 
>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1  wrote:
>> I would very much like to see your proof that the resultant code is 
>> unchanged in an arbitrary codebase. 
>> 
>> -Carl
>> 
>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 
>> 11:55 PM, Carl Brown1  wrote: > Maybe this is the core
>> 
>> From: Xiaodi Wu 
>> To: Carl Brown1/US/IBM@IBM
>> Cc: Drew Crawford , Jonathan Hull , 
>> swift-evolution 
>> Date: 03/25/2017 12:01 AM
>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>> 
>> 
>> 
>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1  wrote:
>> My point is that, in rolling back the specific portion of SE-0025, 
>> case-sensitive find-and-replace will be the trickiest thing in most 
>> codebases, save those that result in invalid redeclarations. The behavior of 
>> the resultant code is, unless I'm mistaken, provably unchanged.
>> 
>> 
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 24 Mar 2017, at 05:36, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I agree with everything you wrote here. And it is for that reason that I 
> would expect that any future proposal for submodules should be judged in no 
> small part on its _not_ changing circumstances surrounding access modifiers, 
> such that no further proposals to revisit this topic will come up. It's one 
> thing to have one-off discussions to back out a change that in hindsight 
> seems unwise; it's quite another to have the community return to the same 
> topic over and over like this. No more. Let's do this never again.

It was not the people using and liking private's scope based visibility which 
brought this proposal forward and should be punished because of it.
I can understand what you are saying and where you are coming from, but it is 
not an argument strong enough to justify removing this access level for IMHO, 
quite the opposite really. 
Also, I do not think the core team would not want to revisit this/accept to 
revisit this once a good submodule design like the one Rust has were to be 
implemented into Swift.

>> On Fri, Mar 24, 2017 at 00:04 Drew Crawford  wrote:
 Or, since many designs for submodules are possible... confident that there 
 will be a good design for submodules
>>> 
>>> We lack any real information on what Swift designs are possible.  We can 
>>> look to other languages for inspiration but they cannot be transplanted 
>>> wholesale into Swift from a technical, practical, or cultural perspective.  
>>> Rust isn't Swift.
>>> 
>> 
>>> Given, as some have said above, many different submodule designs are 
>>> possible whatever the number of access levels, I would expect that we would 
>>> not revisit this topic again for the foreseeable future, whatever the 
>>> decision is.
>> 
>> I think it would be appropriate to revisit this if we have new information.  
>> You have previously argued that there is substantial new information which 
>> you present as a rationale to revisit it now.  I don't accept the premise, 
>> but I do accept the argument: if the circumstances change it's appropriate 
>> to take another look.
>> 
>> 
>>> On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution 
>>> (swift-evolution@swift.org) wrote:
>>> Or, since many designs for submodules are possible, we can proceed to make 
>>> the best decision *now* with respect to access levels, confident that there 
>>> will be a good design for submodules whether or not there exist both scoped 
>>> and file-based private access. That is to say, any future submodule 
>>> proposal would be judged on how well it accommodates desired use cases if 
>>> one type of private is removed, and any future design for submodules would 
>>> be judged on how well it fits with the current set of access levels without 
>>> duplicating functionality with a different syntax if both types of private 
>>> are retained.
>>> 
>>> One very important thing about the evolution process (IMO) is that 
>>> decisions made aren't revisited without compelling changes in 
>>> circumstances. It is highly unusual that fileprivate vs. private is now 
>>> going through this process for a _third_ time. I submit that it is 
>>> untenable that every version of Swift should consider a change to the 
>>> access modifiers. Given, as some have said above, many different submodule 
>>> designs are possible whatever the number of access levels, I would expect 
>>> that we would not revisit this topic again for the foreseeable future, 
>>> whatever the decision is. That is, the question being asked here is, is it 
>>> better for Swift to have both fileprivate and private for all time, or one 
>>> file-scoped private for all time?
> ___
> 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-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via swift-evolution 
>>  wrote:
>> 
>> One point which was raised by a couple of different people on this thread 
>> (Brent Royal-Gordon, Jonathan Hull), which gave me some hesitation in voting 
>> in favor of this proposal, is that it might make more sense to leave things 
>> alone for the time being, with the understanding that scoped access will be 
>> solved in some more general way via submodules in the future.
> 
> 
> For what it's worth, I don't really agree with Jonathan Hull on this. If 
> we're going to remove the band-aid, we might as well rip it off now; there's 
> no reason to wait for people to write more code for us to break.

Fair point, but I honestly do not see how the stated very strong burden of 
proof to revert previous proposals has been met. The new proposal does seem to 
do anything really to address the needs of those that have a legitimate use for 
scoped access and the current state of things does not make life impossible for 
people who want to use file based visibility only or mostly. I really want to 
avoid having another proposal like the one that removed argument labels from 
blocks (burying them from the type param) that is incomplete and supposed to 
get addressed, but still has not been almost a year later.

This proposal as it is does not feel complete and I do not think this helps it 
satisfy the burden of proof needed for this release.

> 
> My point was simply that the burden of proof is now on those proposing to 
> revert SE-0025, and the core team shouldn't accept this proposal unless they 
> are satisfied that the burden has clearly been met.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 22:49, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> That’s why protected (a feature) is on the commonly rejected proposals list
> 
> 
> Unless you’re referring to a different “commonly rejected proposals” list 
> than the one below, this does not appear to be true:
> 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
> 

Perceptions and sometimes... wishful thinking ;).

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 18:41, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  wrote:
> 
>> 
>> 
>>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>>> > that we’ve seen a lot of talk against the original change.
>> 
>> This proposal asks us to balance the convenience of one group 
>> (extension-writers) against the existence of another (scoped-access users).  
>> To do that, we need a clear idea of the composition of both groups.
>> 
>> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
>> not good enough when we introduced the feature, that required argument and 
>> clear use-cases.
>> 
> "A lot of talk" is not the evidence supporting the proposal: it's just a 
> warning that something may be very controversial among the community. The 
> arguments for the revert are in the proposal and in the discussions in this 
> thread.
> 
>>> > By default, I did not mean the syntactic default of the language but the 
>>> > access modifier users will use “by default” when trying to restrict 
>>> > visibility. In most languages, that keyword is “private” so its valid to 
>>> > say that newcomers to the language will “default” to using that one.
>> 
>> Apologies, but I do not understand the argument:
>> 
>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>> “internal”)
>> The user *chooses* private because of familiarity from another language
>> The user is then surprised that their choice of private indeed restricted 
>> the visibility, thus achieving their goal?
>> What language does the user come from in which “private” is file-visible?  
>> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
>> and it isn’t at all close.
> 
> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, especially when Swift does things 
> differently for a good reason. I can't stop from quoting Xiaodi from a month 
> back:
> 
> «The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility.» -- Xiaodi
> 

I do not see how Swift explicitly rejected both types and scope for determining 
visibility, we have private and fileprivate for a reason and they may not help 
everybody to feel Swifty or whatever that means in practice, but it allows 
others to do actual work. Having additional flexibility does not hurt people 
that want to stick with file based visibility.

None of us here is paid to write haiku/poetry code, so while beauty has a place 
it is not the necessary and sufficient condition for language features: code is 
meant to be read, refactored, and most of all shipped and debugged quickly.

>> A user who wants a middle-ground visibility would “default” to “protected”, 
>> “friend”, “partial”, or similar.  After that does not compile, they will use 
>> google to find a middle-road visibility keyword, for which the only 
>> candidate is “fileprivate”.  But they will not choose “private”, it’s just 
>> not a reasonable expectation of what the keyword means to a new Swift 
>> developer.
>> 
>> The popularity of private “as a default” is simply because many users prefer 
>> to hide their implementation details as a matter of routine code hygiene.  
>> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> The point is that keeping both private and fileprivate feels like an 
> un-necessary complication:
> 
> • either a programmer falls on your side of the fence and will use private as 
> often as possible and relegate to fileprivate when the design leaves no other 
> choice. At that point it feels like a language wart.
> • or a programmer will fall on my side of the fence and use fileprivate all 
> the time and the language feels like it has an unnecessary access modifier.
> 
> I'd argue that the cases when a programmer will use both meaningfully is very 
> rare. As a consequence, we should try to only keep one. Removing fileprivate 
> is a no-go with extensions so that leaves us with removing private.
> 
>> I agree with several here (as I did in SE-0025) that our access modifiers 
>> are not well-named.  However, that’s not the proposal in front of us.
>> 
>>> > My own statistics in my projects show the contrary. At best, this shows 
>>> > how divisive this feature is.
>> 
>> This *may* show that, if contrary statistics were presented, but that hasn’t 
>> occurred.
>> 
> I can generate statistics from my projects if you want. But it's unnecessary: 
> I haven't used private once since it's introduction in Swift 3. I don't see 
> the advantages it brings worth the trouble.
>>> In old code, statistics could be biased by the migrator having replaced all 
>>> previous instances of private by fileprivate.
>> 
>> If the migrator migrated code to private, a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 15:57, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>> > that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access users).  
> To do that, we need a clear idea of the composition of both groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
> not good enough when we introduced the feature, that required argument and 
> clear use-cases.
> 
>> > By default, I did not mean the syntactic default of the language but the 
>> > access modifier users will use “by default” when trying to restrict 
>> > visibility. In most languages, that keyword is “private” so its valid to 
>> > say that newcomers to the language will “default” to using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted the 
> visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible?  It 
> isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and 
> it isn’t at all close.
> 

I agree, the old change gave private a much more commonly understood and IMHO 
more understandable meaning (changing do while into repeat while is the kind of 
change I would not like to see again unless well justified :)).

> A user who wants a middle-ground visibility would “default” to “protected”, 
> “friend”, “partial”, or similar.  After that does not compile, they will use 
> google to find a middle-road visibility keyword, for which the only candidate 
> is “fileprivate”.  But they will not choose “private”, it’s just not a 
> reasonable expectation of what the keyword means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users prefer 
> to hide their implementation details as a matter of routine code hygiene.  
> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> I agree with several here (as I did in SE-0025) that our access modifiers are 
> not well-named.  However, that’s not the proposal in front of us.
> 
>> > My own statistics in my projects show the contrary. At best, this shows 
>> > how divisive this feature is.
> 
> This *may* show that, if contrary statistics were presented, but that hasn’t 
> occurred.
> 
>> In old code, statistics could be biased by the migrator having replaced all 
>> previous instances of private by fileprivate.
> 
> If the migrator migrated code to private, and it *worked* (e.g. did not 
> introduce visibility errors) this is not bias, this is a correct use of the 
> feature.
> 
>> > I'm just arguing that the additional scope-based access modifier does not 
>> > provide enough differentiation to be worth that complexity.
> 
> The only argument I have seen so far around “complexity” boils down to: “some 
> people do not use it”.  But some people *do* use it, and anyway if we are 
> going to remove all the features “not enough people” use then we are in for a 
> ride.
> 
> Swift 3 shipped, so what we are discussing now is yanking a keyword without 
> replacement.  There is code written that uses private to enforce its 
> threading or security invariants.  There is code written that uses private in 
> order to shadow another declaration.   There is code that will not compile 
> after migration. We need more than a vague fear of complexity generally to 
> throw a brick through all those windows.  That brick will introduce quite a 
> bit of complexity itself.
> 
>> Concerning the one-class-per-file argument, I would suggest this 
>> counter-argument: when working in large projects, I believe it's a good 
>> thing if the language encourages (forces is too strong a word for my taste) 
>> a one class per file structure, it's good practice.
> 
> The form of the argument is invalid.  Suppose I argued: "it’s a good thing 
> for the language to encourage one definition per class (no extensions), it’s 
> good practice.  So we do not need fileprivate.”  That would be very silly 
> (although it has already been advanced as a straw-man position elsewhere in 
> this thread). The argument that we do not need private because nobody should 
> put multiple classes in a file is equally silly. There are reasons to do so, 
> in fact one motivation was given in SE-0025:
> 
>> > Putting related APIs and/or related implementations in the same file helps 
>> > ensure consistency and reduces the time to find a particular API or 
>> > implementation. 
> 
> 
> These concerns are not resolved by arguments of the form “just don’t do that”.
> 
> I empathize with the S

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 20:36, Goffredo Marocchi  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On 21 Mar 2017, at 16:23, Davor Jankolija via swift-evolution 
>>  wrote:
>> 
>> 
>>> What is your evaluation of the proposal?
>> 
>> + 1.
>> 
>> Don’t like to admit it but i favored the fileprivate modifier when it was 
>> introduced. Alas more experince with Swift has meant that I now very often 
>> catch myself changing private to fileprivate if for nothing else then to 
>> allow protocol conformance through extensions in the same file. Even though 
>> this may not be a good enough reason to make me go with supporting the 
>> proposal, the fact that access modifiers are fundamental to most modern PLs 
>> and fileprivate vs private as is is now adds too little while on the other 
>> hand adds another access modifier which IMHO should be simple and allow 
>> encapsluation (as some have said, internal and public are actually enough to 
>> achieve this) means for me this is something worth reverting.
> 
> The current situation does not prevent anyone from expressing 
> themselves/implementing their preferred patterns. I am really not sure why we 
> should revert a change which allowed people that value and need scope based 
> access to do their job?
> 
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> 
>> Yes.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> 
>> Most other languages encapsulate based on type and inheritance, so this 
>> strays a bit by making private extend beyond the class definition itself. 
>> However, no other language I’ve used make use of extensions the way Swift 
>> does so it makes sense in a Swift environment.
>> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> Followed both the original conversation added fileprivate as well as the 
>> other conversations which led to this proposal. 
>> 
>> - Davor
>> 
>> ___
>> 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-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Forgot to cc.

Sent from my iPhone

> On 21 Mar 2017, at 07:43, Goffredo Marocchi  wrote:
> 
> 
> Sent from my iPhone
> 
>> On 21 Mar 2017, at 02:33, Greg Parker via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>>> through March 27, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> 
>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
>> explained my concerns.
>> 
> 
> -1 here as well, fully support Drew Crawford's points too. 
> 
> To add my own 2c to it, I would say better time would be spent gathering data 
> on number of bugs, severity, performance and more correlated to the (growing) 
> use of Swift for example rather than just vocally discuss what is Swifty and 
> what is not, talk about safety by default and performance to drive our 
> community decisions without tracking those kpi's (data driven decisions). As 
> much as it could be improved, Mozilla's AreWeFastYet.org's project is a 
> direction we could explore.
> 
> 
>> -- 
>> Greg Parker gpar...@apple.com Runtime Wrangler
>> 
>> 
>> ___
>> 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-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 07:05, Rien via swift-evolution 
>  wrote:
> 
> +1
> 
>>• What is your evaluation of the proposal?
> 
> Makes the language easier to understand, lowers cognitive load during coding.

Is it really a problem for cognitive load during coding? In a world where 
protocol extensions defined default methods introducing back the nice and easy 
to understand concept of polymorphism by reference type where casting an 
instances class that overrides the method declared in the protocol extensions 
decides which  method is actually executed... well, having to juggle file and 
scope based access levels breaks the camel's back?

I remain unconvinced of this, no offense meant Rien.

> I also hope this will pave the way for a overhaul of the access level system 
> including modularization.
> 
>>• Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> yes.
> 
>>• Does this proposal fit well with the feel and direction of Swift?
> 
> Yes
> 
>>• If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> private vs fileprivate seems swift-only, as such I have no comparison.
> 
>>• How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Followed and participated in the discussions.
> 
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> through March 27, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>• What is your evaluation of the proposal?
>>• Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>• Does this proposal fit well with the feel and direction of Swift?
>>• If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>• How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 05:48, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Charles Srstka's added comment, while intriguing, poses a problem in 
>> argumentation. One of the points being made above about the major advantage 
>> of new `private` over `fileprivate` is precisely that new `private` is 
>> invisible to extensions. If one "solves" the problem of having to use 
>> `fileprivate` by making `private` visible to extensions, it may well be the 
>> case that `fileprivate` is no longer commonly necessary--but one has also 
>> reverted one of the major arguments in favor of new `private` in the first 
>> place.
> 
> I don’t see making things invisible to extensions to be the benefit of 
> ‘private’ at all—it’s for maintaining encapsulation with embedded types. i.e. 
> things like this:
> 
> class Foo {
>   class Bar {
>   private var baz: String // <— ‘Foo’ doesn’t need to access this
>   }
> }
> 
> This just enforces good programming style.

I cannot believe this proposal is putting scoped access' value into question 
sigh (not you, you are making a point supporting it obviously :)).


> On the other hand, the problem with extensions that people are talking about 
> comes from using extensions to separate sections of a type’s built-in code, 
> mainly around protocol conformances:
> 
> class Foo {
>   private var bar: String
> }
> 
> extension Foo: Baz {
>   func requiredByBaz() {
>   doSomething(with: self.bar) // <— ruh roh
>   }
> }
> 
> The way I look at it, the extension feature was created with the idea of 
> extending someone else’s type in mind, but the community latched onto it as a 
> way to organize the parts of your own type, and Swift 3’s ‘private’ is 
> getting in the way of that. Broadening ‘private’ to reach in-module 
> extensions would solve this issue, and would *also* allow flexibility to, 
> when the code for an extension gets significantly large relative to the rest 
> of the type's code, split that part off into a different file without needing 
> to make your internal state visible to the entire module. Kill two birds with 
> one stone, so to speak.
> 
> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 16 Mar 2017, at 01:18, Joe Groff via swift-evolution 
>  wrote:
> 
> Congrats on getting this out! A question from the field:
> 
> https://twitter.com/mdiep/status/842178457115230210 Why does the Swift 
> Serialization API proposal use abstract base classes?
> 

Hopefully because we realise we need abstract classes as a feature ;)? 

> -Joe
> 
> 
>> On Mar 15, 2017, at 3:40 PM, Itai Ferber via swift-evolution 
>>  wrote:
>> 
>> Hi everyone,
>> 
>> The following introduces a new Swift-focused archival and serialization API 
>> as part of the Foundation framework. We’re interested in improving the 
>> experience and safety of performing archival and serialization, and are 
>> happy to receive community feedback on this work.
>> Because of the length of this proposal, the Appendix and Alternatives 
>> Considered sections have been omitted here, but are available in the full 
>> proposal on the swift-evolution repo. The full proposal also includes an 
>> Unabridged API for further consideration.
>> 
>> Without further ado, inlined below.
>> 
>> — Itai
>> 
>> Swift Archival & Serialization
>>• Proposal: SE-
>>• Author(s): Itai Ferber, Michael LeHew, Tony Parker
>>• Review Manager: TBD
>>• Status: Awaiting review
>>• Associated PRs:
>>• #8124
>>• #8125
>> Introduction
>> Foundation's current archival and serialization APIs (NSCoding, 
>> NSJSONSerialization, NSPropertyListSerialization, etc.), while fitting for 
>> the dynamism of Objective-C, do not always map optimally into Swift. This 
>> document lays out the design of an updated API that improves the developer 
>> experience of performing archival and serialization in Swift.
>> 
>> Specifically:
>> 
>>• It aims to provide a solution for the archival of Swift struct and enum 
>> types
>>• It aims to provide a more type-safe solution for serializing to 
>> external formats, such as JSON and plist
>> Motivation
>> The primary motivation for this proposal is the inclusion of native Swift 
>> enum and struct types in archival and serialization. Currently, developers 
>> targeting Swift cannot participate in NSCoding without being willing to 
>> abandon enum and structtypes — NSCoding is an @objc protocol, conformance to 
>> which excludes non-class types. This is can be limiting in Swift because 
>> small enums and structs can be an idiomatic approach to model 
>> representation; developers who wish to perform archival have to either forgo 
>> the Swift niceties that constructs like enumsprovide, or provide an 
>> additional compatibility layer between their "real" types and their 
>> archivable types.
>> 
>> Secondarily, we would like to refine Foundation's existing serialization 
>> APIs (NSJSONSerialization and NSPropertyListSerialization) to better match 
>> Swift's strong type safety. From experience, we find that the conversion 
>> from the unstructured, untyped data of these formats into strongly-typed 
>> data structures is a good fit for archival mechanisms, rather than taking 
>> the less safe approach that 3rd-party JSON conversion approaches have taken 
>> (described further in an appendix below).
>> 
>> We would like to offer a solution to these problems without sacrificing ease 
>> of use or type safety.
>> 
>> Agenda
>> This proposal is the first stage of three that introduce different facets of 
>> a whole Swift archival and serialization API:
>> 
>>• This proposal describes the basis for this API, focusing on the 
>> protocols that users adopt and interface with
>>• The next stage will propose specific API for new encoders
>>• The final stage will discuss how this new API will interop with 
>> NSCoding as it is today
>> SE- provides stages 2 and 3.
>> 
>> Proposed solution
>> We will be introducing the following new types:
>> 
>>• protocol Codable: Adopted by types to opt into archival. Conformance 
>> may be automatically derived in cases where all properties are also Codable.
>>• protocol CodingKey: Adopted by types used as keys for keyed containers, 
>> replacing String keys with semantic types. Conformance may be automatically 
>> derived in most cases.
>>• protocol Encoder: Adopted by types which can take Codable values and 
>> encode them into a native format.
>>• class KeyedEncodingContainer: Subclasses of this 
>> type provide a concrete way to store encoded values by CodingKey. Types 
>> adopting Encoder should provide subclasses of KeyedEncodingContainer to vend.
>>• protocol SingleValueEncodingContainer: Adopted by types which 
>> provide a concrete way to store a single encoded value. Types adopting 
>> Encoder should provide types conforming to SingleValueEncodingContainer to 
>> vend (but in many cases will be able to conform to it themselves).
>>• protocol Decoder: Adopted by types which can take payloads in a native 
>> format and decode Codable values out of them.
>>• class KeyedDecodingContainer: S

Re: [swift-evolution] [Discussion] Simplifying case syntax

[Goffredo Marocchi via swift-evolution]

I would think that removing confusion and simplifying + rationalising the 
syntax IS the definition of a breaking change justified :). I do not see how 
Erica's proposal is in any way contrary to the philosophy behind the language 
or is removing anything people really depend on now (in terms of expressive 
ability).

This should be nowhere near as controversial as the removal of pre and post 
increments and C style for loops, quite a slam dunk actually.

Sent from my iPhone

> On 28 Feb 2017, at 23:45, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Agree. Design 1 seems like an improvement over the status quo. Barring 
> unexpected downsides to this, it's then a question of whether the 
> improvements are large enough to justify a breaking change.
> 
> 
>> On Tue, Feb 28, 2017 at 3:57 PM, David Hart via swift-evolution 
>>  wrote:
>> I’m happy that someone is trying to fix this small wart in the language. 
>> I’ve always wanted something like Design 1. It makes sense because we are 
>> already used to the pattern matching operator and we finally fix the 
>> inconsistencies between if/guard and switch.
>> 
>>> On 28 Feb 2017, at 20:01, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> The following draft proposal addresses one matter of substance (eliminating 
>>> edge case errors by adopting at-site conditional binding) and one of style 
>>> (using the pattern match operator consistently). Its discussion was 
>>> deferred from Phase 1 and remains in a fairly early stage. Your feedback 
>>> will help me decide whether this is a proposal I want to keep developing or 
>>> one that I should set aside and focus on other matters. Thank you. -- E
>>> 
>>> The work-in-progress gist is here:  
>>> https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c 
>>> 
>>> Simplifying case syntax
>>> Proposal: TBD
>>> Author: Erica Sadun
>>> Status: TBD
>>> Review manager: TBD
>>> Introduction
>>> 
>>> This proposal re-architects case syntax grammar to reduce potential errors 
>>> and simplify unwrapping enumerations. 
>>> 
>>> Swift-evolution thread: [Pitch] Reimagining guard case/if case
>>> 
>>> Motivation
>>> 
>>> In its current design, Swift case binding suffers from two weaknesses.
>>> 
>>> Mixed external and internal let/var binding may introduce errors from 
>>> uncommon edge cases.
>>> Real-world users may not consider the parallel construction between if 
>>> case/guard case with switchstatements or naturally connect the two layouts.
>>> Internal Case Binding
>>> 
>>> When pattern matching, it's common to bind a variable or constant. It's 
>>> uncommon but legal to use a bound value as an argument. Adopting an "always 
>>> explicit, always within the parentheses" rule adds consistency and safety 
>>> to Swift. 
>>> 
>>> Consider the following enumeration and values:
>>> 
>>> // An enum with one, two, or three associated values
>>> enum Value { case one(T), two(T, T), three(T, T, T) }
>>> 
>>> // An example with two associated values
>>> let example2: Value = .two("a", "b")
>>> 
>>> // A bound symbol
>>> let oldValue = "x"
>>> This code's goal is to conditionally bind newValue and pattern match the 
>>> value stored in the oldValue symbol. The first example succeeds. The second 
>>> example compiles and runs but does not match the coder's intent. Using an 
>>> external letcreates a new oldValue shadow instead of pattern matching 
>>> oldValue's stored value.
>>> 
>>> // Safe
>>> if case .two(let newValue, oldValue) = example2 { 
>>> ... 
>>> }
>>> 
>>> // Syntactically legal but incorrect
>>> if case let .two(newValue, oldValue) = example2 { 
>>> ... 
>>> }
>>> In-parenthesis binding avoids accidental shadowing. It eliminates this 
>>> class of error by adding let and var key words to each use point. This 
>>> creates longer call sites but enumerations rarely contain more than three 
>>> or four associated items.
>>> 
>>> Adopting point-of-use binding enhances clarity and readability. Both if 
>>> case let and if case var (plus case varand case let) may look like single 
>>> compound keywords rather than a combination of two distinct actions to 
>>> developers unfamiliar with this syntax.
>>> 
>>> Pattern Matching with Conditional Binding
>>> 
>>> Swift's guard case and if case align statement design with the switch 
>>> statement, moving the matched value to the right of an equal sign.
>>> 
>>> switch value {
>>> case .enumeration(let embedded): ...
>>> }
>>> 
>>> if case .enumeration(let embedded) = value
>>> The status quo for the = operator is iteratively built up in this fashion:
>>> 
>>> = performs assignment
>>> let x = performs binding
>>> if let x = performs conditional binding on optionals
>>> if case .foo(let x) = performs conditional binding on enumerations and 
>>> applies pattern matching
>>> Using if case/guard case in the absense of conditional binding duplicates 
>>> basic pattern matching with less obvious meaning. These two statements are 
>>> functionally identical:
>>> 
>>>

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

[Goffredo Marocchi via swift-evolution]

Hey Slava,

> On 22 Feb 2017, at 23:07, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Feb 21, 2017, at 4:19 PM, David Waite via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 21, 2017, at 2:27 AM, Joanna Carter  
>>> wrote:
>>> 
>>> But in the Swift world, we now have the ability to extend almost any type, 
>>> except Any and AnyObject, which appear to be protected by some deep and 
>>> dark mechanism within the compiler.  So, just as those two protocols cannot 
>>> be extended, should we not be looking at some generally available mechanism 
>>> to prevent extensibility of any type?
>>> 
>>> And, I am not talking visibility here, just extensibility ; somehow those 
>>> two concerns are often conflated and, I believe, this is the cause of much 
>>> of the "lively" discussion on visibility specifiers.
>> 
>> This is imho more of an issue with ABI and resiliency. If I can create an 
>> extension which adds a method to a type, and that type gains a method with 
>> that same signature in a later release, what is the behavior?
> 
> Extension methods are lexically scoped and statically dispatched, so existing 
> code will not be affected by the addition of the new method. New code will 
> call whichever method is visible, or if both are visible in a given lexical 
> scope and overload resolution rules cannot pick an unambiguous winner, the 
> code will no longer type check.

This situation seems pretty messy as, say with a binary framework one day, it 
may lead to someone conforming to a protocol and implementing a method that 
will never be called as it is silently overriding a default method only 
declared in an extension... and there are no warnings for that. 
I think that if the protocol or a protocol extension provides a default 
implementation a class conforming to it not being allowed to override it may 
actually help.

Not to mention how for many protocols should be abstract contracts not 
implementations, I cannot be the only one that enjoys returning to a situation 
where the code being executed depends on how I dress my instance and not what 
my instance is:
...objA is an instance of ClassA that conforms to ProtoA which also has a 
myMethod method and an extension which provides a default implementation of it.

objA.myMethod() 

vs

(objA as ProtoA).myMethod()

When did casting an instance to another type changes what code gets executed 
became ok and good practice again :)?

Default methods are serving a purpose and are allowing code sharing across 
structs, but IMHO they cause more harm than good with classes and OOP design 
while not being a necessary condition for POP either.


> 
> The situation is messier with extensions that add protocol conformances. 
> Right now we don’t do a good job of dealing with duplicate conformances 
> because we assume in several places in the compiler and runtime that they can 
> be looked up globally. We plan on addressing at least some of this.
> 
> Slava
> 
>> 
>>> 
 In C++ terms, it would be when I want some other class to have friend 
 access to a function/data, but for it not to be arbitrarily accessible by 
 subtypes
>>> 
>>> Indeed. I do wonder if some folks approach visibility control as an 
>>> exercise in "what can I see" whereas, demonstrated by C++ friends, it 
>>> becomes obvious that it is more about "what do I want to allow to be seen"
>>> 
>>> Is there not a value in forking this discussion into which keywords are 
>>> truly about visibility control and which are about extensibility control?
>> 
>> Possibly; they are two axes. However, I’m hoping that new access modifiers 
>> (including possible submodule functionality) + extensibility modifiers are 
>> considered holistically. 
>> 
>> For instance, if there is a feature that allows something comparable to 
>> ‘friend’ level access, a restrictive private makes a lot more sense than one 
>> with exceptions allowing access to subtypes, within the same file, to 
>> extensions, etc. A restrictive, scoped private would be what you use to 
>> protect the invariants of your type, with less protected methods given to 
>> allow extensions and internal modification safely.
>> 
>> But without a submodule or similar access level, we need a “fileprivate” 
>> level access (renamed to ‘private’ or not) to make sure code needing a 
>> higher level of access can get it, by being embedded in the same file.
>> 
>>> OK, how does this sound?
>>> 
>>> Extend the 'final' concept, currently used only in classes, to protect any, 
>>> non-protocol, type from being extended.
>> 
>> The extension mechanism, both being able to add new methods and to conform 
>> an existing class to a protocol retroactively, is absurdly powerful. It 
>> doesn’t offer any privileged manipulation of types today that would give a 
>> safety related reason to restrict it. I’d be reluctant to let someone take 
>> that away from me personally without a strong language-level justification 
>> (such as needing to restrict it partial

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[Goffredo Marocchi via swift-evolution]

Well said, thanks for taking time to post this :).

Sent from my iPhone

> On 22 Feb 2017, at 19:34, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> This is bad faith. The original discussion contains many real life example.
> "bad faith"? Really? If we have the same interpretation of this phrase in our 
> dictionaries, it's only fitting here as attribute for the sentence following 
> it.
> I took a position that is extremely easy to attack, yet the only counter 
> argument is the claim that there are many real life examples (instead of 
> citing a single one). That's just "alternative facts", and it tells a lot 
> about the actual power of the arguments that are used to justify forbidding 
> subclassing.
> Afaik, there hasn't been a single real life example by those who fought for 
> "final by default", and it took quite a long time until someone from core 
> came up with a scenario which illustrated a disadvantage of non-final classes 
> in a lib — but that example had bad (worse) consequences in a 
> final-by-default setup as well, so it wasn't convincing for me.
> 
> First step in discussion should be agreeing on facts, and in this discussion, 
> imho the most important fact is that this actually isn't about facts at all, 
> but rather about opinion and personal preferences:
> When someone suggests to rename the keyword "func" to "fn" or "function", it 
> is ridiculous to argue that either choice is better, and the same is true for 
> this topic (it just has bigger consequences).
> When you actually read the original discussion, I expect you will find more 
> false claims and questionable tactics from both parties than valuable 
> examples, and this drags down the quality of the debate.
> 
>> You just don’t want to admit open is useful for many library writers.
> 
> Of course open is extremely useful for library writers — especially for those 
> who write libraries that are intended to be actually used…
> Did anyone question that? (I guess the title of the thread can be a little 
> bit irritating, but afaics, it is only the keyword that should be removed, 
> not the feature itself).
> 
> As I told the author of this draft, I can only tell its opposers as well:
> Just relax and admit that you are not fighting for the better choice, but 
> only for the one you like better.
> 
> (btw, that is the case for a lot of decisions:
> Typed throws aren't better than untyped ones, zero-based arrays aren't better 
> than 1-based arrays, functional programming isn't better than POP or OO, 
> composition isn't better than inheritance, structs aren't better than 
> classes… the strongest statement you can make for some of those alternatives 
> is that they perform better in specific situations)
> ___
> 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] Argument labels in callbacks

[Goffredo Marocchi via swift-evolution]

I remember it and remember the disagreements over this simplification too, but 
I really hope this is now not skipping a full year again.

Sent from my iPhone

> On 22 Feb 2017, at 08:49, Charlie Monroe  wrote:
> 
> This was pointed out during the discussions surrounding this proposal and it 
> was agreed that the type simplification was important.
> 
> There were several suggestions how to bring this back using different 
> features - e.g. compound names that would contain the labels. For example:
> 
> let callback(success:error:): (Bool, Error?) -> Void = ...
> callback(success: true, error: nil)
> 
> This way the type itself wouldn't contain the label information, but the name 
> of the variable would.
> 
>> On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> I am quite interested in this as well, thanks for bringing it up! It was 
>> quite disappointing to fall back to multi argument method calls without 
>> labels as it was going against the emphasis on the value of labels in the 
>> language as well as decreasing readability of what is supposed to be self 
>> documenting code.
>> 
>> Sent from my iPhone
>> 
>>> On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> When SE-0111 was approved, I noticed the implication it had when using 
>>> closures as callbacks:
>>> 
>>> Writing
>>>func foo(completion: (success: Bool) -> Void) {
>>>  completion(success: true)
>>>}
>>> 
>>> is no longer possible, because function types can’t have argument labels 
>>> anymore, and the function has to be written:
>>>func foo(completion: (Bool) -> Void) {
>>>  completion(true)
>>>}
>>> 
>>> which doesn’t look very nice, especially as the number of the arguments 
>>> increases.
>>> 
>>> After talking to Chris Lattner about this, he referred me to this email.
>>> I was wondering if there's been any further work or plans in restoring the 
>>> use of argument labels in closures.
>>> 
>>> - Franklin
>>> ___
>>> 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] Argument labels in callbacks

[Goffredo Marocchi via swift-evolution]

I am quite interested in this as well, thanks for bringing it up! It was quite 
disappointing to fall back to multi argument method calls without labels as it 
was going against the emphasis on the value of labels in the language as well 
as decreasing readability of what is supposed to be self documenting code.

Sent from my iPhone

> On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution 
>  wrote:
> 
> Hi,
> 
> When SE-0111 was approved, I noticed the implication it had when using 
> closures as callbacks:
> 
> Writing
>func foo(completion: (success: Bool) -> Void) {
>  completion(success: true)
>}
> 
> is no longer possible, because function types can’t have argument labels 
> anymore, and the function has to be written:
>func foo(completion: (Bool) -> Void) {
>  completion(true)
>}
> 
> which doesn’t look very nice, especially as the number of the arguments 
> increases.
> 
> After talking to Chris Lattner about this, he referred me to this email.
> I was wondering if there's been any further work or plans in restoring the 
> use of argument labels in closures.
> 
> - Franklin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[Goffredo Marocchi via swift-evolution]

Maybe some people disagree with the emphasis on the library writer POV and from 
a user perspective of other people's libraries they have been accustomed to how 
you can be trusted with enough responsibility to either fix a behaviour in the 
binary lib you have been given or modify the sequence of some events for user 
flow reasons. Let's not act like a lot of people did never benefit from method 
swizzling at runtime (quite often it is popular libraries we use that do that 
for us, but it can be an invaluable tool as many other features of the 
Objective-C runtime... there is a reason why UI programming and rapid 
prototyping are massively more enjoyable in more dynamic languages like 
JavaScript, ruby, and Objective-C).

Sent from my iPhone

> On 22 Feb 2017, at 07:15, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
>>> Le 21 févr. 2017 à 17:19, Tino Heth via swift-evolution 
>>>  a écrit :
>>> 
>>> 
>>> I’ll concede that the proposal makes a claim that might very well be 
>>> disproved. I would very much like to see an actual example of a public 
>>> class that **has** to be public but **shouldn’t** be open for obvious 
>>> reasons. I would happily accept being shown wrong on that point.
>> This is afaics one of the most active disputes on evolution — and you can 
>> save you a lot of grief by accepting that it is pointless:
>> The whole discussion isn't based on facts at all, despite many false claims 
>> that marking things as final is generally better.
>> I have asked for a single example to prove this in the past as well, so I 
>> guess no one can present such a thing to you.
> 
> This is bad faith. The original discussion contains many real life example. 
> You just don’t want to admit open is useful for many library writers.
> 
>> It is personal preference, so arguments don't help much here.
>> 
>> Maybe it helps to know the whole story, as everything started with "final 
>> should be default", followed by a try to forbid subclassing for types from a 
>> different module by default, finally arriving at the current compromise 
>> where you have to decide wether module clients should be allowed to subclass 
>> or not.
>> Nobody ever requested that public should be the only access level, so there 
>> has been only been pressure applied from one direction — it's interesting to 
>> see some backlash now.
>> Imho people already were quite tired of discussion when public/open was 
>> accepted as a compromise...
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[Goffredo Marocchi via swift-evolution]

To those people I would say use final or let's change public to mean the 
current open and replace open with 'module'...

I liked open by default and this not needing open in the first place... you 
guys got me here ;).

Sent from my iPhone

> On 21 Feb 2017, at 07:02, David Hart via swift-evolution 
>  wrote:
> 
> I think this proposal will receive a lot of pushback and that the use case 
> for having a class that is subclassable inside its module but not 
> subclassable outside the module is more frequent than you think.
> 
>> On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Here’s a draft proposal following 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html.
>> The idea is simplify Swift’s syntax by getting rid of the `open` access 
>> modifier.
>> 
>> A rendered version of the proposal is available here: 
>> https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md
>> The raw version follows:
>> 
>> # Remove open Access Modifier
>> 
>> * Proposal: [SE-](-remove-open-access-modifier.md)
>> * Author: [Dimitri Racordon](https://github.com/kyouko-taiga), Joanna Carter
>> * Status: **Awaiting review**
>> * Review manager: TBD
>> 
>> ## Introduction
>> 
>> Swift allows classes, methods, properties and subscripts to be marked as 
>> `final`, hence disallowing their subclassing/overriding inside **and** 
>> outside of their defining module.
>> 
>> It also features two access levels `open`, which allows an entity to be 
>> accessed outside its defining module, and `public`, which gives the same 
>> access level the former **and** allows the entity to be 
>> subclassed/overridden.
>> 
>> There's a clear overlap between `open` and `public`, as they essentially 
>> represent the same access control within the boundaries of a module, and do 
>> not add any benefit from outside them, as `final` is sufficient to prohibit 
>> subclassing/overriding.
>> 
>> Swift-evolution thread: ['Public' class visibility 
>> specifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html)
>> 
>> 
>> ## Motivation
>> 
>> Swift has currently 5 access levels, in the form of:
>> 
>> * `private`, restricting the use of an entity to its enclosing declaration;
>> * `fileprivate`, restricting the use of an entity to its defining source 
>> file:
>> * `internal`, restricting the use of an entity to its defining module;
>> * `public`, allowing the entity to be accessed anywhere;
>> * `open`, allowing the entity to be accessed anywhere **and** allowing the 
>> entity to be subclassed/overridden outside of their defining module.
>> 
>> From inside a module, `open` and `public` represent exactly the same access 
>> level (everything is visible **and** can be subclassed/overridden).
>> From outside a module, `public` is actually akin to `final`.
>> 
>> ```swift
>> // Module 1
>> // 
>> 
>> open class OpenClass {}
>> public class PublicClass {}
>> 
>> public final class PublicFinalClass {}
>> 
>> // The first two classes above have the same access level.
>> class derivedFromOpen: OpenClass {}
>> class derivedFromPublic: PublicClass {}
>> 
>> // Module 2
>> // 
>> 
>> class derivedFromOpenOutside: OpenClass {}
>> 
>> class derivedFromPublicOutside: PublicClass {}
>> // Error: Cannot inherit from non-open class ...
>> 
>> class derivedFromPublicFinalOutside: PublicFinalClass {}
>> // Error: Inheritance from a final class ...
>> ```
>> 
>> Hence, the sole use-case of using both `public` and `final` is for an entity 
>> that *inside* its defining module should not be subclassed/overridden.
>> 
>> ```swift
>> // Module 1
>> // 
>> 
>> class derivedFromPublicFinal : PublicFinalClass {}
>> // Error: Inheritance from a final class ...
>> ```
>> 
>> We believe this use case is rare and not worth the additional complexity of 
>> having an `open` access level in the language.
>> Besides, `open` is only applicable on classes and class members while the 
>> others can be used on other entities (protocols, structures, ...).
>> This asymmetry adds to the complexity of an `open` access level.
>> 
>> In order to simplify the syntax of Swift, we propose to **remove the `open` 
>> access modifier**.
>> 
>> ## Proposal
>> 
>> Remove the `open` access modifier from Swift.
>> 
>> ## Source compatibility
>> 
>> This is a breaking change, as the `open` keyword would disappear from the 
>> language.
>> However, a fixit would be quite easy to put in place, simply replacing 
>> `open` with `public`.
>> 
>> ## Alternative considered
>> 
>> Not removing the `open` access modifier from the language and keep the 
>> status quo.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> s

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

[Goffredo Marocchi via swift-evolution]

Thanks for the suggestion, I will give it some thought and may others will do 
the same.

My issue with this topic is that I feel there is a lot of emotion but not yet a 
clear agreed best path forward. We should also think about design and 
implementation opportunity cost, what are we not addressing/focusing 
on/designing by focusing on arguing loudly about reverting a change set?

Sent from my iPhone

> On 20 Feb 2017, at 09:15, Rien  wrote:
> 
> 
> 
> 
> 
>> On 20 Feb 2017, at 09:39, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> Please, almost anything but going back to the horrible Objective-C pattern 
>> of private headers (that end up included on in the implementation files) :/.
> 
> Why not a best of both worlds?
> 
> Everything is open inside the project unless marked private (in the swift 2 
> sense, i.e. fileprivate)
> 
> If a project/module exports a library, the same applies, unless there is a 
> “library access level control file”.
> 
> If a "library access level control file” is present, all external access 
> defaults to private unless disclosed in the “library access level control 
> file”.
> 
> With proper IDE support, creating a "library access level control file” would 
> require only minimal effort.
> 
> This would allow cleaner source code as you do not have to specify every 
> access level all the time, reduces cognitive load during programming and 
> debugging, fits nicely in the progressive disclosure strategy, creates a more 
> readable interface for API users etc etc.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
>> 
>> Seriously, that was always my issue with that blog post, assuming that the 
>> Objective-C way of dealing with this issue was something worth moving 
>> forward and not a path to massively improve upon or to avoid.
>> 
>> Sent from my iPhone
>> 
>>> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>>> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution 
>>>>  wrote:
>>>> 
>>>> A third point (which is a bit more complex/convoluted) is that fileprivate 
>>>> remained an essential language feature because it allows implementation in 
>>>> extensions, and allows a simple “friend”-like feature where types that 
>>>> need access to implementation details due to higher coupling could be 
>>>> bundled into the same file. Outside of a desire of a scoped ‘private’ 
>>>> simply to match the behavior of certain other languages, private is used 
>>>> to hide implementation details from other parts of a file, while file 
>>>> private exposes them within the file. 
>>>> 
>>>> There is a potential that file-private can lead to an explosion of 
>>>> complexity due to a large amount of “friendly types” being bundled into 
>>>> the same file. In that sense, ‘private’ was wrong because it was adding 
>>>> complexity at the file level, when really a new access level would 
>>>> possibly have been more productive to define at the at the 
>>>> small-group-of-files level - either via a friend access level or 
>>>> submodules. We still have the potential of unmanageable files due to 
>>>> friend types, but any additional access levels to aid with this problem 
>>>> would have to be weighed against a now significantly more complex access 
>>>> model including file and scoped private. In that sense, the inclusion of 
>>>> scoped private may indeed be harmful in that it increases the challenge of 
>>>> much more useful access levels being added to the language.
>>> 
>>> This is the core of what I have been saying.  If we don’t address this need 
>>> of “friendly types” in a swift-y way, we will have to keep coming back to 
>>> the drawing board (either for “friend” or “protected” or “submodules”).  I 
>>> really like swift 2 private, but it did cause long files because all of the 
>>> extensions and friends had to be stuck in the same file. What we are really 
>>> missing is something that has the connotation similar to private, but 
>>> allows access where needed.
>>> 
>>> I agree with most of what was said in this blog post from the swift devs:
>>> https://developer.apple.com/swift/blog/?id=11
>>> 
>>> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
>>> wh

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

[Goffredo Marocchi via swift-evolution]

Ok, on this I can agree... and I will. It try to mention how judging things by 
how "Swifty" they are makes us seem like a cult... but then again we are 
programmers/engineers... that word may very well apply appropriately :).

Sent from my iPhone

> On 20 Feb 2017, at 08:46, Jonathan Hull  wrote:
> 
> I didn’t say we should have headers, I said we need something that maps to 
> those use cases in a swift-y way.
> 
> Just being able to mark something as internal to the type, and a way to 
> opt-in to seeing those things within a particular file.
> 
> Thanks,
> Jon
> 
>> On Feb 20, 2017, at 12:39 AM, Goffredo Marocchi  wrote:
>> 
>> Please, almost anything but going back to the horrible Objective-C pattern 
>> of private headers (that end up included on in the implementation files) :/.
>> 
>> Seriously, that was always my issue with that blog post, assuming that the 
>> Objective-C way of dealing with this issue was something worth moving 
>> forward and not a path to massively improve upon or to avoid.
>> 
>> Sent from my iPhone
>> 
>>> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution 
  wrote:
 
 A third point (which is a bit more complex/convoluted) is that fileprivate 
 remained an essential language feature because it allows implementation in 
 extensions, and allows a simple “friend”-like feature where types that 
 need access to implementation details due to higher coupling could be 
 bundled into the same file. Outside of a desire of a scoped ‘private’ 
 simply to match the behavior of certain other languages, private is used 
 to hide implementation details from other parts of a file, while file 
 private exposes them within the file. 
 
 There is a potential that file-private can lead to an explosion of 
 complexity due to a large amount of “friendly types” being bundled into 
 the same file. In that sense, ‘private’ was wrong because it was adding 
 complexity at the file level, when really a new access level would 
 possibly have been more productive to define at the at the 
 small-group-of-files level - either via a friend access level or 
 submodules. We still have the potential of unmanageable files due to 
 friend types, but any additional access levels to aid with this problem 
 would have to be weighed against a now significantly more complex access 
 model including file and scoped private. In that sense, the inclusion of 
 scoped private may indeed be harmful in that it increases the challenge of 
 much more useful access levels being added to the language.
>>> 
>>> This is the core of what I have been saying.  If we don’t address this need 
>>> of “friendly types” in a swift-y way, we will have to keep coming back to 
>>> the drawing board (either for “friend” or “protected” or “submodules”).  I 
>>> really like swift 2 private, but it did cause long files because all of the 
>>> extensions and friends had to be stuck in the same file. What we are really 
>>> missing is something that has the connotation similar to private, but 
>>> allows access where needed.
>>> 
>>> I agree with most of what was said in this blog post from the swift devs:
>>> https://developer.apple.com/swift/blog/?id=11
>>> 
>>> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
>>> where a second header was used (it doesn’t, and that is what is causing all 
>>> of this trouble).  Because internal is the default, it feels much too easy 
>>> to accidentally use parts of a type which should only be used by 
>>> extensions/subclasses/friend types. Remember, in an app (as opposed to a 
>>> framework), internal is basically equivalent to public.  With the second 
>>> header, users of the contents of that header had to explicitly include it, 
>>> which meant there was no chance of accidental use.
>>> 
>>> What we need is something which maps to that second header case while still 
>>> keeping everything conceptually simple and swift-y.
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Please, almost anything but going back to the horrible Objective-C pattern of 
private headers (that end up included on in the implementation files) :/.

Seriously, that was always my issue with that blog post, assuming that the 
Objective-C way of dealing with this issue was something worth moving forward 
and not a path to massively improve upon or to avoid.

Sent from my iPhone

> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
>  wrote:
> 
> 
>> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution 
>>  wrote:
>> 
>> A third point (which is a bit more complex/convoluted) is that fileprivate 
>> remained an essential language feature because it allows implementation in 
>> extensions, and allows a simple “friend”-like feature where types that need 
>> access to implementation details due to higher coupling could be bundled 
>> into the same file. Outside of a desire of a scoped ‘private’ simply to 
>> match the behavior of certain other languages, private is used to hide 
>> implementation details from other parts of a file, while file private 
>> exposes them within the file. 
>> 
>> There is a potential that file-private can lead to an explosion of 
>> complexity due to a large amount of “friendly types” being bundled into the 
>> same file. In that sense, ‘private’ was wrong because it was adding 
>> complexity at the file level, when really a new access level would possibly 
>> have been more productive to define at the at the small-group-of-files level 
>> - either via a friend access level or submodules. We still have the 
>> potential of unmanageable files due to friend types, but any additional 
>> access levels to aid with this problem would have to be weighed against a 
>> now significantly more complex access model including file and scoped 
>> private. In that sense, the inclusion of scoped private may indeed be 
>> harmful in that it increases the challenge of much more useful access levels 
>> being added to the language.
> 
> This is the core of what I have been saying.  If we don’t address this need 
> of “friendly types” in a swift-y way, we will have to keep coming back to the 
> drawing board (either for “friend” or “protected” or “submodules”).  I really 
> like swift 2 private, but it did cause long files because all of the 
> extensions and friends had to be stuck in the same file. What we are really 
> missing is something that has the connotation similar to private, but allows 
> access where needed.
> 
> I agree with most of what was said in this blog post from the swift devs:
> https://developer.apple.com/swift/blog/?id=11
> 
> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
> where a second header was used (it doesn’t, and that is what is causing all 
> of this trouble).  Because internal is the default, it feels much too easy to 
> accidentally use parts of a type which should only be used by 
> extensions/subclasses/friend types. Remember, in an app (as opposed to a 
> framework), internal is basically equivalent to public.  With the second 
> header, users of the contents of that header had to explicitly include it, 
> which meant there was no chance of accidental use.
> 
> What we need is something which maps to that second header case while still 
> keeping everything conceptually simple and swift-y.
> 
> Thanks,
> Jon
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution