Re: [swift-evolution] [pitch] adding toggle to Bool

[Cheyo Jimenez via swift-evolution]

> On Jan 12, 2018, at 12:14 AM, Nate Cook via swift-evolution 
>  wrote:
> 
> 
>> On Jan 12, 2018, at 12:15 AM, Chris Eidhof via swift-evolution 
>>  wrote:
>> 
>> Hey SE!
>> 
>> When we have a bunch of nested structs:
>> 
>> struct Sample {
>> var bar: Bar
>> }
>> 
>> struct Bar {
>> var show: Bool
>> }
>> 
>> var foo = Sample(bar: Bar(show: false))
>> 
>> It can be repetitive to toggle a deeply nested boolean:
>> 
>> foo.bar.show = !foo.bar.show // duplication
>> 
>> I sometimes add a `toggle` extension on `Bool`
>> 
>> extension Bool {
>> mutating func toggle() {
>> self = !self
>> }
>> }
>> 
>> This allows you to write the same code without duplication, and makes the 
>> intent clearer:
>> 
>> foo.bar.show.toggle()
> 
> I like it!
> 
>> In other languages, I don't think the `toggle` would make as much sense, but 
>> the mutable self makes this very useful.
>> 
>> After I posted it on Twitter, it turns out I'm not the only one: 
>> https://twitter.com/PublicExtension/status/730434956376346624
>> 
>> I would have gone straight to a proposal, but I think we can do some 
>> bikeshedding about the name of `toggle`?
> 
> Another verb that could work is `invert`.

That’s a good one. Similar to bit flipping which Apple calls inverting. 

“The bitwise NOT operator (~) inverts all bits in a number:”

I was thinking `flip` for this function but then I actually don’t think this 
extension is a good idea in the standard library :(

Should we also have a mutating extension for the `NOT` operator? Probably no. 

If people need it, they can add it and call it toggle, invert, flip, reverse, 
negate or what ever they want.  

It’s a slippery slope because it makes me want to have something like `not()` 
added to the library. I don’t think it’s worth it. 



> 
> The `!` operator that does this is the negation operator, but I think 
> `negate` could sound to some like "make this false" rather than toggling. 
> 
> Nate
> ___
> 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-0194: Derived Collection of Enum Cases

[Cheyo Jimenez via swift-evolution]

On Jan 10, 2018, at 8:22 AM, Paul Cantrell via swift-evolution 
 wrote:

>> What is your evaluation of the proposal?
> 
> +1. Yes please. Long overdue.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
> fits my own experience: I’ve wanted this on multiple occasions.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, and in particular, on the name bikeshedding:
> 
> I favor property names with the “all” prefix, whether allValues or allCases. 
> Looking over my own code, I’ve almost always used the word “all” for this 
> when I had to hand-roll it — and either allValues or allCases make reasonable 
> sense in my code when I substitute them.
> 
> Whichever protocol name we choose, the property name should be consistent:
> 
>   ValueEnumerable → allValues
>   CaseEnumerable → allCases

this is good point. I think it would be awesome to also have a compile time 
version named .cases.

.allCases would include unknown cases at runtime.
.cases would only include known at compile time cases. 


> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
> I slightly prefer ValueEnumerable, because it extends to situations where we 
> still want to enumerate a fixed set of possibilities which don’t strictly 
> correspond to enum cases but still have that sort of flavor. For example, one 
> might want:
> 
> enum SideOfBody
>   {
>   case left
>   case right
>   }
> 
> enum Limb: ValueEnumerable
>   {
>   case arm(SideOfBody)
>   case leg(SideOfBody)
> 
>   static let allValues =
> [
> arm(.left),
> arm(.right),
> leg(.left),
> leg(.right)
> ]
>   }
> 
> To my eyes, this code reads better than it would with CaseEnumerable / 
> allCases.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> 
> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
> feature has always worked nicely. Java’s design is slightly different: 
> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
> that name or type choice: (1) Java doesn’t use the term “case” as Swift does, 
> (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a 
> concrete array type has as opposed to Collection has different implications 
> in Java than it does Swift.
> 
> I _do_ agree  that the proposal should consider constraining the Collection 
> to be Int-indexed. Why should it ever be otherwise? What’s the motivation for 
> leaving that open?
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Medium quick study.
> 
> Cheers, P
> 
> ___
> 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]

[Jose Cheyo Jimenez via swift-evolution]

On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner  wrote:

> On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez 
> wrote:
> > Hi Chris,
> >
> > This is great. Thanks for spending time on this! I am in favor of `case
> #unknown` to only match unknown cases.
> >
> > 1) Would #uknown be available to RawRepresentable structs?
>
> I haven’t considered this, so I’m not sure how that would work.  I had
> assumed that this would be an enum specific concept.
>
> What do you have in mind?  If your raw representation is itself an enum,
> then of course this would work.
>

I was just curious since a RawRepresentable structs ( and OptionSet ) are
very similar to non exhaustive enums in that they would require handling
unknown cases. Currently RawRepresentable is required to use a default even
if all cases are accounted for.

struct Directions: OptionSet {
let rawValue: UInt8
static let up= Directions(rawValue: 1 << 0)
}

let myDir = Directions.up

switch myDir
{
case .up : print("matched")
default: print("default required")
}



> > 2) How is the #uknown pattern accomplished? Are you suggesting to
> capture all the compile time known cases so you can do a diff during
> > runtime? (Sorry this is not obvious to me)
>
> The internals of the compiler would handle this, it is difficult to
> explain unless you know the bowels of silgen and irgen :-)
>
> -Chris
>
>
>
___
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]

[Jose Cheyo Jimenez via swift-evolution]

Hi Chris,

This is great. Thanks for spending time on this! I am in favor of `case
#unknown` to only match unknown cases.

1) Would #uknown be available to RawRepresentable structs?

2) How is the #uknown pattern accomplished? Are you suggesting to capture
all the compile time known cases so you can do a diff during
runtime? (Sorry this is not obvious to me)

Previously I suggested having something like `case #known` that would only
match known cases by capturing known cases at compile time ( maybe using a
compile-time variation of
https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md).
This would give us the equivalent of `case _` == `case #known` + `case
#unknown`.  The only issue I found with `case #known`  is that it would be
the same as `case _` when working with an exhaustive enum.

switch myEnum{
case .X :   //
case .Y :   //
case #unknown : // Matches all runtime unknown cases
case #known : //  Matches all compile known cases
}

On Mon, Jan 8, 2018 at 10:54 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> The mega-thread about SE-0192 is a bit large, and I’d like to talk about
> one specific point.  In the review conversation, there has been significant
> objection to the idea of requiring a ‘default’ for switches over enums that
> are non-exhaustive.
>
> This whole discussion is happening because the ABI stability work is
> introducing a new concept to enums - invisible members/inhabitants (and
> making them reasonably prominent).  A closely related feature is that may
> come up in the future is "private cases”.  Private cases are orthogonal to
> API evolution and may even occur on one that is defined to be exhaustive.
>
> Private cases and non-exhaustive enums affect the enum in the same way:
> they say that the enum can have values that a client does not know about.
> Swift requires switches to process *all* of the dynamically possible
> values, which is why the original proposal started out with the simplest
> possible solution: just require ‘default' when processing the cases.
>
>
> *The problems with “unknown case:”*
>
> The popular solution to this probably is currently being pitched as a
> change to the proposal (https://github.com/apple/swift-evolution/pull/777)
> which introduces a new concept “unknown case” as a near-alias for ‘default’:
> https://github.com/jrose-apple/swift-evolution/blob/
> 60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-
> exhaustive-enums.md#unknown-case
>
> In short, I think this is the wrong way to solve the problem.  I have
> several concerns with this:
>
> 1) Unlike in C, switch is Swift is a general pattern matching facility -
> not a way of processing integers.  It supports recursive patterns and
> values, and enums are not necessarily at the top-level of the pattern.
> https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a
> document from early evolution of Swift but contains a good general
> introduction to this.
>
> 2) Swift also has other facilities for pattern matching, including ‘if
> case’.  Making switch inconsistent with them is not great.
>
> 3) As pitched, “unknown case” will match *known* cases too, which is (in
> my opinion :-) oxymoronic.
>
> 4) “unknown case:” changes the basic swift grammar (it isn’t just a
> modifier on case) because case *requires* a pattern.  A better spelling
> would be “unknown default:” which is closer to the semantic provided anyway.
>
> 5) It is entirely reasonable (though rare in practice) to want to handle
> default and unknown cases in the same switch.
>
>
> For all the above reasons, ‘unknown case:' becomes a weird wart put on the
> side of switch/case, not something that fits in naturally with the rest of
> Swift.
>
>
> *Alternative proposal:*
>
> Instead of introducing a new modifier on case/switch, lets just introduce
> a new pattern matching operator that *matches unknown cases*, called
> “#unknown” or “.#unknown” or something (I’m not wed to the syntax, better
> suggestions welcome :).
>
> In the simple case most people are talking about, instead of writing
> “unknown case:” you’d write “case #unknown:” which isn’t much different.
> The nice thing about this is that #unknown slots directly into our pattern
> matching system.  Here is a weird example:
>
> switch someIntEnumTuple {
> case (1, .X):   … matches one combination of int and tuple...
> case (2, .Y):   … matches another combination of int and tuple...
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case default:  … matches anything ...
> }
>
> Furthermore, if you have a switch that enumerates all of the known cases
> and use #unknown, then it falls out of the model that new cases (e.g. due
> to an SDK upgrade or an updated source package) produces the existing build
> error.  As with the original proposal, you can always choose to use
> “default:” instead of “case #unknown:” if you don’t like that behavior.
>
> Of course, 

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

[Cheyo Jimenez via swift-evolution]

> On Jan 9, 2018, at 10:43 AM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>> 
>> What is your evaluation of the proposal?
> +1 on the general problem, but I have a few comments on the design specifics
> 
> - I'd very much prefer automatic synthesis with enums, 
> - I strongly feel the compiler should auto-generate the implementation in an 
> extension for enums.
> - Should we add `ValueCollection.Index == Int` to the associatedtype so it 
> can always be indexed as in a table? 
>   - At the least, we should ensure the synthesized implementation is 
> int-indexed for tables.
> - I feel we should allow auto-generation of imported c enums in an extension, 
> as just an array of the known cases rather than the magical metadata iterator 
> if necessary. 
> 
+1 for known cases at compile time. 


>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Definitely. It's been a gaping hole in the language since the beginning.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> I prefer Java's automatic allValues(), but this is better than nothing.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> Followed at least the start of several threads and read the proposal.
> ___
> 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-0194: Derived Collection of Enum Cases

[Cheyo Jimenez via swift-evolution]

> What is your evaluation of the proposal?
+1
How does this work with public non exhaustive enums?

Can we have a version of this that is compile time only? This would be very 
helpful specially if non exhaustive enums make it into the language. Perhaps 
also having compile time allCases could also gets us closer to objc enum 
support. 

I much rather take the extra copy of all the cases in my binary than having 
surprising results during runtime (new cases or removed cases).

> 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?
N/a
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Followed the first PR and most of the discussions. ___
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

[Cheyo Jimenez via swift-evolution]

> On Jan 4, 2018, at 4:37 PM, Xiaodi Wu  wrote:
> 
> 
> On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez  wrote:
>>> On Jan 4, 2018, at 3:50 PM, Xiaodi Wu  wrote:
>>> 
>>> 
>>> On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez  wrote:
 
> On Jan 4, 2018, at 2:55 PM, Xiaodi Wu  wrote:
> 
> 
> On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez  wrote:
>>> On Jan 4, 2018, at 11:53 AM, Xiaodi Wu  wrote:
>>> 
>>> 
 On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez  wrote:
 
 
> On Jan 4, 2018, at 10:49 AM, Jordan Rose  
> wrote:
> 
> I'll admit I hadn't thought of using "unknown default" (or "default 
> unknown"). I don't think that's terrible, but I mildly prefer 
> `unknown case` because it builds on the "pun" that enum elements are 
> also defined using 'case'. If anything hits this part of the switch, 
> it really will be an "unknown case", i.e. a statically-unknown enum 
> element.
> 
> To Cheyo's point, if this were to be a single token I'd probably 
> spell it #unknown, like #available. Then we'd have `case #unknown:` 
> and something that naturally expands to other pattern positions. I 
> found that less aesthetically pleasing, though, and so a 
> context-sensitive keyword seemed like the way to go.
> 
> (For the record, though, I wouldn't describe `case _` as a special 
> case of `default`. They do exactly the same thing, and `_` is a 
> useful pattern in other contexts, so if anything the current 
> `default` should be thought of as syntactic sugar for `case _`.)
 
 Can case _ be mixed with unknown case? How can we match all compile 
 time known cases but exclude future cases?
>>> 
>>> What’s your use case for that? That eliminates the possibility of 
>>> “unknown case” giving you compile-time warnings for subsequently added 
>>> cases, which was the entire purpose of adding the syntax in the first 
>>> place.
>> 
>> I was thinking of a generalized `unknown case` pattern but that is out 
>> of scope for this proposal. 
>> 
>> switch excuse {
>>  case .eatenByPet :
>>//…
>>  unknown case:
>>// …
>>  case _:
>>// …
>>  }
>> 
>>> 
 Should there be something like `case *` that would capture all 
 currently known cases during compile time? case * and case _ would be 
 the same in exhaustive enums. 
>> 
>> This is why I was suggesting another pattern that only captures known 
>> cases at compile time:
>> 
>> switch excuse {
>>  case .eatenByPet :
>>//…
>>  case * : //  All cases captured at compile time. 
>>// …
>>  unknown case:
>>// …
>>  }
> 
> Sorry, I don’t understand. However you spell it, what is your use case 
> for this? The stated purpose of “unknown case” is to gain compile-time 
> exhaustiveness testing, but this would not allow for that.
 
 
 
 
 switch (excuse, notifiedTeacherBeforeDeadline) {
 case (.eatenByPet, true):
   // …
 case (.thoughtItWasDueNextWeek, true):
   // …
 case (unknown case, true):
   // …
 case (_, false):
   // …
 }
 
 Im referring to the future direction section in the new PR. The above 
 example if from there. 
 
 I am fine with `unknown case` being required to be at the end of the 
 switch for now. 
 
 I think of `unknown case` as a pattern that only matches unknown cases no 
 matter where on the switch it is.
 
 This is why I do not think that `default unknown` would work well once 
 `unknown case` can be used a pattern.
 
 We can start a new thread on this if you’d like. 
>>> 
>>> The reason I put forward “default unknown” is precisely because the 
>>> proposed feature *cannot* be used in a pattern and therefore seems more apt 
>>> as not a case.
>>> 
>> 
>> It can not be used in a pattern now but you could in the future if left as 
>> `case`. 
>> 
>> 
>>> It actually makes it more natural to use in the given example above because 
>>> “default unknown” could actually be used to provide compile-time 
>>> exhaustiveness checking for such a tuple pattern, whereas without being 
>>> able to use “unknown case” in a pattern you can’t write “case (unknown 
>>> case, _)”.
>> 
>> The way `unknown case` enforces  compile-time exhaustiveness is by only 
>> matching unknown cases. The implementation may be more close to default by 
>> the virtue of being forced to go at the end of the switch statement now but 
>> that should not dictate the user experience. 
> 
> We seem to 

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

[Cheyo Jimenez via swift-evolution]

> On Jan 4, 2018, at 10:49 AM, Jordan Rose  wrote:
> 
> I'll admit I hadn't thought of using "unknown default" (or "default 
> unknown"). I don't think that's terrible, but I mildly prefer `unknown case` 
> because it builds on the "pun" that enum elements are also defined using 
> 'case'. If anything hits this part of the switch, it really will be an 
> "unknown case", i.e. a statically-unknown enum element.
> 
> To Cheyo's point, if this were to be a single token I'd probably spell it 
> #unknown, like #available. Then we'd have `case #unknown:` and something that 
> naturally expands to other pattern positions. I found that less aesthetically 
> pleasing, though, and so a context-sensitive keyword seemed like the way to 
> go.
> 
> (For the record, though, I wouldn't describe `case _` as a special case of 
> `default`. They do exactly the same thing, and `_` is a useful pattern in 
> other contexts, so if anything the current `default` should be thought of as 
> syntactic sugar for `case _`.)

Can case _ be mixed with unknown case? How can we match all compile time known 
cases but exclude future cases? Should be something like `case *` that would 
capture all currently known cases during compile time? case * and case _ would 
be the same in exhaustive enums. 


> 
> I'll add these points to the "Alternatives Considered" section in the PR 
> later today.
> 
> Jordan
> 
> 
>> On Jan 3, 2018, at 22:56, Xiaodi Wu  wrote:
>> 
>> As has already been said, “case unknown” is source-breaking because it 
>> conflicts with any real cases named “unknown”; “\unknown” looks like a key 
>> path but isn’t, and I wonder if it would potentially conflict with existing 
>> key paths.
>> 
>> In any case, my point was not to bikeshed the “unknown” part, but to ask 
>> whether any consideration had been made to have the feature presented as a 
>> flavor of default instead of a flavor of case.
>> 
>>> On Wed, Jan 3, 2018 at 23:57 Cheyo Jimenez  wrote:
>>> 
>>> 
 On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 This is a very nice revision. One bikeshedding thought:
 
 Since "unknown case" is presented as a special kind of "default", can't be 
 mixed with "default", and can't be used in case patterns, why not "default 
 unknown" (or "unknown default") instead of "unknown case"?
>>> 
>>> `case _ :` is already a special case of default. 
>>> I’d rather have `case unknown :`
>>> `unknown case :` is weird because of the order of `case`. 
>>> 
>>> Another alternative is `case \unknown :`
>>> `\unknown` would also allow pattern matching. 
>>> 
>>> 
>>> 
 
 
 On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution 
  wrote:
>> On Jan 2, 2018, at 18:07, Jordan Rose  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?
>> 
>> 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.
>> 
>> ---
>> 
>> 

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

[Cheyo Jimenez via swift-evolution]

> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This is a very nice revision. One bikeshedding thought:
> 
> Since "unknown case" is presented as a special kind of "default", can't be 
> mixed with "default", and can't be used in case patterns, why not "default 
> unknown" (or "unknown default") instead of "unknown case"?

`case _ :` is already a special case of default. 
I’d rather have `case unknown :`
`unknown case :` is weird because of the order of `case`. 

Another alternative is `case \unknown :`
`\unknown` would also allow pattern matching. 



> 
> 
> On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution 
>  wrote:
>>> On Jan 2, 2018, at 18:07, Jordan Rose  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?
>>> 
>>> 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!
>> 
>> I ended up doing these in the opposite order, writing up the new proposal 
>> first and not yet responding to the discussion that's further out. You can 
>> read my revisions at https://github.com/apple/swift-evolution/pull/777.
>> 
>> In particular, I want to at least address:
>> - Dave D and Drew C's points about versioned libraries / linking semantics 
>> of modules.
>> - Jason M's point about migration
>> and I'll do one more pass over the thread to see if there's anything else I 
>> didn't address directly. (That doesn't mean everyone who disagrees, just 
>> messages where I think there's more I can do to explain why the proposal is 
>> the way it is.)
>> 
>> Jordan
>> 
>> P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
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

[Cheyo Jimenez via swift-evolution]

On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution 
 wrote:

>> On 21 Dec 2017, at 03:32, John McCall wrote:
>> 
 On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote:
 
 On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote:
 
• What is your evaluation of the proposal?
>>> 
>>> I am pleased with the broad strokes of this design. I have quibbles with 
>>> three areas:
>>> 
>>> 1. The `@exhaustive` attribute may be confusing because the term doesn't 
>>> suggest versioning. My best alternative suggestion is `@frozen`, which 
>>> matches existing programming terminology: something that has been frozen 
>>> will not be changed in the future.
>> 
>> I rather like @frozen.  We could use that across language features, so that 
>> we don't end up with a keyword per kind of declaration.
> 
> Could this also be used on functions to make them inlinable?
> i.e. The body of the function has been frozen.
> 
> ```
> @frozen
> public func a()
> 
> @available(*, frozen)
> public func b()
> 
> @available(swift, introduced: 4.1, frozen: 5.0)
> public func c()
> 
> ```

My understanding is that frozen / exhaustible is guaranteed by the compiler 
while inlineable is more of a strong suggestion to the compiler. It would be 
confusing to use the same word for both. 
> 
> 
> 
> 
> -- Ben
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> On Dec 25, 2017, at 9:14 AM, Cheyo Jimenez via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
>> On Dec 22, 2017, at 8:49 AM, Cheyo Jose Jimenez <ch...@masters3d.com> wrote:
>> 
>> 
>> 
>>> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez <ch...@masters3d.com> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
>>>> January 3, 2018.
>>>> 
>>>> The proposal is available here:
>>>> 
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>>> Reviews are an important part of the Swift evolution process. All review 
>>>> feedback should be sent to the swift-evolution mailing list at:
>>>> 
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> or, if you would like to keep your feedback private, directly to the 
>>>> review manager. 
>>>> 
>>>> When replying, please try to keep the proposal link at the top of the 
>>>> message:
>>>> 
>>>> Proposal link: 
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>>> ...
>>>> Reply text
>>>> ...
>>>> Other replies
>>>> What goes into a review of a proposal?
>>>> 
>>>> The goal of the review process is to improve the proposal under review 
>>>> through constructive criticism and, eventually, determine the direction of 
>>>> Swift. 
>>>> 
>>>> When reviewing a proposal, here are some questions to consider:
>>>> 
>>>> What is your evaluation of the proposal?
>>>> 
>>> +1 except for the name. @frozenExposed @fixedMembers @frozenMembers. 
>>> preferably something that aligns with the other notion of not being able to 
>>> add public members to structs. This will help treat structs with static 
>>> members in the same way which would be ideal.  I don't think enums should 
>>> have their own attitude.
>>>> Is the problem being addressed significant enough to warrant a change to 
>>>> Swift?
>>>> 
>>> don't know. im not a library author. ill defer to other library authors. 
>> 
>> I want to revise my review here. While I am not a library author I am a 
>> library consumer. 
>> 
>> Having the ability treat a non exhaustive enum as exhaustive should be 
>> introduced with this. I like the idea of a 
>> `final switch`
>> 
>> I think it communicate clearly that I want this to be treated as exhaustive 
>> even if it is already exhaustive. Having something like future, unknowns 
>> would be weird to me. 
>> 
>> Another option would be being able to cast a enum as exhaustive. I am not 
>> sure how that would work. I do not like switch!  
> 
> Preferably I’d like to say: 
> 
> switch (@exhaustive x){...}
> 
> Would this be allowed?
> 
> let @exhaustive myEnum=  x
> 
> typealias  @exhaustive Y = X
> 
> if let @exhaustive x = x {
>  switch x {...} // exhaustive here. 
> }
> 
> Could this be addressed in the proposal? 

I would also expect case _  to only match known cases since _ acts like a wild 
char. 

switch x { // x is non-exhaustive here. 
  case _ : fatalError("compile time error when missing cases ") // known cases 
at compile time 
  default: fatalError("runtime error when missing cases") // unknown cases. 
}

It makes sense for default and case _ to do the same thing for exhaustive enums 
but not for non exhaustive. 

Could this be addressed in the proposal too?  Thanks in advance. 


> 
>>>> 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?
>>>> 
>>> n/a
>>>> How much effort did you put into your review? A glance, a quick reading, 
>>>> or an in-depth study?
>>>> 
>>> followed the previous discussion. read the proposal. 
>>>> Thanks,
>>>> Ted Kremenek
>>>> Review Manager
>>>> ___
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
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

[Cheyo Jimenez via swift-evolution]

> On Dec 22, 2017, at 8:49 AM, Cheyo Jose Jimenez  wrote:
> 
> 
> 
>> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez  wrote:
>> 
>> 
>> 
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>>>  wrote:
>>> 
>>> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
>>> January 3, 2018.
>>> 
>>> The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>> Reviews are an important part of the Swift evolution process. All review 
>>> feedback should be sent to the swift-evolution mailing list at:
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. 
>>> 
>>> When replying, please try to keep the proposal link at the top of the 
>>> message:
>>> 
>>> Proposal link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>> ...
>>> Reply text
>>> ...
>>> Other replies
>>> What goes into a review of a proposal?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. 
>>> 
>>> When reviewing a proposal, here are some questions to consider:
>>> 
>>> What is your evaluation of the proposal?
>>> 
>> +1 except for the name. @frozenExposed @fixedMembers @frozenMembers. 
>> preferably something that aligns with the other notion of not being able to 
>> add public members to structs. This will help treat structs with static 
>> members in the same way which would be ideal.  I don't think enums should 
>> have their own attitude.
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> 
>> don't know. im not a library author. ill defer to other library authors. 
> 
> I want to revise my review here. While I am not a library author I am a 
> library consumer. 
> 
> Having the ability treat a non exhaustive enum as exhaustive should be 
> introduced with this. I like the idea of a 
> `final switch`
> 
> I think it communicate clearly that I want this to be treated as exhaustive 
> even if it is already exhaustive. Having something like future, unknowns 
> would be weird to me. 
> 
> Another option would be being able to cast a enum as exhaustive. I am not 
> sure how that would work. I do not like switch!  

Preferably I’d like to say: 

switch (@exhaustive x){...}

Would this be allowed?

let @exhaustive myEnum=  x

typealias  @exhaustive Y = X

if let @exhaustive x = x {
 switch x {...} // exhaustive here. 
}

Could this be addressed in the proposal? 

>>> 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?
>>> 
>> n/a
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>>> 
>> followed the previous discussion. read the proposal. 
>>> Thanks,
>>> Ted Kremenek
>>> Review Manager
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> On Dec 23, 2017, at 4:15 PM, Slava Pestov via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
>> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> What are your thoughts on `final switch` as a way to treat any enum as 
>>> exhaustible?
>>> https://dlang.org/spec/statement.html#FinalSwitchStatement
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> I’d be very much in favour of this (qualms about the naming of the ‘final’ 
>> keyword aside - ‘complete’ or ‘exhaustive’ reads better to me). 
>> 
>> Looking back at the proposal, I noticed that something similar was mentioned 
>> that I earlier missed. In the proposal, it says:
>> 
>>> However, this results in some of your code being impossible to test, since 
>>> you can't write a test that passes an unknown value to this switch.
>> 
>> Is that strictly true? Would it be theoretically possible for the compiler 
>> to emit or make accessible a special ‘test’ case for non-exhaustive enums 
>> that can only be used in test modules or e.g. by a 
>> ‘EnumName(testCaseNamed:)’, constructor? There is  potential for abuse there 
>> but it would address that particular issue. 
>> 
>> Regardless, I still feel something like a ‘final switch’ is necessary if 
>> this proposal is introduced, and that it fits with the ‘progressive 
>> disclosure’ notion; once you learn this keyword you have a means to check 
>> for completeness, but people unaware of it could just use a ‘default’ case 
>> as per usual and not be concerned with exhaustiveness checking. 
> 
> My general philosophy with syntax sugar is that it should do more than just 
> remove a constant number of tokens. Basically you’re saying that
> 
> final switch x {}
> 
> just expands to
> 
> switch x { // edited
> default: fatalError()
> }
> 
> I don’t think a language construct like this carries its weight.

Having the ability to treat a non exhaustive enum as if it where exhaustive is 
not the same as 

switch x {
default : fatalError()
}

The above will happily let me omit currently compile time known cases.  Perhaps 
‘final switch’ is not the best but I can’t think of another way to semantically 
“cast” a non exhaustive as exhaustive. Essentially what I believe we want is a 
way to treat a non exhaustive as exhaustive during compile time, on the client 
side. 

It would be cool if we instead repurposed the swift “case _” to handle all 
compile time known cases and default could then handle all unknown future cases 
in an non exhaustive enum. 

public enum x {a, b, c, d}

switch x { // x is non exhaustive here
  case a: print("case a")
  case _ : print(“known cases b c or d”) // sugar for cases b, c, d which are 
known during compile time. Expanded to mean case b, c, d. 
default: fatalError() // future unknown cases
}

I don’t think this would would break any code since all enums have been 
exhaustive. No new syntax would be added and now there would be a meaningful 
difference between compile time known cases (case _) vs compile time unknown 
future cases (default). 


> 
> For example, generics have a multiplicative effect on code size — they 
> prevent you from having to write an arbitrary number of versions of the same 
> algorithm for different concrete types.
> 
> Another example is optionals — while optionals don’t necessarily make code 
> shorter, they make it more understandable, and having optionals in the 
> language rules out entire classes of errors at compile time.
> 
> On the other hand, a language feature that just reduces the number of tokens 
> without any second-order effects makes code harder to read, the language 
> harder to learn, and the compiler buggier and harder to maintain without much 
> benefit. So I think for the long term health of the language we should avoid 
> ‘shortcuts’ like this.
> 
> Slava
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> On Dec 21, 2017, at 9:49 AM, Ignacio Soto via swift-evolution 
>  wrote:
> 
> I think I speak for the entire Swift community when I say that Swift's enums, 
> together with the ability to switch over them exhaustively and having 
> compile-time guarantees, is one of the best features in Swift. I'm regularly 
> annoyed by this when writing other languages like Java and JS (default: throw 
> new IllegalArgumentException();)
> 
> Now, that's not to say I don't understand why this proposal is necessary. I 
> totally get it, and the existing decisions make a lot of sense to me. But I'd 
> like us to introduce this while maintaining the ability to guarantee 
> exhaustive switch statements, no matter how the enum was defined.
> 
> Example: imagine a theoretical SampleKit defines:
> public enum E {
> case A
> case B
> }
> 
> It's implicitly non-exhaustive, possibly because the author was not aware of 
> the default (which would likely happen often), or possibly because they made 
> a conscious decision, as they expect to expand the cases in the future.
> 
> In my app, I use SampleKit and decide that I want to make sure I handle all 
> cases:
> 
> switch e {
> case A: break
> case B: break
> default: break // This becomes necessary
> }
> 
> As the proposal stands right now, I'm forced to handle any future cases. 
> That's fine. What's not fine in my opinion, is that in doing so I lose the 
> ability to keep this exhaustiveness moving forward. If I update SampleKit to 
> v2.0, I want to know at compile-time if there are new cases I need to be 
> aware of (instead of going to some generic handling path). Instead, I’m left 
> in the same place I would in other languages like Java or JS:
> 
> // No error :(
> switch e {
> case A: break
> case B: break
> default: break
> }
> 
> Proposed Solution
> 
> What I’m proposing is that we introduce a new keyword, unknown (or a better 
> name), that serves as a way to handle cases that aren’t yet known, but not 
> those that are.
> 
> // Error: missing case C
> switch e {
> case A: break
> case B: break
> unknown: break // Would handle future cases
> }
> 

What are your thoughts on `final switch` as a way to treat any enum as 
exhaustible?
https://dlang.org/spec/statement.html#FinalSwitchStatement


> With this, you shouldn’t be able to use default AND unknown at the same time, 
> as default implicitly includes unknown.
> 
> Thanks for reading, and I hope you can consider this change (or some 
> variation of it).
> 
> Nacho Soto
> ___
> 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

[Cheyo Jimenez via swift-evolution]

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
> January 3, 2018.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
> Reviews are an important part of the Swift evolution process. All review 
> feedback should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
+1 except for the name. @frozenExposed @fixedMembers @frozenMembers. 
preferably something that aligns with the other notion of not being able to add 
public members to structs. This will help treat structs with static members in 
the same way which would be ideal.  I don't think enums should have their own 
attitude.
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
don't know. im not a library author. ill defer to other library authors. 
> 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?
> 
n/a
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
followed the previous discussion. read the proposal. 
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> On Dec 20, 2017, at 4:19 PM, Ted Kremenek via swift-evolution 
>  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
> Reviews are an important part of the Swift evolution process. All review 
> feedback should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
+1
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
yes
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
yes, I’d suggest a name like @abiExposed.
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
C++ but on briefly. 
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
read proposal. used _ attribute in the past but never really needed it. 
> 
> Thanks,
> Ted Kremenek
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Dec 3, 2017, at 8:41 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
>> On 3 Dec 2017, at 04:11, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Dec 2, 2017, at 7:40 PM, Chris Lattner  wrote:
>>> 
>>> On Dec 2, 2017, at 2:13 PM, Matthew Johnson  wrote:
> For all those reasons, we really do need something like AnyObject 
> dispatch if we care about working with dynamically typed languages.  The 
> design I’m suggesting carefully cordons this off into its own struct 
> type, so it doesn’t infect the rest of the type system, and is 
> non-invasive in the compiler.
 
 I am quite familiar with dynamic languages and agree that this is 
 necessary if we are going to fully open up access to these languages from 
 Swift.
>>> 
>>> Ok, then it appears you agree that something like anyobject dispatch is 
>>> necessary for effective dynamic language interop.
>>> 
>> I strongly urge you to reconsider the decision of that dynamic members 
>> must be made available with no indication at usage sites.  An indication 
>> of dynamic lookup at usage sites aligns very well (IMO) with the rest of 
>> Swift (AnyObject lookup aside) by calling attention to code that 
>> requires extra care to get right.
> 
> I don’t understand this.  The proposal is fully type safe, and this 
> approach is completely precedented by AnyObject.  Swift’s type system 
> supports many ways to express fallibility, and keeping those decisions 
> orthogonal to this proposal is the right thing to do, because it allows 
> the author of the type to decide what model makes sense for them.
 
 Allowing the author of the type to choose whether the mechanism is hidden 
 or visible is exactly what I don’t want to allow.  I think you have the 
 right design regarding types and semantics - the author chooses.  But I 
 don’t want these calls to look like ordinary member lookup when I’m 
 reading code.  
 
 They inherently have a much greater chance of failure than ordinary member 
 lookup.  Further, authors are likely to choose immediate traps or nil IUO 
 as failure modes as forcing users to deal with Optional on every call is 
 likely to be untenable.  I believe this behavior should be represented by 
 some kind of syntax at the usage site.  I don’t believe it is an undue 
 burden.  It would make the dynamic lookup semantic clear to all readers 
 and would help to discourage abuse.
>>> 
>>> I believe that adding explicit syntax would be counterproductive to your 
>>> goals, and would not make dynamic lookup syntax more clear.  I assume that 
>>> you would also want the same thing for DynamicCallable too, and operator 
>>> overloads, subscripts, and every other operation you perform on these 
>>> values, since they all have the exact same behavior.
>>> 
>>> If we required some syntax even as minimal as “foo.^bar” and "baz^(42)”, 
>>> that change would turn this (which uses runtime failing or IUO return 
>>> values like AnyObject):
>>> 
>>> let np = Python.import("numpy")
>>> let x = np.array([6, 7, 8])
>>> let y =  np.arange(24).reshape(2, 3, 4)
>>> 
>>> let a = np.ones(3, dtype: np.int32)
>>> let b = np.linspace(0, pi, 3)
>>> let c = a+b
>>> let d = np.exp(c)
>>> print(d)
>>> 
>>> into:
>>> 
>>> let np = Python.import("numpy")
>>> let b = np^.array^([6, 7, 8])
>>> let y =  np^.arange^(24)^.reshape^(2, 3, 4)
>>> 
>>> let a = np^.ones^(3, dtype: np^.int32)
>>> let b = np^.linspace^(0, pi, 3)
>>> let c = a+^b
>>> let d = np^.exp^(c)
>>> 
>>> This does not improve clarity of code, it merely serves to obfuscate logic. 
>>>  It is immediately apparent from the APIs being used, the API style, and 
>>> the static types (in Xcode or through static declarations) that this is all 
>>> Python stuff.  
>> 
>> It may be immediately apparent when the types involved are obviously 
>> dynamic, such as in this example where Python.import is explicitly used.  
>> However, my concern is less about the intended use case of dynamic language 
>> interop than I am that this feature will be generally available to all types 
>> in Swift.  
>> 
>> This is big change from AnyObject dispatch.  It opens up the dynamism to 
>> types and contexts that are not necessarily obviously using dynamic lookup, 
>> callable, etc.  Maybe this won’t turn out to be a problem in practice but I 
>> still think it’s a legitimate concern.
> 
> If dynamism if restricted to subclasses of a DynamicObject type, like Xiaodi 
> suggested earlier, then we can protect ourselves from this dynamic dispatch 
> being generally available to all types in Swift.

I like the idea of a class type as the marker. 

If we did expose the protocols that DynamicObject conform to, 

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

[Jose Cheyo Jimenez via swift-evolution]

> On Dec 2, 2017, at 11:46 PM, Jean-Daniel <mail...@xenonium.com> wrote:
> 
> 
> 
>> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org> a écrit :
>> 
>> Hi Chris, 
>> 
>> Thank you for pushing this forward.
>> 
>> My only comment is that on the declaration side it would be great to also 
>> have an attribute to communicate that compiler magic is happening.
>> 
>> Currently it is surprising that a regular looking protocol is providing me 
>> so much power.
>> 
>> Suggestions: 
>> 
>> @dynamic
>> struct PyVal : MemberLookupProtocol {...}
>> 
>> @dynamic
>> struct ParameterSummer : DynamicCallable {...}
>> 
>> // Error: This type needs the @dynamic attribute.
>> class ParamWinter : MyCustomCallableProtocolOrClassOrTypeAlias {...}
>> 
>> By requiring @dynamic (Or other attribute name), people can know that this 
>> is a compiler dynamic declaration and not just some random protocol whose 
>> name starts with Dynamic*. :)
>> 
> 
> I’m not fond of the idea of an attribute. This introduce redundancy.

> What a declaration means if the attribute is missing ?  
Won’t compile?

> What this attribute will mean on an other declaration ?
Won’t compile?

It would be similar to the swift 4 mode where @objc is required in some 
declarations. 


> If this attribute must be used with the declaration and it can’t be used with 
> an other one, then what is the point of having an attribute but to exercice 
> the compiler fixit feature 
> 
>> @NSManagedObject is another example I like from Core Data.
>> https://useyourloaf.com/blog/core-data-code-generation/
> 
> @NSManageObject apply to normal declarations that have a different meaning 
> when this attribute is not present.
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

[Jose Cheyo Jimenez via swift-evolution]

Hi Chis, 

Thank you for pushing this forward.

My only comment is that on the declaration side it would be great to also have 
an attribute to communicate that compiler magic is happening.

Currently it is surprising that a regular looking protocol is providing me so 
much power.

Suggestions: 

@dynamic
struct PyVal : MemberLookupProtocol {...}

@dynamic
struct ParameterSummer : DynamicCallable {...}

// Error: This type needs the @dynamic attribute.
class ParamWinter : MyCustomCallableProtocolOrClassOrTypeAlias {...}

By requiring @dynamic (Or other attribute name), people can know that this is a 
compiler dynamic declaration and not just some random protocol whose name 
starts with Dynamic*. :)

@NSManagedObject is another example I like from Core Data.
https://useyourloaf.com/blog/core-data-code-generation/ 


- Cheyo



> On Nov 28, 2017, at 8:35 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Nov 27, 2017, at 6:21 PM, Brent Royal-Gordon > > wrote:
>> 
>>> On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> Just to talk to myself a bit here, but I’ve come to realize that the right 
>>> design really is to have a simple empty marker protocol like this:
>> 
>> If you're reaching this point. why have a marker protocol at all? Why not 
>> treat `subscript(dynamicMember:)` specially on any type that has it, or have 
>> an `@dynamicMember subscript(_:)` attribute, or introduce an entire new 
>> `dynamicMember(_:)` declaration?
> 
> We’ve had a lot of discussions over the years about how to balance simplicity 
> vs power, implicitness vs explicitness, intentionality vs accidental 
> behavior, etc.  For example, in very early discussions about Swift generics, 
> some folks where strong proponents of protocol conformance being fully 
> implicit: satisfying all the requirements of a protocol meant that you 
> conformed to it, even if you didn’t explicitly “inherit” from it.
> 
> This is obviously not the design we went with over the long term, and I’m 
> glad we didn’t.  That said, if we did, then all of the “ExpressibleBy” 
> protocols wouldn’t  need to exist: we’d probably just say that it was enough 
> to implement the requirements to get the behavior and elide the protocol 
> declaration entirely.
> 
> I think that DynamicMemberLookup requiring conformance is the same thing: it 
> makes it explicit that the behavior is intentional, and it allows somewhat 
> better error checking (if you conform to the protocol but don’t implement the 
> (implicitly known) requirement, you DO get an error).  That said, this is 
> just my opinion.  
> 
> Do you feel strongly enough about this that you’d like to make a strong 
> argument for changing the behavior?
> 
> -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-0187: Introduce Sequence.filterMap(_:)

[Jose Cheyo Jimenez via swift-evolution]

- 1 I agree with Kevin Ballard. 

I think that it would be appropriate to nudge the user to use map instead. 

We already nudge people to use let over var so I think is sensible to do the 
same for misuses of flatMap when map is sufficient.

Thanks!


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

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 14, 2017, at 6:11 PM, Michael Ilseman via swift-evolution 
>  wrote:
> 
> I think that “match” is a word to avoid for this, as this doesn’t have 
> anything to do with pattern matching, fuzzy matching, etc., while  “equals” 
> is precisely the concept we’re using.
> 
> What about the name “sequentiallyEquals”? Highlight the fact that we’re 
> talking about sequential ordering, i.e. whatever order the sequence provides, 
> as opposed to first doing some lexicographical ordering of elements 
> themselves.
> 
> var a: Set =  [3, 1, 2]
> a.sequentiallyEquals([1,2,3]) // result depends on application of equality in 
> a (potentially-arbitrary) sequential ordering

I really like this name. 

It does make me think about .first which I now feel it should be 
.sequentiallyFirst :)

I ultimately think that these methods/properties do not make sense for 
unordered types so probably they should just be unavailable. 

> 
> Whereas I could see the following being more confusing:
> 
> var a: Set =  [3, 1, 2]
> a.lexicographicallyEquals([1,2,3]) // result depends on application of 
> equality, but what meaning does “lexicographically” convey?
> 
> It’s not immediately clear to someone new to the API that “lexicographically” 
> speaks to the nature of the sequence’s (potentially-arbitrary) order, 
> irrespective of element. It could give the false impression that it speaks to 
> some nature of the elements themselves, in this case Ints, which have an 
> obvious lexicographical ordering. I don’t know how frequent that 
> misconception would be in practice, but it does cause me to do a double-take 
> in this contrived example.
> 
> 
>> On Oct 14, 2017, at 1:04 PM, Benjamin G via swift-evolution 
>> > wrote:
>> 
>> To answer more precisely this request (which remains valid no matter the 
>> protocol hierarchy). I propose
>> 
>> "matchesSequence" ( or simply "matches" or "match", whatever is more 
>> coherent with the naming guidelines).
>> 
>> So
>> var a: [Int] = [1,2,3]
>> a.matchesSequence([1,2,3]) returns true.
>> 
>> I first thought that the verb "matching" was too heavily associated to 
>> regular expressions, but i think that it's the correct equivalent for 
>> something as general as a sequence.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Oct 13, 2017 at 1:24 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> Rename Sequence.elementsEqual
>> 
>> Proposal: SE- 
>> Authors: Xiaodi Wu 
>> Review Manager: TBD
>> Status: Awaiting review
>>  
>> Introduction
>> 
>> The current behavior of Sequence.elementsEqual is potentially confusing to 
>> users given its name. Having surveyed the alternative solutions to this 
>> problem, it is proposed that the method be renamed to 
>> Sequence.lexicographicallyEquals.
>> 
>>  
>> Motivation
>> 
>> As outlined by Ole Begemann 
>> , use of 
>> Sequence.elementsEqual(_:) can lead to surprising results if the sequences 
>> compared are unordered:
>> 
>> var set1: Set = Set(1...5)
>> var set2: Set = Set((1...5).reversed())
>> 
>> set1 == set2 // true
>> set1.elementsEqual(set2) // false
>> This result does reflect the intended and documented behavior of the 
>> elementsEqual(_:) method, which performs a lexicographical elementwise 
>> comparison. That is, the method first compares set1.first to set2.first, 
>> then (if the two elements compare equal) compares the next element stored 
>> internally in set1 to the next element stored internally in set2, and so on.
>> 
>> In almost all circumstances where a set is compared to another set, or a 
>> dictionary is compared to another dictionary, users should use == instead of 
>> elementsEqual(_:).
>> 
>>  
>> Proposed
>>  solution
>> 
>> The proposed solution is the result of an iterative process of reasoning, 
>> presented here:
>> 
>> The first and most obvious solution is to remove the elementsEqual(_:) 
>> method altogether in favor of ==. This prevents its misuse. However, because 
>> elementsEqual(_:) is a generic method on Sequence, we can use it to compare 
>> an instance of UnsafeBufferPointer to an instance of [Int]. This is a 
>> useful and non-redundant feature which would be eliminated if the method is 
>> removed altogether.
>> 
>> A second solution  is to create 
>> overloads that forbid the use of the elementsEqual(_:) method specifically 
>> in non-generic code. This would prevent misuse in non-generic code; however, 
>> it would also forbid legitimate mixed-type 

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 10, 2017, at 8:24 AM, Vladimir.S  wrote:
> 
> On 09.10.2017 20:36, Jose Cheyo Jimenez wrote:
>>> On Oct 9, 2017, at 9:17 AM, Vladimir.S via swift-evolution 
>>> > wrote:
>>> 
>>> On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote:
 Two weeks ago I had a fairly strong opinion about “private extension” 
 behavior. After following this discussion, I now have no opinion on the 
 matter.
 I would summarize the points on both sides as follows:
 For the change:
 • It is surprising to many people that members of a private extension are 
 implicitly fileprivate. > • There is currently no way to make an extension 
 whose members default to private.
>>> 
>>> I'd add this:
>>> * Current rule for 'private extension' can lead to bugs, when you expect 
>>> that private methods will be 'true' private but they are fileprivate, so 
>>> could be called from not-expected code in the same file. Inverse 
>>> situation(when you need fileprivate but 'private extension' means 'true' 
>>> private) - can't cause bugs, you'll be notified by the compiler if you need 
>>> a 'wider' access level.
>>> * The change will make the access-control rule for extensions simpler, not 
>>> harder to understand.
>>> * 'fileprivate' access level for methods in extension will be used by 
>>> *intention*, not just because "this is how 'private extension' works". If I 
>>> understand correctly, it is not the 'fileprivate' *keyword* we want to see 
>>> less, but the fileprivate *access level*, which should be rare and 
>>> intentional.
>> Top level private *is* private. Swift did not make a distinction between top 
>> level private and fileprivate so why should the programmer have to choose?
>> If you explicitly declare something private at the top level you are going 
>> to get fileprivate semantics. This is how scope private works. If you 
>> disagree then that is a different conversation I think. If you wish for 
>> these not have an overlap then that is definitely a different proposal?
> 
> I'd like to reply with Xiaodi's words(I hope he will not be against this):
> 
> >---<
> The documentation is correct. To interpret it, you must understand that 
> extensions are not entities and therefore do not have accessibility of their 
> own; an access modifier in front of “extension” acts only as a shorthand to 
> set the default and maximum access level of contained members. This aspect of 
> Swift is not up for change, only the question of what the “private” shorthand 
> means.
> >---<
> 
> i.e. extension is another "thing" than type. You should not derive any 
> rules/expectation of how access modifiers work for extension based on rules 
> for type. This could be even(as I showed) dangerous.
> 
> Given the *definition* (and the "spirit", as I undertand it) of how access 
> modifiers work for extensions, and how this rule *differs* from access 
> modifiers for type, plus given the potential bugs produced by current rule 
> for 'private extension' but no problems if one declared 'true' private 
> extension but needs fileprivate access level, and over-complicated rules for 
> access modifiers in Swift, and given we can't have a extension of true 
> private members, especially in the light of new visibility rules for private 
> members in extensions in the same file - all this leads me to conclusion that 
> we need to make change. I understand that you have another opinion, but for 
> me, it is clear that pros of the change are much better than status quo and 
> than possible cons of the change.
> 
> I.e. I do think current situation is harmful enough to be changed now, and 
> now is the last chance to fix this for observable future(i.e. after Swift 5).
> 
> As for changing the rules for access modifiers for extensions or their 
> syntax, as Xiaodi already mentioned, this is out of scope for current 
> discussion and most likely will not be discussed ever soon.

If the main motivation for changing the rules for `private extension` is 
because it can lead to bugs, then you can not just dismiss the elephant in the 
room that is `public extension`. Accidentally leaking a public interface is 
more damaging than accidentally using an implementation detail. SE-0119 was 
about completely removing extension modifiers. 

I am all for fixing the inconsistencies but I do not believe that `private 
extension` is inconsistent. 

> 
> Actually, I feel like we start to repeat the opinions/arguments regarding the 
> subject, so probably we need to decide if we need a formal proposal. Or 
> probably we should collect even more opinions on this? Right now I feel like 
> the most opinions are positive, or I'm wrong?

Go for it. I am completely against it but lets see what the community has to 
say. 

> 
> Vladimir.
> 
>>> 
 Against the change:
 • The proposal is source-breaking.
 • The proposal makes “fileprivate” more 

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 9, 2017, at 9:17 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote:
>> Two weeks ago I had a fairly strong opinion about “private extension” 
>> behavior. After following this discussion, I now have no opinion on the 
>> matter.
>> I would summarize the points on both sides as follows:
>> For the change:
>> • It is surprising to many people that members of a private extension are 
>> implicitly fileprivate. > • There is currently no way to make an extension 
>> whose members default to private.
> 
> I'd add this:
> * Current rule for 'private extension' can lead to bugs, when you expect that 
> private methods will be 'true' private but they are fileprivate, so could be 
> called from not-expected code in the same file. Inverse situation(when you 
> need fileprivate but 'private extension' means 'true' private) - can't cause 
> bugs, you'll be notified by the compiler if you need a 'wider' access level.
> * The change will make the access-control rule for extensions simpler, not 
> harder to understand.
> * 'fileprivate' access level for methods in extension will be used by 
> *intention*, not just because "this is how 'private extension' works". If I 
> understand correctly, it is not the 'fileprivate' *keyword* we want to see 
> less, but the fileprivate *access level*, which should be rare and 
> intentional.

Top level private *is* private. Swift did not make a distinction between top 
level private and fileprivate so why should the programmer have to choose?

If you explicitly declare something private at the top level you are going to 
get fileprivate semantics. This is how scope private works. If you disagree 
then that is a different conversation I think. If you wish for these not have 
an overlap then that is definitely a different proposal?

> 
>> Against the change:
>> • The proposal is source-breaking.
>> • The proposal makes “fileprivate” more common.
> 
> It depends on what most of Swift developers *mean* when writing 'private 
> extension' - if they actually need 'fileprivate extension' - then yes, we'll 
> see it more in code. But if in most cases the *intention* is to have a bunch 
> of 'true private' methods - we'll have a small number of 'fileprivate 
> extension'.
> But in any case, what is the problem with this? If developer *needs* 
> fileprivate access level for methods in extension - this will be clearly 
> stated in code, not hidden under the cute title of 'private extension'
> 
>> • A private extension and a (top-level) private type both currently have 
>> implicitly fileprivate members. The proposal breaks that symmetry.
> 
> Is it really good symmetry?
> By definition, the rule for applying the access level to type is differ from 
> the rule for extension. Here all symmetry already broken and we have 2 
> separate rules. And from my point of view, having a symmetry in *this 
> particular* case is a bad thing, it can lead to wrong assumptions. Don't you 
> want to apply the same 'symmetry' rule for the code below ? :

I would be totally on board with making extensions work the same as types. So 
instead of enforcing a default ACL, the extension would work the same way as a 
type by just declaring the upper bound. This would effectively only allow 
extension to lower the upper bound while still making the default ACL to 
internal. This would also be a breaking change for public extensions that 
assume their members to be public. I believe that the behavior of public 
extension is more harmful and more likely to cause bugs because you are 
exposing a public API and may not be aware of it. This would remove the ability 
of open types to be extended with a default ACL of public.  The same would 
happen to public types that are being extended with public modifier.

The below would be symmetrical but now public extension are essentially the 
same as just extension without the modifier.

open class MyOpenClass {}

public extension MyOpenClass { // upper bound public
func myFunc(){} // default internal, upperbound higher it stays internal. 
}
internal extension MyOpenClass { // upper bound internal
func myFunc2(){} // default internal
}

fileprivate extension MyOpenClass { // upper bound fileprivate
func myFunc3(){} // default internal but lowered to fileprivate
}

private extension MyOpenClass { // upper bound toplevel private
func myFunc4(){} // default internal but lowered to toplevel private
}



> 
> public class C {
>var i = 10
> }
> 
> public extension C {
>func j(){}
> }
> 
> ,as you understand 'i' is internal, while 'j()' is public. So this could be a 
> dangerous assumption.
> 
> 
>> Notable questions:
>> • Currently “open” cannot be applied to an extension at all, should we allow 
>> it?
> 
> Probably. But this should be a separate pitch/proposal.
> 
>> • Might we ever want to allow nested (non-top level) extensions, and if so 
>> how should 

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 7, 2017, at 10:17 AM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Two weeks ago I had a fairly strong opinion about “private extension” 
> behavior. After following this discussion, I now have no opinion on the 
> matter.
> 
> I would summarize the points on both sides as follows:
> 
> For the change:
> • It is surprising to many people that members of a private extension are 
> implicitly fileprivate.
> • There is currently no way to make an extension whose members default to 
> private.
> 
> Against the change:
> • The proposal is source-breaking.
> • The proposal makes “fileprivate” more common.
> • A private extension and a (top-level) private type both currently have 
> implicitly fileprivate members. The proposal breaks that symmetry.
> 
Great summary! Thank you. 
> Notable questions:
> • Currently “open” cannot be applied to an extension at all, should we allow 
> it?
> • Might we ever want to allow nested (non-top level) extensions, and if so 
> how should access levels on them work?

This could be a solution that would not be source breaking to the topic at 
hand. 

extension MyType {
private extension {
// “true” private here
}
}

I think it would be a good idea to limit the nesting with other extensions. 
Other idea. 

extension { // bag of extensions
private extension MyType {
// “true” private here
}
fileprivate extension MyType2 {
// fileprivate  here
}
}

I rather have a comprehensive sub module system than nested extensions though.  
:)

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 7, 2017, at 8:28 AM, Xiaodi Wu  wrote:
> 
> This, I think, is the most persuasive argument available here; it provides a 
> concrete use case to justify why one design is superior to the other.

open extension do not exist either. :)

>> On Sat, Oct 7, 2017 at 10:26 David Hart via swift-evolution 
>>  wrote:
>> One argument: without this fix, private is the only access level for which 
>> we have no means to easily and implicitly apply an access level to a group 
>> of members. And it bums me to have to explicitly type private on ever single 
>> member to achieve the same result as I can with any other access level.

In the same way that we need to be explicit about open in extension members or 
public in public type members; the lowest access version of scope private needs 
to also be explicit in private extension members and top level private concrete 
type members. 

The premise of 169 was never about creating a new version of scope private that 
could only be used in extensions. It just relaxed the rules for explicit 
private extension members. 

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 6, 2017, at 9:35 PM, Tony Allevato  wrote:
> 
> 
> 
> On Fri, Oct 6, 2017 at 9:29 PM Jose Cheyo Jimenez  > wrote:
>> On Oct 6, 2017, at 8:58 PM, Tony Allevato > > wrote:
>> 
>> 
>> 
>> On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez > > wrote:
>>> On Oct 6, 2017, at 8:01 PM, Tony Allevato >> > wrote:
>>> 
>>> At the time SE-0025 was accepted, "private extension" would have been 
>>> meaningless if it did not mean "fileprivate" because it predated the 
>>> SE-0169 behavior extending "private" to extensions in the same file. The 
>>> very issue being debated here is whether the oversight that SE-0169 did not 
>>> consider extensions—now that "private extension" *could* have a meaningful 
>>> use separate from "fileprivate extension"—is something that is worth 
>>> correcting.
>>> 
>>> If the documentation is out-of-date and needs to be updated to list 
>>> describe unintuitive special behavior, why not use the opportunity to make 
>>> the behavior intuitive and consistent instead?
>> 
>> Lets say you “fix” the private extension override. Now MyClass2.myFunc2() is 
>> not accessible from outside the type. 
>> Wouldn't MyClass2.myFunc2() now be inconsistent with MyClass.myFunc()? 
>> I don’t think you can make a change to one with out causing other 
>> inconsistencies. I rest my case.  :) 
>> 
>> No, because a class is a concrete "thing" whose access level which—while 
>> providing an upper bound for access levels of its defaulting members—is 
>> otherwise independent of the access level of its members.
>> 
>> Extensions, on the other hand, aren't a concrete thing of their own. The 
>> access level on an extension exists *solely* as a shortcut to specify the 
>> upper bound for its defaulting members that are injected into the main type.
>> 
>> What happens in your example if you replace "private" with "public"? Then 
>> myFunc has internal access but myFunc2 is public. So the "inconsistency" 
>> you're pointing out between access inherited from a type and access 
>> inherited from an extension already exists—they're apples and oranges.
>> 
>> That's why access levels of classes/structs/other types aren't relevant 
>> examples here—extensions treat access levels fundamentally differently.
> 
> Sure. Extensions apply a default upper bound and types can lower the upper 
> bound of the default internal members. The upper bound on the below example 
> is the same for both when dealing with top level private.
> 
> Extensions should resolve their upper bound accessibility where the ‘private’ 
> appears explicitly and this now happens to be the same for both types and 
> extensions regardless of how they are enforced. 
> 
> But *why* do you think that should be? You're stating what the current 
> situation is and you say that it "should" be that way, but why should we 
> accept that status quo instead of making "private extension" more useful for 
> people who use "private" in the sense introduced by SE-0169, when the 
> argument for consistency can honestly be argued either way (the two options I 
> wrote a few messages up)?

Oh :) Because I believe that lowering the scope of “private extension” would 
undermine the spirit of 169.  169 was a compromise after 159 was rejected. 169 
was meant to make fileprivate less common and thus more meaningful when it 
occurs in source. Where 169 was meant to relax the rules, the proposed “fix” 
would force people who now use “private extension” to use “fileprivate 
extension” thus making fileprivate more common. In other words, 169 was about 
relaxing rules and not about tightening down the rules or allowing “true” 
private to be applied as a default ACL extension.

“scoped" `private extension` can’t be archived now in the same way that ‘open 
extension’ is not allowed. The lowest and highest ACL are not able to be 
applied as default  extension modifiers and this makes sense to me. 

There is no solution that will make everyone happy: maintaining the status quo 
makes “fileprivate” too common and therefore not meaningful when it occurs in 
source; removing or diluting scope-level access control (as in SE-0159 
>
 and this proposal)
https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html
 




> 
>  
>> 
>> private class MyClass {
>> static func myFunc(){ // This would now act differently from private 
>> extensions? 
>> print("acts like fileprivate now")
>> }
>> }
>> 
>> private class MyClass2 {}
>> 
>> 

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 6, 2017, at 8:58 PM, Tony Allevato  wrote:
> 
> 
> 
> On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez  > wrote:
>> On Oct 6, 2017, at 8:01 PM, Tony Allevato > > wrote:
>> 
>> At the time SE-0025 was accepted, "private extension" would have been 
>> meaningless if it did not mean "fileprivate" because it predated the SE-0169 
>> behavior extending "private" to extensions in the same file. The very issue 
>> being debated here is whether the oversight that SE-0169 did not consider 
>> extensions—now that "private extension" *could* have a meaningful use 
>> separate from "fileprivate extension"—is something that is worth correcting.
>> 
>> If the documentation is out-of-date and needs to be updated to list describe 
>> unintuitive special behavior, why not use the opportunity to make the 
>> behavior intuitive and consistent instead?
> 
> Lets say you “fix” the private extension override. Now MyClass2.myFunc2() is 
> not accessible from outside the type. 
> Wouldn't MyClass2.myFunc2() now be inconsistent with MyClass.myFunc()? 
> I don’t think you can make a change to one with out causing other 
> inconsistencies. I rest my case.  :) 
> 
> No, because a class is a concrete "thing" whose access level which—while 
> providing an upper bound for access levels of its defaulting members—is 
> otherwise independent of the access level of its members.
> 
> Extensions, on the other hand, aren't a concrete thing of their own. The 
> access level on an extension exists *solely* as a shortcut to specify the 
> upper bound for its defaulting members that are injected into the main type.
> 
> What happens in your example if you replace "private" with "public"? Then 
> myFunc has internal access but myFunc2 is public. So the "inconsistency" 
> you're pointing out between access inherited from a type and access inherited 
> from an extension already exists—they're apples and oranges.
> 
> That's why access levels of classes/structs/other types aren't relevant 
> examples here—extensions treat access levels fundamentally differently.
Sure. Extensions apply a default upper bound and types can lower the upper 
bound of the default internal members. The upper bound on the below example is 
the same for both when dealing with top level private.

Extensions should resolve their upper bound accessibility where the ‘private’ 
appears explicitly and this now happens to be the same for both types and 
extensions regardless of how they are enforced. 
> 
> private class MyClass {
> static func myFunc(){ // This would now act differently from private 
> extensions? 
> print("acts like fileprivate now")
> }
> }
> 
> private class MyClass2 {}
> 
> private extension MyClass2{
>   static func myFunc2(){
>print("Same as MyClass.myFunc")
> }
> }
> 
> 
> MyClass.myFunc() // acts like fileprivate
> MyClass2.myFunc2() // The proposed change would hide myFunc2
>  //Error: 'myFunc2' is inaccessible due to 'private' protection 
> level

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 6, 2017, at 8:01 PM, Tony Allevato  wrote:
> 
> At the time SE-0025 was accepted, "private extension" would have been 
> meaningless if it did not mean "fileprivate" because it predated the SE-0169 
> behavior extending "private" to extensions in the same file. The very issue 
> being debated here is whether the oversight that SE-0169 did not consider 
> extensions—now that "private extension" *could* have a meaningful use 
> separate from "fileprivate extension"—is something that is worth correcting.
> 
> If the documentation is out-of-date and needs to be updated to list describe 
> unintuitive special behavior, why not use the opportunity to make the 
> behavior intuitive and consistent instead?

Lets say you “fix” the private extension override. Now MyClass2.myFunc2() is 
not accessible from outside the type. 
Wouldn't MyClass2.myFunc2() now be inconsistent with MyClass.myFunc()? 
I don’t think you can make a change to one with out causing other 
inconsistencies. I rest my case.  :) 


private class MyClass {
static func myFunc(){ // This would now act differently from private 
extensions? 
print("acts like fileprivate now")
}
}

private class MyClass2 {}

private extension MyClass2{
  static func myFunc2(){
   print("Same as MyClass.myFunc")
}
}


MyClass.myFunc() // acts like fileprivate
MyClass2.myFunc2() // The proposed change would hide myFunc2
 //Error: 'myFunc2' is inaccessible due to 'private' protection 
level






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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 6, 2017, at 11:07 AM, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> On Fri, Oct 6, 2017 at 10:16 AM Jose Cheyo Jimenez via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On Oct 6, 2017, at 7:10 AM, Vladimir.S <sva...@gmail.com 
>> <mailto:sva...@gmail.com>> wrote:
>> 
>> On 05.10.2017 20:52, Jose Cheyo Jimenez via swift-evolution wrote:
>>>> On Oct 5, 2017, at 4:32 AM, David Hart <da...@hartbit.com 
>>>> <mailto:da...@hartbit.com><mailto:da...@hartbit.com 
>>>> <mailto:da...@hartbit.com>>> wrote:
>>>> 
>>>>> 
>>>>> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> 
>>>>> wrote:
>>>>> 
>>>>> I appreciate the enthusiasm but this is not a bug. This was a deliberate 
>>>>> change in swift 3 to make `private extension` usable. If this was a bug 
>>>>> then during swift 3 we should have disallowed `private extension` and 
>>>>> only allowed `fileprivate extension` but that is not what happened. 
>>>>> `private extension` has worked the same since swift 1. I’ve always used 
>>>>> `private extension` when I want to add methods to String or other build 
>>>>> in types. 
>>>> 
>>>> It’s not a bug, but its unfortunate the behaviour wasn’t changed at the 
>>>> same time as SE-0169, and it now is very inconsistent. I also don’t have 
>>>> to rehash previous discussions, but if a Core Team member (Chris) is okay 
>>>> with going ahead with this, perhaps we should consider it.
>>> This could have not been part of 169 because it would've required to lower 
>>> the visibility of the private extension modifier.
>>> “No migration will be necessary as this proposal merely broadens the 
>>> visibility of|private|.”
>>> There was a corner case mentioned when dealing with functions with the same 
>>> name and that was understandable.
>>> private extension is consistent to the way the private scope rules work. 
>>> The word private is explicit at the top level because extensions can only 
>>> be declared at top level. Top level private is always fileprivate. The 
>>> inconsistency is that we have 1 scope ALC and the rest are not. An explicit 
>>> declaration should always take precedence when declaring something like an 
>>> access level override.
>> 
>> FWIW, I can't agree with this. 'private extension' is a real point of 
>> additional confusion for access levels in Swift.
>> Extension *by itself* has no access level, we only can specify the *default* 
>> (and the top most) access level for inner methods.
>> I.e. 'private' access modifier for extension has not the same meaning as 
>> 'private' func/type/variable at file scope.
>> (Yes, I also believe we should disallow 'private' keyword at file level and 
>> allow it only for extensions, so 'fileprivate' should be used explicitly if 
>> one needs this. At least warning should be raised. This is the *root* of the 
>> problem we discuss now. But unfortunately I don't expect this could be 
>> supported.)
> 
> Wouldn't that just add a special rule to extensions? :)
> 
> 
>> The latter is 'direct' access level for the func/type/variable and here we 
>> apply the standard rule for scoped private, so 'private' for file scope --> 
>> 'fileprivate'.
>> 
> 
>> The former means 'the default(and top most) modifier that will be 
>> auto-inserted by compiler for all nested methods in extension'. This 
>> relatively simple rule should not be complicated by additional rule as ", 
>> but if it is private extension, result access level will be fileprivate, you 
>> can't have extensions with private methods”
> 
> Private as it exist in swift now is the scope access control label. The 
> compiler does not insert the modifier without having to first compute what 
> access control level would be applied to the members of the extension.  Doing 
> it the other way would be counterintuitive for an scope access label. In my 
> code base I disallow top level fileprivate because private top level is 
> fileprivate. This is a matter of taste and a linter here would help like a 
> mentioned up thread.
> 
> This is the sticking point, which is why there are two possible 
> interpretations of 

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 6, 2017, at 7:10 AM, Vladimir.S <sva...@gmail.com> wrote:
> 
> On 05.10.2017 20:52, Jose Cheyo Jimenez via swift-evolution wrote:
>>> On Oct 5, 2017, at 4:32 AM, David Hart <da...@hartbit.com 
>>> <mailto:da...@hartbit.com>> wrote:
>>> 
>>>> 
>>>> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> I appreciate the enthusiasm but this is not a bug. This was a deliberate 
>>>> change in swift 3 to make `private extension` usable. If this was a bug 
>>>> then during swift 3 we should have disallowed `private extension` and only 
>>>> allowed `fileprivate extension` but that is not what happened. `private 
>>>> extension` has worked the same since swift 1. I’ve always used `private 
>>>> extension` when I want to add methods to String or other build in types. 
>>> 
>>> It’s not a bug, but its unfortunate the behaviour wasn’t changed at the 
>>> same time as SE-0169, and it now is very inconsistent. I also don’t have to 
>>> rehash previous discussions, but if a Core Team member (Chris) is okay with 
>>> going ahead with this, perhaps we should consider it.
>> This could have not been part of 169 because it would've required to lower 
>> the visibility of the private extension modifier.
>> “No migration will be necessary as this proposal merely broadens the 
>> visibility of|private|.”
>> There was a corner case mentioned when dealing with functions with the same 
>> name and that was understandable.
>> private extension is consistent to the way the private scope rules work. The 
>> word private is explicit at the top level because extensions can only be 
>> declared at top level. Top level private is always fileprivate. The 
>> inconsistency is that we have 1 scope ALC and the rest are not. An explicit 
>> declaration should always take precedence when declaring something like an 
>> access level override.
> 
> FWIW, I can't agree with this. 'private extension' is a real point of 
> additional confusion for access levels in Swift.
> Extension *by itself* has no access level, we only can specify the *default* 
> (and the top most) access level for inner methods.
> I.e. 'private' access modifier for extension has not the same meaning as 
> 'private' func/type/variable at file scope.
> (Yes, I also believe we should disallow 'private' keyword at file level and 
> allow it only for extensions, so 'fileprivate' should be used explicitly if 
> one needs this. At least warning should be raised. This is the *root* of the 
> problem we discuss now. But unfortunately I don't expect this could be 
> supported.)

Wouldn't that just add a special rule to extensions? :)

> The latter is 'direct' access level for the func/type/variable and here we 
> apply the standard rule for scoped private, so 'private' for file scope --> 
> 'fileprivate'.
> 
> The former means 'the default(and top most) modifier that will be 
> auto-inserted by compiler for all nested methods in extension'. This 
> relatively simple rule should not be complicated by additional rule as ", but 
> if it is private extension, result access level will be fileprivate, you 
> can't have extensions with private methods”

Private as it exist in swift now is the scope access control label. The 
compiler does not insert the modifier without having to first compute what 
access control level would be applied to the members of the extension.  Doing 
it the other way would be counterintuitive for an scope access label. In my 
code base I disallow top level fileprivate because private top level is 
fileprivate. This is a matter of taste and a linter here would help like a 
mentioned up thread.

> 
> And, as was already said, this inconsistency leads to *relaxed* access level, 
> which can lead to bugs. If one expects 'private extension' means 'fileprivate 
> extension' - compiler will show(with error) that this assumption is wrong 
> just after the first attempt to access methods from outside of the extended 
> type.
> But if one expects true 'private' access level - the methods from private 
> extension could be called from any other code in the same file(by mistake, or 
> because code was written a long time ago, or by another developer) and this 
> clearly could produce complex bugs.
> 
> Also, isn't it a strange code below:
> 
> private extension MyType {
>  func foo() {}
>  private bar() {}
>  fileprivate baz() {} // note that "usually" fileprivate is 'wider' access 
> level
> }

This is also strange too :)

 filepr

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 5, 2017, at 4:32 AM, David Hart <da...@hartbit.com> wrote:
> 
>> 
>> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I appreciate the enthusiasm but this is not a bug. This was a deliberate 
>> change in swift 3 to make `private extension` usable. If this was a bug then 
>> during swift 3 we should have disallowed `private extension` and only 
>> allowed `fileprivate extension` but that is not what happened. `private 
>> extension` has worked the same since swift 1. I’ve always used `private 
>> extension` when I want to add methods to String or other build in types. 
> 
> It’s not a bug, but its unfortunate the behaviour wasn’t changed at the same 
> time as SE-0169, and it now is very inconsistent. I also don’t have to rehash 
> previous discussions, but if a Core Team member (Chris) is okay with going 
> ahead with this, perhaps we should consider it.

This could have not been part of 169 because it would've required to lower the 
visibility of the private extension modifier.

“No migration will be necessary as this proposal merely broadens the visibility 
of private.”

There was a corner case mentioned when dealing with functions with the same 
name and that was understandable. 

private extension is consistent to the way the private scope rules work. The 
word private is explicit at the top level because extensions can only be 
declared at top level. Top level private is always fileprivate. The 
inconsistency is that we have 1 scope ALC and the rest are not. An explicit 
declaration should always take precedence when declaring something like an 
access level override.

> 
>> private is different because it is scoped so because of that it is also 
>> different when dealing with extensions. Top level private is always the same 
>> as fileprivate thanks to its scoped nature. 
>> 
>> Making private the scope ACL was a mistake but that ship has sailed and so 
>> has this one imo. 
>> 
>> 
>> 
>> On Oct 4, 2017, at 10:05 PM, Tony Allevato <tony.allev...@gmail.com 
>> <mailto:tony.allev...@gmail.com>> wrote:
>> 
>>> Trust me, I'm the last person who wants to rehash access levels in Swift 
>>> again. But that's not what's happening here, IMO, and fixing bugs is not 
>>> just "a change for the sake of changing."
>>> 
>>> The current behavior of "private extension" is *incorrect*, because it's 
>>> entirely inconsistent with how access levels on extensions are documented 
>>> to behave and it's inconsistent with how other access levels apply to 
>>> extensions.
>>> 
>>> Can anyone think of a reason—other than "it's too late to change it"—why 
>>> "private extension" and "fileprivate extension" should behave the same, and 
>>> why "X extension { decl }" should be identical to "extension { X decl }" 
>>> for all X *except* "private"?
>>> 
>>> Yes, it's absolutely unfortunate that this oversight was not addressed when 
>>> the other access level changes were made. But we shouldn't have to live 
>>> with bugs in the language because we're afraid of some unknown amount of 
>>> churn among code that is already written incorrectly. Nor is fixing this 
>>> bug declaring open season on other, unrelated access level debates. Do you 
>>> have data that shows that the amount of code broken because it's using 
>>> "private" when it really should be saying "fileprivate" is high enough that 
>>> we should just leave the bug there?
>>> 
>>> On Wed, Oct 4, 2017 at 9:51 PM Jose Cheyo Jimenez via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> There was a high bar for breaking changes in swift 4 and is even higher for 
>>> swift 5.  se-110 was approved and implemented on the premises that it was 
>>> not a big change but it was breaking code so it got reverted. Sure the 
>>> migrator was making this easier but the result was a usability regression. 
>>> I think this is a change just for the sake of changing. This will cause 
>>> unnecessary churn. Let’s leave ACLs alone for the next few versions of 
>>> swift unless we have a way better system. 
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html
>>>  
>>> <https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html>
>>> 
>>> 
>>

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

I appreciate the enthusiasm but this is not a bug. This was a deliberate change 
in swift 3 to make `private extension` usable. If this was a bug then during 
swift 3 we should have disallowed `private extension` and only allowed 
`fileprivate extension` but that is not what happened. `private extension` has 
worked the same since swift 1. I’ve always used `private extension` when I want 
to add methods to String or other build in types. 

private is different because it is scoped so because of that it is also 
different when dealing with extensions. Top level private is always the same as 
fileprivate thanks to its scoped nature. 

Making private the scope ACL was a mistake but that ship has sailed and so has 
this one imo. 



> On Oct 4, 2017, at 10:05 PM, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> Trust me, I'm the last person who wants to rehash access levels in Swift 
> again. But that's not what's happening here, IMO, and fixing bugs is not just 
> "a change for the sake of changing."
> 
> The current behavior of "private extension" is *incorrect*, because it's 
> entirely inconsistent with how access levels on extensions are documented to 
> behave and it's inconsistent with how other access levels apply to extensions.
> 
> Can anyone think of a reason—other than "it's too late to change it"—why 
> "private extension" and "fileprivate extension" should behave the same, and 
> why "X extension { decl }" should be identical to "extension { X decl }" for 
> all X *except* "private"?
> 
> Yes, it's absolutely unfortunate that this oversight was not addressed when 
> the other access level changes were made. But we shouldn't have to live with 
> bugs in the language because we're afraid of some unknown amount of churn 
> among code that is already written incorrectly. Nor is fixing this bug 
> declaring open season on other, unrelated access level debates. Do you have 
> data that shows that the amount of code broken because it's using "private" 
> when it really should be saying "fileprivate" is high enough that we should 
> just leave the bug there?
> 
>> On Wed, Oct 4, 2017 at 9:51 PM Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> There was a high bar for breaking changes in swift 4 and is even higher for 
>> swift 5.  se-110 was approved and implemented on the premises that it was 
>> not a big change but it was breaking code so it got reverted. Sure the 
>> migrator was making this easier but the result was a usability regression. I 
>> think this is a change just for the sake of changing. This will cause 
>> unnecessary churn. Let’s leave ACLs alone for the next few versions of swift 
>> unless we have a way better system. 
>> 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html
>> 
>> 
>> 
>> 
>> 
>>> On Oct 4, 2017, at 8:47 PM, BJ Homer <bjho...@gmail.com> wrote:
>>> 
>>> It certainly could break *some* code. But it only breaks code written by an 
>>> author who wrote ‘private extension’ knowing that ‘fileprivate extension’ 
>>> was also an option, but still intended it to be shared with the whole file. 
>>> (If that code was from Swift 2, it would have already been migrated to 
>>> ‘fileprivate extension’ by the 2->3 migrator.)
>>> 
>>> So existing code that says ‘private extension’ was written in a Swift 3 or 
>>> 4 era when ‘fileprivate’ was an option. If the goal was specifically to 
>>> share it with the whole file, it seems likely that most authors would have 
>>> used ‘fileprivate extension’ instead of ‘private extension’, as that better 
>>> communicates the intention. Regardless, though, we could check against the 
>>> Swift source compatibility test suite to see how widespread that is.
>>> 
>>> Regardless, I think this change makes Swift a better language, and I’m in 
>>> favor of it.
>>> 
>>> -BJ
>>> 
>>>> On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> 
>>>>>>> On Mon, Oct 2, 2017 at 9:16

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

There was a high bar for breaking changes in swift 4 and is even higher for 
swift 5.  se-110 was approved and implemented on the premises that it was not a 
big change but it was breaking code so it got reverted. Sure the migrator was 
making this easier but the result was a usability regression. I think this is a 
change just for the sake of changing. This will cause unnecessary churn. Let’s 
leave ACLs alone for the next few versions of swift unless we have a way better 
system. 

https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html





> On Oct 4, 2017, at 8:47 PM, BJ Homer <bjho...@gmail.com> wrote:
> 
> It certainly could break *some* code. But it only breaks code written by an 
> author who wrote ‘private extension’ knowing that ‘fileprivate extension’ was 
> also an option, but still intended it to be shared with the whole file. (If 
> that code was from Swift 2, it would have already been migrated to 
> ‘fileprivate extension’ by the 2->3 migrator.)
> 
> So existing code that says ‘private extension’ was written in a Swift 3 or 4 
> era when ‘fileprivate’ was an option. If the goal was specifically to share 
> it with the whole file, it seems likely that most authors would have used 
> ‘fileprivate extension’ instead of ‘private extension’, as that better 
> communicates the intention. Regardless, though, we could check against the 
> Swift source compatibility test suite to see how widespread that is.
> 
> Regardless, I think this change makes Swift a better language, and I’m in 
> favor of it.
> 
> -BJ
> 
>> On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>> 
>>> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> 
>>>> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>>> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> 
>>>>> Sent from my iPad
>>>>> 
>>>>>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>> 
>>>>>>> On 01.10.2017 1:18, Chris Lattner wrote:
>>>>>>>>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>> 
>>>>>>>>> Vladimir, I agree with you on that change, but it’s a separate topic 
>>>>>>>>> from this one.
>>>>>>>>> 
>>>>>>>>> Tony is absolutely correct that this topic has already been 
>>>>>>>>> discussed. It is a deliberate design decision that public types do 
>>>>>>>>> not automatically expose members without explicit access modifiers; 
>>>>>>>>> this has been brought up on this list, and it is clearly not in scope 
>>>>>>>>> for discussion as no new insight can arise this late in the game. The 
>>>>>>>>> inconsistency with public extensions was brought up, the proposed 
>>>>>>>>> solution was to remove modifiers for extensions, but this proposal 
>>>>>>>>> was rejected. So, the final design is what we have.
>>>>>>>> Agreed.  The core team would only consider a refinement or change to 
>>>>>>>> access control if there were something actively broken that mattered 
>>>>>>>> for ABI stability.
>>>>>>> 
>>>>>>> So we have to live with *protected* extension inconsistency for very 
>>>>>>> long time just because core team don't want to even discuss _this 
>>>>>>> particular_ inconsistency(when access level in *private extension* must 
>>>>>>> be private, not fileprivate)?
>>>>>>> 
>>>>>>> Yes, we decided that access level for extension will mean a default and 
>>>>>>> top most access level for nested methods, OK. But even in this rule, 
>>>

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
>> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>>> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
  wrote:
 
 
 
> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 01.10.2017 1:18, Chris Lattner wrote:
>>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Vladimir, I agree with you on that change, but it’s a separate topic 
>>> from this one.
>>> 
>>> Tony is absolutely correct that this topic has already been discussed. 
>>> It is a deliberate design decision that public types do not 
>>> automatically expose members without explicit access modifiers; this 
>>> has been brought up on this list, and it is clearly not in scope for 
>>> discussion as no new insight can arise this late in the game. The 
>>> inconsistency with public extensions was brought up, the proposed 
>>> solution was to remove modifiers for extensions, but this proposal was 
>>> rejected. So, the final design is what we have.
>> Agreed.  The core team would only consider a refinement or change to 
>> access control if there were something actively broken that mattered for 
>> ABI stability.
> 
> So we have to live with *protected* extension inconsistency for very long 
> time just because core team don't want to even discuss _this particular_ 
> inconsistency(when access level in *private extension* must be private, 
> not fileprivate)?
> 
> Yes, we decided that access level for extension will mean a default and 
> top most access level for nested methods, OK. But even in this rule, 
> which already differ from access modifiers for types, we have another one 
> special case for 'private extension'.
> 
> Don't you think this is not normal situation and actually there IMO can't 
> be any reason to keep this bug-producing inconsistency in Swift? 
> (especially given Swift 5 seems like is a last moment to fix this)
 
 I hate to say it but I'm inclined to agree with Vladimir on this. "private 
 extension" has a useful meaning now distinct from "fileprivate extension", 
 and it was an oversight that SE-0169 didn't include a fix here. On this 
 very narrow, very specific access control issue I think it would still be 
 worth discussing; like Xiaodi said it's not related to James' original 
 thread-starter.
>>> 
>>> I agree with this in principle but would not want to see it become a 
>>> slippery slope back into extremely long access control discussions.
>>> 
>> 
>> As I've said elsewhere, I too agree with this in principle. I agree with 
>> Jordan that the current state of things is justifiable but the alternative 
>> would be somewhat superior, agree that in a vacuum this very narrow and 
>> specific discussion might be warranted, and agree also that this could be a 
>> very slippery slide down a very steep slope.
> 
> Same here. It’s the only grudge I have left with the current access control 
> situation. I remember Doug Gregor and John McCall discussing this during the 
> last access control proposal. And I wouldn’t mind having a very narrow 
> discussion about only this.
> 
> I organize my types into extensions for each conformance and for each access 
> control. I can currently implicitly apply public or fileprivate to all 
> members of an extension but I have no way of doing the same for private. 
> That’s why I think it should be fixed.

This will break a bunch of code because `private extension` has always meant 
`fileprivate extension`. Even Swift 3 had this same behavior. Lowering the 
access level of the extension members will hide a bunch of code that was 
visible to the file. 

169 was not a breaking change but this “fix” would have made it a breaking 
change. I doubt 169 would had been accepted if it was a breaking change. I 
don’t think it’s worth it. 


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md



> 
 
 (I maintain that the current model does not include a special case; it 
 simply means the 'private' is resolved at the level of the extension 
 rather than the level of its members. But that isn't what people expect 
 and it's not as useful.)
 
 
 I agree that changing the behavior of all access modifiers on extensions 
 is out of scope. (I also agree that it is a bad idea. Sorry, James, but 
 wanting 'pubic' here indicates that your mental model of 

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>> > wrote:
>> 
>> On 01.10.2017 1:18, Chris Lattner wrote:
 On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 Vladimir, I agree with you on that change, but it’s a separate topic from 
 this one.
 
 Tony is absolutely correct that this topic has already been discussed. It 
 is a deliberate design decision that public types do not automatically 
 expose members without explicit access modifiers; this has been brought up 
 on this list, and it is clearly not in scope for discussion as no new 
 insight can arise this late in the game. The inconsistency with public 
 extensions was brought up, the proposed solution was to remove modifiers 
 for extensions, but this proposal was rejected. So, the final design is 
 what we have.
>>> Agreed.  The core team would only consider a refinement or change to access 
>>> control if there were something actively broken that mattered for ABI 
>>> stability.
>> 
>> So we have to live with *protected* extension inconsistency for very long 
>> time just because core team don't want to even discuss _this particular_ 
>> inconsistency(when access level in *private extension* must be private, not 
>> fileprivate)?
>> 
>> Yes, we decided that access level for extension will mean a default and top 
>> most access level for nested methods, OK. But even in this rule, which 
>> already differ from access modifiers for types, we have another one special 
>> case for 'private extension'.
>> 
>> Don't you think this is not normal situation and actually there IMO can't be 
>> any reason to keep this bug-producing inconsistency in Swift? (especially 
>> given Swift 5 seems like is a last moment to fix this)
> 
> I hate to say it but I'm inclined to agree with Vladimir on this. "private 
> extension" has a useful meaning now distinct from "fileprivate extension", 
> and it was an oversight that SE-0169 
> 
>  didn't include a fix here. On this very narrow, very specific access control 
> issue I think it would still be worth discussing; like Xiaodi said it's not 
> related to James' original thread-starter.
> 
> (I maintain that the current model does not include a special case; it simply 
> means the 'private' is resolved at the level of the extension rather than the 
> level of its members. But that isn't what people expect and it's not as 
> useful.)
> 
> 
> I agree that changing the behavior of all access modifiers on extensions is 
> out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 
> 'pubic' here indicates that your mental model of extensions does not match 
> what Swift is actually doing, and that could get you into trouble.)
> 
> Jordan


I am not in favor of including a special case for “private extension” because 
like Jordan said, private is resolved at the level of the extension which is 
always top level currently. A change would make sense if we start allowing 
extensions that are not top level. Anything private that is top level is 
equivalent to fileprivate so why should “private extension” be any different?

This is only confusing if people start mixing “fileprivate extension” and 
“private extension” in the same code base. 

We have a SwiftLint rule for this situation:
https://github.com/realm/SwiftLint/blame/master/Source/SwiftLintFramework/Rules/PrivateOverFilePrivateRule.swift
 


Alternatively you can enforce no extensions :)
https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/NoExtensionAccessModifierRule.swift
 


“"There is no solution that will make everyone happy: maintaining the status 
quo makes “fileprivate” too common and therefore not meaningful when it occurs 
in source;”"
https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html
 











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

Re: [swift-evolution] Enums and Source Compatibility

[Jose Cheyo Jimenez via swift-evolution]

Here is an alternative view. I've been thinking about this and I feel that 
instead of adding this to an enum why not make RawRepresentable structs a swift 
construct. 

You could declare it like this:

enum struct {
   case a, b, c
}

This would be a struct that acts like an enum but it is open like a 
RawRepresentable but using the enum case sugar. 

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

Re: [swift-evolution] Revisiting SE-0110

[Jose Cheyo Jimenez via swift-evolution]

The way I interpreted SE-110 is that it was suppose to address anonymous 
arguments. 

Instead of using $0.0, $0.1, One needs to use $0, $1 when there are multiple 
arguments. 

I was not aware of any implications for explicitly named parameters. 

Perhaps the issue is with the signature of forEach. Does it need to be a nested 
tuple?

public func forEach(_ body: ((key: Key, value: Value)) throws -> Void) rethrows


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

[Jose Cheyo Jimenez via swift-evolution]

Hi Andrew, 

Implicitly making Tuples Hashable should be its own proposal. Take a look at 
the Equable Tuple proposal as a template. 
https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md
 


Thanks


> On May 9, 2017, at 3:45 PM, Andrew Bennett via swift-evolution 
>  wrote:
> 
> You state that you will not synthesise conformance for tuples, I agree with 
> this, but if a struct or enum holds a tuple it would be nice if it could be 
> hashed if its members are all hashable.
> 
> struct A {
>   var a: Int, b: Int, c: Int
> }
> 
> struct B {
>   var tuple: (a: Int, b: Int, c: Int)
> }
> 
> I'd consider these two to be equivalent as far as this proposal is concerned, 
> it would be nice if the proposal made that explicit.
> 
> 
> On Tue, May 9, 2017 at 7:17 AM, Tony Allevato via swift-evolution 
> > wrote:
> 
> 
> On Mon, May 8, 2017 at 2:11 PM Matthew Johnson  > wrote:
>> On May 8, 2017, at 4:02 PM, Tony Allevato > > wrote:
>> 
>> On Sat, May 6, 2017 at 4:17 PM Chris Lattner > > wrote:
>> On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution 
>> > wrote:
>>> 
>>> 
>>> 
>>> Can the opt-in conformance be declared in an extension?  If so, can the 
>>> extension be in a different module than the original declaration?  If so, 
>>> do you intend any restrictions, such as requiring all members of the type 
>>> declared in a different module to be public?  My initial thought is that 
>>> this should be possible as long as all members are visible.
>>> 
>>> Declaring the conformance in an extension in the same module should 
>>> definitely be allowed;
>> 
>> Please follow the precedent of the Codable proposal as closely as possible.  
>> If you’d like this to be successful for Swift 4, you should look to scope it 
>> as narrowly as possible.  Because it is additive (with opt-in), it can 
>> always be extended in the future.
>> 
>>> I believe this would currently be the only way to support conditional 
>>> conformances (such as the `Optional: Hashable where Wrapped: Hashable` 
>>> example in the updated draft), without requiring deeper syntactic changes.
>> 
>> This proposal doesn’t need to cover all cases, since it is just sugaring a 
>> (very common) situation.  Conditional conformances to Hashable could be 
>> written manually.
>> 
>>> I'm less sure about conformances being added in other modules,
>> 
>> It is a bad idea, it would break resilience of the extended type.
>> 
>>> But after writing this all out, I'm inclined to agree that I'd rather see 
>>> structs/enums make it into Swift 4 even if it meant pushing classes to 
>>> Swift 4+x.
>> 
>> Agreed, keep it narrow to start with.
>> 
>> Also, I don’t know how the rest of the core team feels about this, but I 
>> suspect that they will be reticent to take an additive proposal at this late 
>> point in the schedule, unless someone is willing to step up to provide an 
>> implementation.
>> 
>> That someone is me :)  I have a branch where it's working for enums (modulo 
>> some weirdness I need to fix after rebasing a two-month-old state), and 
>> adapting that logic to structs should hopefully be straightforward after 
>> that. Going with the more narrowly-scoped proposal and making conformances 
>> explicit simplifies the implementation a great deal as well (I was 
>> previously blocked with recursive types when it was implicit).
>> 
>> Thanks for the feedback—after consideration, I've pulled classes out of the 
>> proposal completely (even non-final) and mentioned the other limitations so 
>> we'd have a record of what was discussed in this thread.
>> 
>> I've created a PR for the proposal text, in the event that the core team is 
>> interested in moving this forward: 
>> https://github.com/apple/swift-evolution/pull/706 
>> 
> Thanks for continuing to push this forward Tony!  The current proposal looks 
> like the right approach for getting this into Swift 4.  
> 
> I only have one question which I will present with an example:
> 
> protocol Foo: Equatable {}
> protocol Bar: Hashable {}
> 
> struct FooType: Foo {}
> struct BarType: Bar {}
> 
> Do FooType and BarType receive synthesis?
> 
> Great question! Yes they should. It's "explicit" transitively since the 
> answer to "does FooType/BarType conform to Equatable/Hashable?" is still 
> "yes". (And I've confirmed that my prototype handles this case.)
> 
> This is especially helpful since Hashable extends Equatable, so a user only 
> needs to list conformance to the former to get correctly synthesized 

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

[Jose Cheyo Jimenez via swift-evolution]

I filled a bug report. https://bugs.swift.org/browse/SR-4811 
<https://bugs.swift.org/browse/SR-4811>


> On May 5, 2017, at 9:38 AM, Jose Cheyo Jimenez <ch...@masters3d.com> wrote:
> 
> 
>> On May 5, 2017, at 8:34 AM, Vladimir.S <sva...@gmail.com 
>> <mailto:sva...@gmail.com>> wrote:
>> 
>> On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:
>>> I can't think of a single time when I would need a tuple shuffle but I 
>>> don't really work with tuples much. It would be great to hear other 
>>> people's usage of this feature.
>>> I did not know that types could be overloaded with values. That was very 
>>> surprising to me. Honestly I think that is the issue here. Not sure what 
>>> can be done about it.
>> 
>>> let Int = 5 // works
>>> let Void = "what?" // works.
>> 
>> Very interesting. Could some one clarify, why this is allowed? Isn't this is 
>> a bug we want to fix? At least by requiring a tilda like `Int`
>> And of course, you can't "overload" user defined type:
>> struct S {}
>> let S = 10 // Error: invalid redeclaration of ’S'
> 
> What version of swift are you using? Could it be a regression?
> 
> Welcome to Apple Swift version 3.1 (swiftlang-802.0.51 clang-802.0.41). Type 
> :help for assistance.
>   1> struct S {}
>   2> let S = 10
> S: Int = 10
>   3> print(S)
> error: repl.swift:3:7: error: ambiguous use of 'S'
> print(S)
>   ^
> 
> 
> 
>> 
>>> On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> 
>>> 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 <https://github.com/apple/swift-evolution/pull/705/files 
>>>> <https://github.com/apple/swift-evolution/pull/705/files>>.
>>>> 
>>>> Thanks!
>>>> 
>>>> ~Robert Widmann
>>>> 
>>>> 
>>>>  Deprecate Tuple Shuffles
>>>> 
>>>>  * Proposal: SE-
>>>>
>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-filename.md
>>>>  
>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-filename.md>>
>>>>  * Authors: Robert Widmann <https://github.com/codafi 
>>>> <https://github.com/codafi>>
>>>>  * Review Manager: TBD
>>>>  * Status: Awaiting review
>>>> 
>>>> 
>>>>
>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-deprecate-tuple-shuffles.md#introduction
>>>>  
>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-deprecate-tuple-shuffles.md#introduction>>Introduction
>>>> 
>>>> This proposal seeks the deprecation of a little-known feature of Swift 
>>>> called a "Tuple Shuffle".
>>>> 
>>>> 
>>>>
>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-deprecate-tuple-shuffles.md#motivation
>>>>  
>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-deprecate-tuple-shuffles.md#motivation>>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

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

[Jose Cheyo Jimenez via swift-evolution]

> On May 5, 2017, at 8:34 AM, Vladimir.S <sva...@gmail.com> wrote:
> 
> On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:
>> I can't think of a single time when I would need a tuple shuffle but I don't 
>> really work with tuples much. It would be great to hear other people's usage 
>> of this feature.
>> I did not know that types could be overloaded with values. That was very 
>> surprising to me. Honestly I think that is the issue here. Not sure what can 
>> be done about it.
> 
>> let Int = 5 // works
>> let Void = "what?" // works.
> 
> Very interesting. Could some one clarify, why this is allowed? Isn't this is 
> a bug we want to fix? At least by requiring a tilda like `Int`
> And of course, you can't "overload" user defined type:
> struct S {}
> let S = 10 // Error: invalid redeclaration of ’S'

What version of swift are you using? Could it be a regression?

Welcome to Apple Swift version 3.1 (swiftlang-802.0.51 clang-802.0.41). Type 
:help for assistance.
  1> struct S {}
  2> let S = 10
S: Int = 10
  3> print(S)
error: repl.swift:3:7: error: ambiguous use of 'S'
print(S)
  ^



> 
>> On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <https://github.com/apple/swift-evolution/pull/705/files>.
>>> 
>>> Thanks!
>>> 
>>> ~Robert Widmann
>>> 
>>> 
>>>  Deprecate Tuple Shuffles
>>> 
>>>  * Proposal: SE-
>>>
>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-filename.md>
>>>  * Authors: Robert Widmann <https://github.com/codafi>
>>>  * Review Manager: TBD
>>>  * Status: Awaiting review
>>> 
>>> 
>>>
>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-deprecate-tuple-shuffles.md#introduction>Introduction
>>> 
>>> This proposal seeks the deprecation of a little-known feature of Swift 
>>> called a "Tuple Shuffle".
>>> 
>>> 
>>>
>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/-deprecate-tuple-shuffles.md#motivation>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 
>>> <https://twitter.com/CodaFi_/status/860246169854894081>, contradicts the 
>>> goals of earlier SE's (see SE-0060 
>>> <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md>),
>>>  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

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

[Jose Cheyo Jimenez via swift-evolution]

I can't think of a single time when I would need a tuple shuffle but I don't 
really work with tuples much. It would be great to hear other people's usage of 
this feature. 

I did not know that types could be overloaded with values. That was very 
surprising to me. Honestly I think that is the issue here. Not sure what can be 
done about it. 

let Int = 5 // works 
let Void = "what?" // works. 


> On May 4, 2017, at 7:14 PM, 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 
> enforce that deprecation as a hard error in Swift 4 to facilitate their 
> eventual removal from the language.
> 
> Proposed solution
> 
> Construction of Tuple Shuffle Expressions will become a warning in Swift 3 
> compatibility mode and will be a hard-error in Swift 4.
> 
> Detailed design
> 
> In addition to the necessary diagnostics, the grammar will be ammended to 
> simplify the following productions:
> 
> tuple-pattern → (tuple-pattern-element-list )
> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , 
> tuple-pattern-element-list
> - tuple-pattern-element → pattern | identifier:pattern
> + tuple-pattern-element → pattern
> Impact on Existing Code
> 
> Because very little code is intentionally using Tuple Shuffles, impact on 
> existing code will be negligible but not non-zero.
> 
> Alternatives considered
> 
> Continue to keep the architecture in place to facilitate this feature.
> ___
> 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-0169: Improve Interaction Between `private` Declarations and Extensions

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 22, 2017, at 2:05 PM, Jose Cheyo Jimenez <ch...@masters3d.com> wrote:
> 
> 
> 
>> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>> 
>>> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>>> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> The "Access Control" section of the Swift 3 book says the following:
>>>>> You can mark an extension with an explicit access-level modifier (for 
>>>>> example, private extension) to set a new default access level for all 
>>>>> members defined within the extension.
>>>> The behavior of "private extension" in Swift 3 was a deviation from that 
>>>> model, justified because "private" as a default would have meant that 
>>>> nothing in the extension could ever be called. But it was still contrary 
>>>> to the model suggested by the Swift documentation. 
>>>> 
>>>> Given the highly restrictive behavior of "private" in Swift 3 and the 
>>>> documentation quoted above, it seems unlikely that a developer would 
>>>> intentionally use "private extension" to mean "please make all this stuff 
>>>> visible to the entire file"—it would have worked, but it seems an odd way 
>>>> to write it. If that were the intention, I think "fileprivate extension" 
>>>> would have been more likely.
>>>> 
>>>> I think the change to the behavior of "private extension" is in line with 
>>>> the model proposed by SE-0169, in line with the documented behavior of 
>>>> access control on extensions, and in line with user expectations.
>>>> 
>>>> -BJ
>>> 
>>> I understand your point. Another aspect of SE-0169 is that fileprivate 
>>> should be more rare and thus meaningful when used. The current behavior 
>>> stays true to the goal of making fileprivate rare. 
>>> 
>>> A top level private scope is effectively fileprivate so it is not totally 
>>> weird for the extension members to inherit the top level private scope. 
>>> 
>>> When extensions gain the ability to contain properties, we should not allow 
>>> the access level modifiers to the extensions in the same way protocol 
>>> extensions prohibit its use. 
>> 
>> That idea would be my preference too, but it has been already written up as 
>> a proposal, considered, and rejected.
> 
> Properties in extensions? AKA partials ? I was thinking disallow only when 
> properties are introduced in the extension not in general. 

I meant stored properties here. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
>> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> The "Access Control" section of the Swift 3 book says the following:
>>>> You can mark an extension with an explicit access-level modifier (for 
>>>> example, private extension) to set a new default access level for all 
>>>> members defined within the extension.
>>> The behavior of "private extension" in Swift 3 was a deviation from that 
>>> model, justified because "private" as a default would have meant that 
>>> nothing in the extension could ever be called. But it was still contrary to 
>>> the model suggested by the Swift documentation. 
>>> 
>>> Given the highly restrictive behavior of "private" in Swift 3 and the 
>>> documentation quoted above, it seems unlikely that a developer would 
>>> intentionally use "private extension" to mean "please make all this stuff 
>>> visible to the entire file"—it would have worked, but it seems an odd way 
>>> to write it. If that were the intention, I think "fileprivate extension" 
>>> would have been more likely.
>>> 
>>> I think the change to the behavior of "private extension" is in line with 
>>> the model proposed by SE-0169, in line with the documented behavior of 
>>> access control on extensions, and in line with user expectations.
>>> 
>>> -BJ
>> 
>> I understand your point. Another aspect of SE-0169 is that fileprivate 
>> should be more rare and thus meaningful when used. The current behavior 
>> stays true to the goal of making fileprivate rare. 
>> 
>> A top level private scope is effectively fileprivate so it is not totally 
>> weird for the extension members to inherit the top level private scope. 
>> 
>> When extensions gain the ability to contain properties, we should not allow 
>> the access level modifiers to the extensions in the same way protocol 
>> extensions prohibit its use. 
> 
> That idea would be my preference too, but it has been already written up as a 
> proposal, considered, and rejected.

Properties in extensions? AKA partials ? I was thinking disallow only when 
properties are introduced in the extension not in general. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> The "Access Control" section of the Swift 3 book says the following:
>> You can mark an extension with an explicit access-level modifier (for 
>> example, private extension) to set a new default access level for all 
>> members defined within the extension.
> The behavior of "private extension" in Swift 3 was a deviation from that 
> model, justified because "private" as a default would have meant that nothing 
> in the extension could ever be called. But it was still contrary to the model 
> suggested by the Swift documentation. 
> 
> Given the highly restrictive behavior of "private" in Swift 3 and the 
> documentation quoted above, it seems unlikely that a developer would 
> intentionally use "private extension" to mean "please make all this stuff 
> visible to the entire file"—it would have worked, but it seems an odd way to 
> write it. If that were the intention, I think "fileprivate extension" would 
> have been more likely.
> 
> I think the change to the behavior of "private extension" is in line with the 
> model proposed by SE-0169, in line with the documented behavior of access 
> control on extensions, and in line with user expectations.
> 
> -BJ

I understand your point. Another aspect of SE-0169 is that fileprivate should 
be more rare and thus meaningful when used. The current behavior stays true to 
the goal of making fileprivate rare. 

A top level private scope is effectively fileprivate so it is not totally weird 
for the extension members to inherit the top level private scope. 

When extensions gain the ability to contain properties, we should not allow the 
access level modifiers to the extensions in the same way protocol extensions 
prohibit its use. 


> 
>> On Apr 21, 2017, at 9:30 AM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>> 
 On Apr 20, 2017, at 7:53 PM, John McCall  wrote:
 
> On Apr 20, 2017, at 7:31 PM, Douglas Gregor  wrote:
>> On Apr 20, 2017, at 3:39 PM, John McCall  wrote:
>> 
>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor  
>>> wrote:
>>> 
>>> 
> On Apr 20, 2017, at 11:33 AM, Jordan Rose  
> wrote:
> 
> 
> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>  wrote:
> 
> This makes the private/fileprivate distinction meaningful for 
> extensions. I think also bans the use of "private" at global scope 
> for non-nominal types or extensions thereof.  A clarifying update to 
> the proposal is in order, so developers can better understand the 
> semantics. 
 
 Wait, hang on, then people have to write 'fileprivate' instead of 
 'private' for top-level typealiases (and functions?). 
>>> 
>>> That seems like the correct behavior; private is about members with 
>>> SE-0169. What do you think?
>> 
>> ...that seems suboptimal, given that the goal has been to make it 
>> possible for people to use `private` more and not less frequently. IMO, 
>> there's no need for `private typealias` at the global level to be 
>> prohibited.
> 
> Yeah, I see no reason for this to change the behavior of private 
> extensions to be more restrictive than before.
 
 So you’re okay with:
 
private extension X {
  func foo() { }
}
 
 being equivalent to
 
extension X {
  fileprivate func foo() { }
}
 
 rather than
 
extension X {
  private func foo() { }
}
 
 ?
 
 That seems unintuitive at best.
>>> 
>>> Perhaps, but it's existing unintuitive behavior.  Are you suggesting that 
>>> SE-0169 rationalizes changing it because (1) it's likely that a private 
>>> extension is just meant for the use of other extensions of that type in the 
>>> current file and (2) SE-0169 already allows such uses and so justifies the 
>>> stricter rule?  That is an interesting theory, but I'm not sure I believe 
>>> (1).  
>> 
>> I’m saying (2), and I suspect (1) is most often the case… but I agree that 
>> we’re likely to end up breaking code here.
>> 
>>> More importantly, though, SE-0169 didn't actually propose changing this 
>>> behavior, and it's a very substantial shift in behavior, and we haven't 
>>> actually discussed or gathered any community feedback about it, so I'm 
>>> really struggling to see why it wouldn't need to be a separate evolution 
>>> proposal.  
>> 
>> I was interpreting SE-0169 to mean this, but you are correct: SE-0169 
>> doesn’t spell out a change here.
>> 
>>> And that would be 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>  wrote:
> 
> I don't want to make any change until Chris has been able to chime in. If he 
> agrees with us, what should be done?
> 
> • Immediate change in the proposal?
> • Would it have to go through a new review?
This is major change. I would hope for a new review if the proposal is being 
accepted. 

I would also want this new behavior to be explicit thus making it a non 
breaking change. 
 
> • Or can the Core Team make the change if it is accepted?
> 
>> On 11 Apr 2017, at 19:01, John McCall  wrote:
>> 
>> 
>>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
>>> 
 
 
 Sent from my iPad
 
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall  wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>  wrote:
> 
>> I have not voted in favor or against the proposal. I have been 
>> reading a lot of responses but I agree with Tony. 
>> 
>> When I started reading the proposal everything was more or less fine 
>> half way through the proposal because it was reverting private to 
>> fileprivate between the type and its extensions within the same 
>> file. I said, if you think of the type and its extensions as a unit 
>> then it makes sense. I can explain that. 
>> 
>> Then it started describing a different behavior among the extensions 
>> located in a file separate from the file containing the definition 
>> of the type. That just started a whole debate inside my head and I 
>> understand the passionate responses on both sides. 
>> 
>> But then I imagined myself explaining this to someone new to Swift 
>> and it just doesn't seem right. If it becomes convoluted then that's 
>> a red flag that it does not belong in Swift. 
> 
> I understand what you are saying and I wouldn't be against relaxing 
> that requirement (not talking for Chris here).
> 
> The model would change from "Types share scopes with their extensions 
> in the same file the type was defined" to "Types and their extensions 
> share the same scope in each file".
 
 Oh, I had missed that somehow.  I agree that that is a very strange 
 rule.  Do you know why it was proposed that way?
>>> 
>>> We had to take a stance and Chris seemed to prefer the rule that was 
>>> proposed. I didn't press because I'm sure he has reasons for preferring 
>>> it that way. But I have a preference for generalizing visibility to all 
>>> extensions, even to those in a different file than the type.
>> 
>> I think there is a technical limitation if the visibility goes beyond 
>> the compilation unit (unless whole module optimization is turned on).
> 
> I’m not suggesting visibility beyond the compilation unit. That would 
> break the hierarchy of visibility layers: accessibility levels have 
> always been contained in one-another and that’s why you can go from 
> private, to fileprivate, to internal, to public, to open (but not the 
> other way round) without the risk of any compilation error. If all scopes 
> of a type were visible to each other (whatever the file), you could not 
> go from private to fileprivate.
> 
> I’m talking about extensions of the same type in the same file (but in a 
> separate file from the type) to be able to share private members:
> 
> Type.swift
> 
> struct A {
> }
> 
> Other.swift
> 
> extension A {
> func foo() {
> bar()
> }
> }
> 
> extension A {
> private func bar() {
> }
> }
> 
 
 If this is not how your proposal already works I missed that aspect 
 earlier and find it extremely perplexing (which is probably why I missed 
 it).
>>> 
>>> It's mentioned in the Derailed design section:
>>> 
>>> This proposal does not change the behavior of extensions that are not in 
>>> the same file as the type - i.e., extensions in a seperate file to the type 
>>> do not share access between themselves:
>>> 
>>> 

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

[Jose Cheyo Jimenez via swift-evolution]

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

I agree with you here. I don't think the proposal will be accepted as is, 
because of the breaking change. 

What if there was a way to make this a new feature so it is not a breaking 
change?

I can see this same proposal being accepted if it was revised to mark the new 
extension behavior explicitly.

Type.swift

struct A { 
private func foo() {}
}

*partial* extension A {  // any other keyword would do here or even \
func baz() {
foo()  // okay 
}
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}

Other.swift

*partial* extension A {  // error. Partial extensions only allowed within the 
declaring file. 
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}



> 
> 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] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 10:22 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>>> I don't buy this argument at all without an objective explanation why the 
>>> curly braces of extensions should be treated different than the curly 
>>> braces of types…
>> Extensions are not Partials. 
>>> do you think sprinkling parts of class over the project is easier to follow?
>> Extensions are not Partials. 
> I can't see how statement and answer(?) are related to the original post… or 
> did I miss that this topic is about partials? :)
I am partial to partials. :)
> 
>>> it can be delayed for as long as the core team likes, without causing any 
>>> trouble.
>> Partials limited to the same scope can do the same
> That is true… so can we agree that nothing should change now, so that 
> something can be added later? ;-)
Same page. 
> 
>> with out having to give extension special nesting powers :)
> I would say there's no doubt that extensions are withhold the common nesting 
> powers of all other, similar constructs in Swift: Classes can be nested, 
> Structs can be nested, Enums can be nested, functions can be nested, 
> protocols… I haven't tried yet, but associated objects are something 
> comparable ;-)

___
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

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 7, 2017, at 12: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.

My understanding is that the slowdowns are produced when the inference has to 
take into account generics. If somebody is using lots of generics and 
overloads; I would hope they would know that this can slow down compile times. 
I am not sure how this can be communicated to the user other than showing a 
warning. 


> 
> 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
> ___
> 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] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 9:49 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> But even outside the generated code use cases, it's nice to just be able to 
>> implement helpers or additional "convenience" conformances in separate files 
>> named appropriately (like "Type+Protocol.swift" or "Type+Helpers.swift"). I 
>> find it makes my codebase easier to navigate.
> No doubt about the usefulness of having separate files with extensions here
> 
>> If nothing else, nested extensions could save those who actually don't care 
>> much about such issues from another breaking change in Swift — and imho it 
>> adds consistency:
>> We can nest types, so why can't we nest extensions?
>> 
>> Because types and extensions are quite different beasts, so something that 
>> applies to one doesn't necessarily apply to the other.
> I don't buy this argument at all without an objective explanation why the 
> curly braces of extensions should be treated different than the curly braces 
> of types…
Extensions are not Partials. 
> 
>> I don't think that holds its weight. This feels like another case of "let's 
>> try to satisfy everyone who's unhappy with some part of Swift visibility by 
>> changing a completely different feature to make things fall into place", 
>> which I don't think is a sound motivation or design principle. The example 
>> you posted in your initial message weaves multiple types/nesting levels 
>> together in a way that looks *incredibly* difficult to follow/parse to even 
>> an experienced user of the language.
> Did you noticed that I started this example as mockery? In real life, I would 
> hopefully never nest more than once… and do you think sprinkling parts of 
> class over the project is easier to follow?
Extensions are not Partials. 
> 
>> Everyone seems to be striving for a "perfect" level of access control that 
>> lets individual types/members dictate precisely what other types/members can 
>> access them. I'm not sure if that perfection is attainable or not, but even 
>> if it is, I don't think it's something we should strive for. I'd rather have 
>> a simple visibility model that leaks a little than an air-tight model that 
>> allows people to write overly complicated code for the sake of fine-tuning 
>> access.
> I had no desire to change the model of Swift 2 — but apparently, others 
> thought it wasn't sufficient, and I'd rather prefer a conceptually simple 
> model like nesting over a complicated one with less power.
> 
>> Let's remember that the core team has limited resources to implement the 
>> things we propose, and if I have to choose between, say, serialization, 
>> reflection, asynchronous constructs, and rehashing visibility levels yet 
>> again, it's clear to me which one I would want dropped on the floor. I don't 
>> want perfect to be the enemy of good.
> Well, right now, there are several (at least one ;-) proposals that aim for a 
> breaking change of the whole model… nested extensions break nothing, so it 
> can be delayed for as long as the core team likes, without causing any 
> trouble.
Partials limited to the same scope can do the same with out having to give 
extension special nesting powers :)
> ___
> 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] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>>> On 10 Apr 2017, at 08:21, Jean-Daniel <mail...@xenonium.com> wrote:
>>> 
>>> 
>>> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution 
>>> <swift-evolution@swift.org> a écrit :
>>> 
>>> 
>>> 
>>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>>> 
>>>>> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> This struck me as a bit odd at first, but the more I think about it, the 
>>>>> more I really like the ability to nest extensions/scopes.  The one issue 
>>>>> I see is sticking that public extension inside a private one.  I think 
>>>>> you would have to mark ‘secret: Int’ as private instead of the extension 
>>>>> itself to allow the effect you are looking for...
>>>>> 
>>>>> What I ultimately want is the ability to declare storage in extensions in 
>>>>> the same submodule. Combining that with fileprivate will allow the same 
>>>>> tricks without the indentation (together in their own file).  This 
>>>>> nesting will help in the mean-time (and would still be useful after for 
>>>>> those who prefer to organize their code in fewer/longer files).  I think 
>>>>> it could be helpful in other ways too…
>>>> 
>>>> What do you think of `partial` types like C# but limited to a file?
>>>> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx
>>>> 
>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
>>>> 
>>> 
>>> That's the direction the new proposal (0169) is going towards with 
>>> extensions in the same file.
>> 
>> I don’t see how SE-0169 do that more than any other meaning private got 
>> until now. This was already the case with the initial meaning of private, 
>> and was the case with fileprivate.
> 
> The current semantics of private don’t give any support for partial types 
> like in C# because the accessibility is restricted to the current scope. With 
> SE-0169’s private, extensions in the same file as the type share that scope. 
> Plus, the Alternatives Considered section of the proposal discusses potential 
> future directions where those extensions could look even more like C# 
> partials :)

SE-169 could be emulated cleanly by introducing partial types within the same 
scope as a new feature completely separate from extensions. Partial types would 
not require redefining how private or extensions work now. It would also serve 
as a way to communicate to the user that the type is not done being defined so 
if they want to encapsulate the type completely, They have to make it non 
partial. 





> 
>> And for file splitting and visibility control, we need submodules. Until 
>> then, if this proposal is to define the ultimate meaning of private, I 
>> rather like this meaning that the SE-0025 one.
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> This struck me as a bit odd at first, but the more I think about it, the more 
> I really like the ability to nest extensions/scopes.  The one issue I see is 
> sticking that public extension inside a private one.  I think you would have 
> to mark ‘secret: Int’ as private instead of the extension itself to allow the 
> effect you are looking for...
> 
> What I ultimately want is the ability to declare storage in extensions in the 
> same submodule. Combining that with fileprivate will allow the same tricks 
> without the indentation (together in their own file).  This nesting will help 
> in the mean-time (and would still be useful after for those who prefer to 
> organize their code in fewer/longer files).  I think it could be helpful in 
> other ways too…

What do you think of `partial` types like C# but limited to a file?
https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx 


https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
 




> 
> Thanks,
> Jon
> 
>> On Apr 8, 2017, at 5:03 AM, Tino Heth via swift-evolution 
>> > wrote:
>> 
>> Imho there is a simple solution to reach the goals of SE-0169 without 
>> breaking compatibility:
>> Just allow extensions inside type declarations.
>> 
>> class MyVC: UIViewController {
>> private let numberOfSections = 0
>> 
>> extension: UITableViewDataSource {
>> // Skipping the class and assume we want to extend the surrounding 
>> type
>> func numberOfSections(in tableView: UITableView) -> Int {
>> return numberOfSections
>> }
>> 
>> func tableView(_ tableView: UITableView, numberOfRowsInSection 
>> section: Int) -> Int {
>> return 0
>> }
>> }
>> 
>> private extension {
>> // this would contain everything that shoudn't be visible for other 
>> extensios
>> 
>> var secret: Int = 0
>> 
>> public extension MyFriendClass {
>> // oh, well, I make an exception here for a trustworthy type
>> func checkSecret(of controller: MyVC) -> Bool {
>> return controller.secret > 0
>> }
>> }
>> 
>> private extension {
>> // this is so secret, I'm not even allowed to copy it
>> }
>> }
>> 
>> public func myMethod() {
>> print("This is just a boring method")
>> }
>> }
>> 
>> It has the downside of shifting code to the right (you could as well leave 
>> those extension-blocks unindented), but lots of advantages:
>> - No change for private needed
>> - It can be nested as much as you like to satisfy even the most absurd 
>> desires of encapsulation
>> - It reminds me on operator definitions inside type declarations 
>> - No change for fileprivate needed (but actually, I think there is very 
>> little need to keep fileprivate)
>> 
>> I wish this would only be a joke, but writing the example, I actually 
>> started liking the concept (but I have a terrible headache right now which 
>> might affect my mind) — so either this receives some feedback, or I might 
>> start re-proposing this ;-)
>> 
>> - Tino
>> ___
>> 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-0169: Improve Interaction Between private Declarations and Extensions

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution 
>  wrote:
> 
> I agreed with Charlie, but I think there’s another option. 
> 
> The access control problems that both SE-0159 and SE-0169 are attempting to 
> address can be resolved not by changing the definition of the existing access 
> modifiers, but refocussing the use of extensions. 
> 
> One such way would be to introduce a `partial` modifier. It would be similar 
> to C#’s partial modifier. The proposed partial modifier would be purely 
> additive and it would go a long way to mitigate the access control issues 
> inherent in extension-oriented design. 
> 
> The key characteristics of partial-oriented design would be:
> 
> - Partials would allow the splitting of implementations into multiple logical 
> units without the same-file restriction.

I really like the idea of partial but it would need to be restricted to the 
same file. This would allow partial to just be a compile time feature which 
just zips up a type together.  Another great feature would be that it could 
allow stored properties because it is only a compile time feature. Partial 
could be used to communicate to the user that this type has additional members 
and properties declared somewhere else in the file. 

+1 for file scope partial. 


> - Partial definitions of a type are restricted to same module. If you wish to 
> add functionality to a type external to its defining module, use an 
> extension. 
> - Partials would provide greater clarity between additive extension and the 
> original implementation. 
> - Within a partial, private would be type-private. 
> - Within an extension, private would be scoped-private (the status quo). 
> 
> I do see that the last two points may introduce some friction. Particularly 
> because: 
> 
> - Within a partial, fileprivate would be more restrictive than private. 
> - Within an extension, fileprivate would be less restrictive than private 
> (the status quo). 
> 
> However, I don’t see these as too challenging for educators or developers as 
> they are differentiated by their top-level scope. 
> 
> 
>> On 07/04/2017, 05:57, "Charlie Monroe via swift-evolution" 
>>  
>> wrote:
>> 
>> Simply as long as it's file-based, it's not a solution, it's just another 
>> attempt to satisfy some part of the community. I'm not saying that the 
>> current access levels are perfect, but I still believe the way to go is to 
>> either use submodules, and/or introducing the concept of "protected" members.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 6, 2017, at 4:10 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> What is your evaluation of the proposal?
-1 
I don't see how this "breaking" change is better than just reverting SE-025. 

SE-169 complicates private by making it even closer to fileprivate. It 
technically reverts most of the SE-025 functionality. 

If this proposal is desired then just out right revert SE-025. 


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

No. 

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

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

Participated in previous discussions. ___
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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 24, 2017, at 12:32 AM, Rien  wrote:
> 
> 
>>> On 23 Mar 2017, at 21:26, Jose Cheyo Jimenez  wrote:
>>> 
>>> 
>>> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 21 Mar 2017, at 08:05, Rien  wrote:
 
 +1
>>> 
>>> -1: I have revised my opinion.
>>> 
>>> 
 
>• What is your evaluation of the proposal?
 
 Makes the language easier to understand, lowers cognitive load during 
 coding.
 I also hope this will pave the way for a overhaul of the access level 
 system including modularization.
>>> 
>>> I still hope that fileprivate will be dumped one day. Presumably when a 
>>> better proposal is on the table.
>>> However it is clear that for some people the disadvantage of dropping it 
>>> now is bigger than the advantage to the proponents together.
>>> Regardless of wether the need is only perceived or not.
>>> 
 
>• Is the problem being addressed significant enough to warrant a 
> change to Swift?
 
 yes.
>>> 
>>> yes, but not without an alternative solution in place at the time 
>>> fileprivate is dropped.
>> 
>> Can you clarify what you mean here? 
> 
> Quite obviously the functionality of the current private feature is part of 
> the workflow of a considerable number of people.
> It does not really matter if this feature is necessary or not, they have it 
> integrated in their thinking and workflow.
> (Note: we don’t need "for element in collection" either, plain "1..N" for 
> loops would suffice)
> To me, that is enough reason to postpone this proposal until this 
> functionality can be retained while at the same time reverting private back 
> to its original meaning.

That is alternative 3. 

> Rien.
> 
>> 
>>> 
>>> 
 
>• Does this proposal fit well with the feel and direction of Swift?
 
 Yes
>>> 
>>> 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.
>>> 
>>> Same
>>> 
 
>• 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.
>>> 
>>> 
>>> Same.
>>> 
 
 
 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
>>> 

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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution 
>  wrote:
> 
> 
>> On 21 Mar 2017, at 08:05, Rien  wrote:
>> 
>> +1
> 
> -1: I have revised my opinion.
> 
> 
>> 
>>> • What is your evaluation of the proposal?
>> 
>> Makes the language easier to understand, lowers cognitive load during coding.
>> I also hope this will pave the way for a overhaul of the access level system 
>> including modularization.
> 
> I still hope that fileprivate will be dumped one day. Presumably when a 
> better proposal is on the table.
> However it is clear that for some people the disadvantage of dropping it now 
> is bigger than the advantage to the proponents together.
> Regardless of wether the need is only perceived or not.
> 
>> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> yes.
> 
> yes, but not without an alternative solution in place at the time fileprivate 
> is dropped.

Can you clarify what you mean here? 

> 
> 
>> 
>>> • Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes
> 
> 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.
> 
> Same
> 
>> 
>>> • 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.
> 
> 
> Same.
> 
>> 
>> 
>> 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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 2:33 PM, Matthew Johnson  wrote:
> 
>> 
>> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez > > wrote:
>> 
>> 
>>> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 21, 2017, at 1:41 PM, 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
 
> 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.
>>> 
>>> Removing scoped access is a no-go if we consider tightly encapsulating 
>>> invariant-preserving state to be an important feature.  The fact is that 
>>> both features can be used meaningfully.  The fact that some people choose 
>>> not to do this is not an argument against the features being available.  It 
>>> is an opportunity to encourage people to thing more carefully about why 
>>> they are encapsulating something.  
>> 
>> I understand the bigger picture you are getting at but the scope access you 
>> have envisioned should not be called private. 
> 
> I don’t disagree with this.  I’m fine with renaming it 

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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Mar 21, 2017, at 1:41 PM, 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
>> 
>>> 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.
> 
> Removing scoped access is a no-go if we consider tightly encapsulating 
> invariant-preserving state to be an important feature.  The fact is that both 
> features can be used meaningfully.  The fact that some people choose not to 
> do this is not an argument against the features being available.  It is an 
> opportunity to encourage people to thing more carefully about why they are 
> encapsulating something.  

I understand the bigger picture you are getting at but the scope access you 
have envisioned should not be called private. 

In order to get scope access to a place where it is more useful we have to 
remove it.

I don’t mind if scope access is kept but it must have a different name and that 
should be a different limited scope proposal. 

Opposing SE-0159 will make it much harder to redefine scope access.


> 
> A programmer has to make a conscious decision to give a declaration 
> visibility other than internal.  If they have trouble identifying whether 
> file or scoped access is appropriate this indicates they don’t really 
> 

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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> 
>> On Mar 21, 2017, at 8:26 AM, Slava Pestov > > wrote:
>> 
>>> 
>>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
>>> > wrote:
>>> 
>>> -1 on this as well for similar reasons. Places where I use fileprivate 
>>> (aside from what was automatically migrated by Xcode) can be counted on 
>>> fingers of one or two hands. 
>>> 
>>> I feel that this proposal is reverting something without offering an 
>>> alternative solution.
>> 
>> In what situations do you use Swift 3 private where fileprivate is not an 
>> acceptable replacement?
> 
> In my usage, I very rarely use fileprivate. To back this with numbers, a 
> recent project I developed (i.e. without Xcode's automatic migration of 
> private -> fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 uses 
> of "private”.

Do you have a way to tell how much of the private is effectible fileprivate? 
(top level private usage)



> 
> This is definitely a personal opinion, but I tend to limit access to members 
> as much as possible to discourage/prevent their usage out of the scope they 
> are intended for and to better design API that should be used out of the 
> scope (public/internal). I feel this is a good thing for newcomers to a 
> codebase (and myself coming back to a codebase after a year or two) as 
> Xcode's autocompletion won't offer members that are not supposed to be called 
> out of the scope (scope-private). 
> 
> As I've mentioned this during the discussion, I feel that current state of 
> things encourages huge files (1000+ lines of code) as you can't define 
> "protected" level access and migrate some of the code that implements e.g. 
> accessibility to a different file without potentially exposing internal 
> details to the rest of the module (if the extension in the other file needs 
> access to private details, which is often the case).
> 
> I feel that if there should be a change to the access levels, it should 
> address this as well. The current solution based on reverting the original 
> proposal only unnecessarily exposes implementational details to the rest of 
> the file - at least in my codebase.
> 
>> 
>> Slava
>> 
>>> 
 On Mar 21, 2017, at 3:33 AM, 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.
 
 
 -- 
 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 
>>> 
> ___
> 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

[Jose Cheyo Jimenez via swift-evolution]

> 
> What is your evaluation of the proposal?
+1
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. Making scope private be the soft default (private) created much confusion 
. The incredible overlap that this change created for fileprivate and private 
is actively harmful. Reverting this now will allow a more powerful scope access 
to be added much later in conjunction with a comprehensive module system. 

> 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?
Swift 1 and 2. 
Simple. 
Easy to understand.
Worked great with extensions. 

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Participated extensibly on the conversations leading to the proposal. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 9, 2017, at 10:43 AM, Ricardo Parada <rpar...@mac.com> wrote:
> 
> In other languages I normally have a method with a variable number of 
> arguments and another one taking an array. Then one typically ends up calling 
> the other. 
> 
> If we had implicit splatting I imagine it would reduce such methods to only 
> one. 
> 
> However if implicit splatting were to cause problems I think it would be nice 
> to do it explicitly as follows:
> 
> foo(args as Argument…)

That would depend on Joe Groff’s proposal “Replacing `as` for bridging coercion"
[swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from 
`as`/`is`/`as?` casts



> 
> 
> On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> 
>>> wrote:
>>> 
>>>> These is very unfortunate as a solution for “spreading” a collection or 
>>>> tuple so that It can be applied to function taking a variadic.
>>>> It makes sense on the declaration site but not on the call site. 
>>>> 
>>>> someFunc(@nonVariadic [1])  
>>>> someFunc(@variadic [1]) 
>>>> 
>>>> There is nothing special about variadic/ spreading that would warrant an 
>>>> attribute. 
>>>> 
>>>> I think using attributes is not different than using a keyword like c# 
>>>> uses. 
>>>> http://stackoverflow.com/questions/7580277/why-use-the-params-keyword 
>>>> <http://stackoverflow.com/questions/7580277/why-use-the-params-keyword>
>>>> 
>>>> Do we really want to tag every array/tuple with a @variadic or 
>>>> @nonVariadic tag when packing and unpacking parameters?
>>>> 
>>>> variadic/ spreading (AKA packing / unpacking ) is a well known concept to 
>>>> most languages. 
>>> 
>>> I have the impression there is a misunderstanding about the proposal:
>>> It would not only make the variadics-syntax superflous, but also the whole 
>>> splatting-magic.
>>> There would only be functions that accept arrays, and you could freely 
>>> choose to feed them a comma-seperated list instead.
>>> The attribute would be written in the function declaration only — and we 
>>> could even decide that it isn't needed at all, and simply accept lists 
>>> wherever an array is expected.
>> 
>> Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we 
>> would reintroduce it for Array like constructs. 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered>
>> 
>> I am in favor in explicit splat behavior but I don’t see it happening 
>> anytime soon. Its tagged as low priority.  
>> 
>>  
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>

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

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de> wrote:
> 
>> These is very unfortunate as a solution for “spreading” a collection or 
>> tuple so that It can be applied to function taking a variadic.
>> It makes sense on the declaration site but not on the call site. 
>> 
>> someFunc(@nonVariadic [1])  
>> someFunc(@variadic [1]) 
>> 
>> There is nothing special about variadic/ spreading that would warrant an 
>> attribute. 
>> 
>> I think using attributes is not different than using a keyword like c# uses. 
>> http://stackoverflow.com/questions/7580277/why-use-the-params-keyword 
>> 
>> 
>> Do we really want to tag every array/tuple with a @variadic or @nonVariadic 
>> tag when packing and unpacking parameters?
>> 
>> variadic/ spreading (AKA packing / unpacking ) is a well known concept to 
>> most languages. 
> 
> I have the impression there is a misunderstanding about the proposal:
> It would not only make the variadics-syntax superflous, but also the whole 
> splatting-magic.
> There would only be functions that accept arrays, and you could freely choose 
> to feed them a comma-seperated list instead.
> The attribute would be written in the function declaration only — and we 
> could even decide that it isn't needed at all, and simply accept lists 
> wherever an array is expected.

Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we 
would reintroduce it for Array like constructs. 
https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered
 


I am in favor in explicit splat behavior but I don’t see it happening anytime 
soon. Its tagged as low priority.  

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

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> I suggest to take a look at the topics "Variadics as an Attribute" and "array 
> splatting for variadic parameters" and 
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md.
> 
> This is basically the other way round (arrays would accept variadic 
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with 
> types besides array (set, iterator….)
I agree with getting rid of the Type... because we could use ... in slicing 
(see String manifesto). Why must it be an attribute and not just "*" ? The 
advantage I see is that this will play great in also deconstructing collection 
like things like Array, Slice and Tuple. This is already familiar to python and 
ruby users. 

> ___
> 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] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution 
>  wrote:
> 
> In swift, a variadic argument can become an array without too much effort.
> 
> func foo(_ va: String...) {
>let a: [String] = va
> }
> 
> However, it seems odd to me that an array can not be converted into a 
> variadic argument
> 
> foo(["a", "b", "c"]) // <-error
> foo("a", "b", "c") // no error
> 
> Other people have wondered about this too. 
> 
> 
> According to this thread  
> Doug Gregor says it is due to some type ambiguity. with Generics.
> 
> If type ambiguity is the issue, Do we have the option to cast it to the 
> correct type?
> 
> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String... to 
> be a type.

I think this needs to be done with a spread operator in order to disambiguate. 

foo(...["a", "b", "c”] 

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator
 


I like the idea. Its syntactic sugar so I am not sure how open the core team 
would be to adding it. 

> 
> What does the community think? Should we be granted some mechanism to turn an 
> array into a variadic argument?
> ___
> 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

[Jose Cheyo Jimenez via swift-evolution]

Sorry to beat this like a drum :

How is swift 3 extensibility harmful exactly? 

Do you have specific examples when extensibility was harmful in a project? 

This probably deserves its own thread if the examples are substantial. 




> On Feb 21, 2017, at 1:27 AM, Joanna Carter via swift-evolution 
>  wrote:
> 
> 
>>> Le 21 févr. 2017 à 05:21, David Waite  a 
>>> écrit :
>>> 
>>> The only other option that might be useful is something like 'internal 
>>> extensible' to limit visibility for extensible members to the current 
>>> module.
>> If a type is extensible by other modules at all, I prefer that to be spelled 
>> “public”.
> 
> Indeed, I could agree with that but…
> 
> Before 'open' was added to indicate extensibility of a publicly visible 
> class, we used to have 'public' to indicate that the class was visible 
> anywhere and 'final' to restrict inheritance/overriding.
> 
> With classes, 'final' was good enough to indicate that a type and/or its 
> members should not be extensible.
> 
> 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.
> 
>> 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?
> 
>> I believe the critical piece of designing access levels is for the levels to 
>> document the intent of the developer specifying the access level. Does 
>> “extensible” indicate that the designer of the library wanted a certain kind 
>> of access - or that the compiler maybe gave an error at some point when it 
>> was “private”?
> 
> This is somewhere where I have to bring up my learning and experience with 
> other languages. Albeit only with classes, private always meant what it said 
> on the tin - from outside of a class, it doesn't exist, don't touch!
> 
> Which is why I am very wary of reverting file scope to private.
> 
> 'fileprivate' is a keyword that allows, not extensibility but visibility.
> 
> Extensibility control for non-class types is more akin to using or not using 
> 'final' to control inheritance/overriding with classes.
> 
> Maybe, instead of looking at extending visibility by adding yet another 
> visibility specifier (extensible), we should be looking at adding a specifier 
> that limits extensibility for any type?
> 
> This would be additive and would have the advantage of not breaking so much 
> code.
> 
> OK, how does this sound?
> 
> Extend the 'final' concept, currently used only in classes, to protect any, 
> non-protocol, type from being extended.
> 
> That way, folks who are not so "purist" about access control can continue as 
> before, leaving those of us who want that control to be able to exercise it.
> 
> So, for example :
> 
> final struct DontExtendMe
> {
>  …
> }
> 
> extension DontExtendMe // error : final type cannot be extended
> {
>  …
> }
> 
> I am not suggesting that 'final' should be applicable to members of non-class 
> types. Members of class types should continue to be markable as 'final' for 
> inheritance control reasons.
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> 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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 19, 2017, at 7:29 PM, David Waite <da...@alkaline-solutions.com> wrote:
> 
> Swift 2’s access modifiers had a very simple ‘elevator pitch’ - 
> “If you are writing code, by default everything within the module (app or 
> library) your are working in can see it, but other modules cannot. If you 
> want other modules to see features of your module, you make them public. If 
> something is an implementation detail that even other parts of your module 
> shouldn’t mess with, you make them private”
> 
> I think I would have trouble *just* describing private vs file private in 
> that amount of space. One sign of the complexity was that even after a 
> ridiculous amount of bike shedding, we couldn’t come up with better way to 
> distinguish the two than to call one “fileprivate”. So I would say for the 
> purposes of swift as a language suitable for learning, the change was 
> harmful. 

Swift’s scope private is not different than other languages. 

> 
> Secondly, there are reasons to choose one versus the other, but the 
> combination of the meaning of the keyword changing between swift 2 and 3 and 
> the spelling of “fileprivate” means that the choice of one or the other 
> doesn’t really communicate anything to a developer of a typical project - it 
> appears to often be a matter of the legacy of the code as well as developer 
> taste. That the choice between private and file private doesn’t illustrate 
> intent is harmful to coordination.

This really depends on where private is. If it on the top scope then private is 
the same as file-private and your statement is correct. 

SE-0025 was changed to allow higher access modifier for inner types and this is 
when things started to get confusing because the vast majority of times when 
scope private was being used in reality is the same as fileprivate. The fact 
that we encourage the use of scope private over file-private is harmful because 
of the confusion. 


// File.swift

private let myString = ""   // fileprivate same as private
fileprivate let myString2 = ""  // fileprivate same as private


private struct MyType {  // fileprivate same as private
fileprivate struct MyInnerType{  // private never the same as private
fileprivate struct MyInnerType{} // private never the same as private
}
}

// end of File.swift



 
> 
> 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.
> 
> -DW
> 
>> On Feb 18, 2017, at 11:57 PM, Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> How exactly is the use of scope private harmful? 
>> 
>> Do you have specific examples when scope private was harmful?
>> 
>> 
>> 
>>> On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution 
>>> wrote:
>>>> I don’t think there is evidence that scope private in Swift3 is "actively 
>>>> harmful”. 
>>>> 
>>> 
>>> This thread would quite simply not exist if not to present exactly that 
>>> evidence. It exists; we, the change's detractors, exist.
>>> 
>>> Zachary
>>> 
>>> __

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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 19, 2017, at 7:16 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> The current private is closer to other languages than the previous one we 
>>> had which now has in fileprivate a better name.
>> 
>> It is closer, but it's not a goal for Swift to always follow conventions of 
>> other languages. It's useful sometimes. But in this case it goes directly 
>> against the philosophy of Swift's extension feature. Swift should be allowed 
>> to go against the norm when it serves the languages. And in this case, if 
>> only one private should exist, it's the file-s open one.
> 
> Yes, I think making private not work well with extensions was the "actively 
> harmful" aspect of SE-0025.  Scoped access itself is not actively harmful and 
> should not be removed, but it could be renamed so that private works the way 
> people want it to again.
> 
I think this an excellent point. In your proposal you can also mention that 
perhaps the renaming on private to mean scope private was premature since the 
primary goal was to match other languages notion on private. The issue is that 
Swift's public does not match other languages public. Should we then also 
change Swift's public to mean the established meaning of public in other 
languages? By no means! Swift is different. We agree that scope private is 
useful to some people by we believe that it is the wrong default for Swift. It 
is actively harmful in that by making it the default it forces a programmer to 
think fileprivate the moment the want to extend a type and access their private 
members. This in turn forces every programmer to have to deal with two access 
modifiers before they even make anything public. We believe this goes against 
the swift  centric feature of extensibility via extensions and the philosophy 
of "the complexity inherited in the language needs to be progressively 
disclosed". In the same way that public doesn't make classes open, private 
should not be scope private. 

This will make it possible for people to lock down in steps instead of all 
together which doesn't work with extensions.  

We need more examples to make this case. 



>> ___
>> 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] final + lazy + fileprivate modifiers

[Jose Cheyo Jimenez via swift-evolution]

How exactly is the use of scope private harmful? 

Do you have specific examples when scope private was harmful?



> On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution 
> wrote:
>> I don’t think there is evidence that scope private in Swift3 is "actively 
>> harmful”. 
>> 
> 
> This thread would quite simply not exist if not to present exactly that 
> evidence. It exists; we, the change's detractors, exist.
> 
> Zachary
> 
> ___
> 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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 17, 2017, at 6:10 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez  > wrote:
> 
>> 
>> From Ted.
>>> Relative to Swift 3, the bar for such changes is significantly higher:
>>> 
>>> The existing syntax/API being changed must be actively harmful.
>>> The new syntax/API must clearly be better and not conflict with existing 
>>> Swift syntax.
>>> There must be a reasonably automatable migration path for existing code.
>> 
>> 
>> I don’t think there is evidence that scope private in Swift3 is "actively 
>> harmful”. 
>> Reverting to Swift2 file-private as private is not clearly better. 
>> The community has not converged on a clear winner. 
>> 
>> The only positive thing here is that if we get rid of scope private then it 
>> will be easy to make private alias to file-private so no code will break, 
>> but we would be removing a feature so I would think this is a breaking 
>> change. 
>> 
>> Would removing private and fileprivate by making them alias to internal also 
>> be a breaking change? Even if the code will still compile?
> 
> Thanks for posting this Jose.  I think the point that has near unanimous 
> agreement is that assigning `private` the meaning of scoped access was a 
> mistake.  `fileprivate` is too awkward given how frequently it is necessary 
> in common idioms of Swift code organization.  
> 
> Whether scoped access itself is a valuable feature and whether it should 
> remain is the question that is turning out to be very controversial.  The 
> mistake we made with the keywords in Swift 3 certainly didn't help make the 
> case for it.  
> 
> That's why I would like to see us try to fix that mistake.  I think everyone 
> can be reasonably happy if we can all use `private` the way we did in Swift 2 
> and `scoped` can become a style issue.  Some teams can have a linter reject 
> it and those of us who like it can continue using it.  As a bonus, we would 
> eliminate an awkward keyword.

I appreciate the enthusiasm about this but the same argument can be used the 
other way. 

What about renaming `fileprivate` to `privy`. Shorter than private, typing 
`pri` would auto complete to it,  more swifty. Win Win. :) 

Its going to be hard finding names for either scope private or file private 
that the community will agree with. 

Its going to be a hard sale given the other more important features being 
worked on.

> 
>> 
>> This is a linter problem. If people don’t want other people in their team to 
>> use scope private then make it part of the coding style. 
>> 
>> If people do not want fileprivate because it looks ugly, then force 
>> everybody to use scope private using a linter like swiftlint. 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
 > wrote:
 
> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
> > wrote:
> 
> Personally I feel enforced encapsulation of implementation detail to the 
> latter group is less important than the former, and can be handled by 
> convention. Whereas other users of your module definitely benefit from 
> access control and being able to consume a clearly-defined interface.
 
 I think failing to provide some sort of below-`internal` privacy would be 
 missing *really* low-hanging fruit for no good reason. The languages I can 
 think of which don't include some sort of sub-library-wide privacy 
 level—Objective-C, Javascript, Perl, Python—usually have very simple 
 object designs with a flat namespace. (Well, there's Rust, but Rust lets 
 you wrap anything you'd like in a module.) Even Objective-C in practice 
 includes a `fileprivate` equivalent in the form of methods declared only 
 in the .m file.
 
 I also think it's often helpful to be able to change a member's access 
 level without having to change all references to it. Publishing or 
 privatizing an interface is not an uncommon refactoring.
 
 Not everybody likes our current semantics, but that's no reason to throw 
 the feature out entirely.
>>> 
>>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
>>> we can reconsider using `scoped` as the keyword for scoped access rather 
>>> than abandoning it.  Does anyone remember why this was considered a bad 
>>> idea?
>>> 
 
 -- 
 Brent Royal-Gordon
 Architechies
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 

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

[Jose Cheyo Jimenez via swift-evolution]

From Ted.
> Relative to Swift 3, the bar for such changes is significantly higher:
> 
> The existing syntax/API being changed must be actively harmful.
> The new syntax/API must clearly be better and not conflict with existing 
> Swift syntax.
> There must be a reasonably automatable migration path for existing code.


I don’t think there is evidence that scope private in Swift3 is "actively 
harmful”. 
Reverting to Swift2 file-private as private is not clearly better. 
The community has not converged on a clear winner. 

The only positive thing here is that if we get rid of scope private then it 
will be easy to make private alias to file-private so no code will break, but 
we would be removing a feature so I would think this is a breaking change. 

Would removing private and fileprivate by making them alias to internal also be 
a breaking change? Even if the code will still compile?

This is a linter problem. If people don’t want other people in their team to 
use scope private then make it part of the coding style. 

If people do not want fileprivate because it looks ugly, then force everybody 
to use scope private using a linter like swiftlint. 



















> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Personally I feel enforced encapsulation of implementation detail to the 
>>> latter group is less important than the former, and can be handled by 
>>> convention. Whereas other users of your module definitely benefit from 
>>> access control and being able to consume a clearly-defined interface.
>> 
>> I think failing to provide some sort of below-`internal` privacy would be 
>> missing *really* low-hanging fruit for no good reason. The languages I can 
>> think of which don't include some sort of sub-library-wide privacy 
>> level—Objective-C, Javascript, Perl, Python—usually have very simple object 
>> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
>> anything you'd like in a module.) Even Objective-C in practice includes a 
>> `fileprivate` equivalent in the form of methods declared only in the .m file.
>> 
>> I also think it's often helpful to be able to change a member's access level 
>> without having to change all references to it. Publishing or privatizing an 
>> interface is not an uncommon refactoring.
>> 
>> Not everybody likes our current semantics, but that's no reason to throw the 
>> feature out entirely.
> 
> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
> we can reconsider using `scoped` as the keyword for scoped access rather than 
> abandoning it.  Does anyone remember why this was considered a bad idea?
> 
>> 
>> -- 
>> 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

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

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Jose Cheyo Jimenez via swift-evolution]

Hi Ted, 

Today I learned about https://esdiscuss.org/  which is 
like an archiver viewer for disc...@mozilla.org pipermail mailing list 

All their code is at  https://github.com/esdiscuss 


This still preserves pipermail as the one source of truth but it allows better 
searching and visibility.

There is even a reply button which opens up a mail client presumably the 
correct headers. 

Thanks!


> On Feb 9, 2017, at 5:18 PM, Ted Kremenek via swift-users 
>  wrote:
> 
>> 
>> On Feb 9, 2017, at 4:09 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Feb 9, 2017, at 6:04 PM, Ted Kremenek >> > wrote:
>>> 
>>> 
 On Feb 9, 2017, at 3:52 PM, Ted Kremenek via swift-users 
 > wrote:
 
> I’ve been mostly silent in this conversation largely because I didn’t 
> realize it was leading up to a formal decision.  I wish it would have 
> followed the proposal process so it was clear to everyone that a decision 
> was being considered and this was our chance to offer input.  
 
 FWIW, I am not ignoring this thread.  At some point there was diminishing 
 signal on the thread, and it felt like the category of opinions that had 
 been voiced had been vocalized on the thread.  Looping in swift-users into 
 that thread would have been a good thing to do in hindsight so more people 
 felt like they had a chance to participate.  Based on what I am seeing in 
 reaction to this decision, however, I’m not seeing much new signal.
>>> 
>>> Just to add to this point — new insights on this topic are welcome, and 
>>> will be paid attention to.  The decision to change to a forum is because 
>>> that was evaluated as being the best thing for the community, based on the 
>>> range of opinions provided and the tradeoffs made.  If there is something 
>>> important that was missed, obviously that is not going to be ignored.  We 
>>> want to do the right thing.  So far I still feel that moving to a forum 
>>> software is the right choice, but I’d like to do that in a way that allows 
>>> people to still participate effectively via email.
>> 
>> Is there any way to have a trial run so we can evaluate the email experience 
>> of using the forum software before we make the final switch?  I agree that 
>> this sounds like the right direction, but it’s hard to know what the email 
>> experience will really be like until we give it a try for a week or so.
> 
> I need to formalize a plan, but yes I’d like to trial this somehow.  Nate 
> Cook created a staged installation of Discourse when the thread on 
> swift-evolution was happening and there was some useful telemetry out of that 
> experiment (such as how rich text email interacted with doing inline 
> replies).  Moving to Discourse (or some alternate forum software if we decide 
> Discourse is not a fit) would be a staged thing.  The main question to me is 
> how do we do a meaningful trial without actually doing the real discussions 
> in the forum (while the mailing lists are still running).
> ___
> swift-users mailing list
> swift-us...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

https://developer.apple.com/swift/blog/?id=11



> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> How about removing fileprivate, getting Swift 2 meaning of private (as most 
> people here now suggest) and add additional @protected annotation for those 
> who want a more fine-grained solution:
> 
> @protected private - members accessable only from the class/struct/enum/... 
> and their extensions within the file
> 
> @protected internal - again, but you can access it even from extensions and 
> subclasses outside of the file within the entire module.
> 
> @protected public/open - the same as above, but outside the modules.
> 
> To me, this way most people here will be happy:
> 
> - those wishing the access control gets simplified - it in fact does, you 
> don't need to use @protected, if you don't want to/need to.
> - those who need a fine-grained solution, here it is.
> 
> 
> 
>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
 On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
  wrote:
 
 
 On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
  wrote:
 
 While we’re bikeshedding, I’m going to add my two cents. Hold on to your 
 hat because this might be controversial here.
 
 I think both ‘private’ and ‘fileprivate’ are unnecessary complications 
 that only serve to clutter the language.
 
 It would make a lot more sense to just have internal and public only. No 
 private, no fileprivate, no lineprivate, no protected. It’s all silly.
>>> 
>>> Eh, I've used `private` to keep myself honest in terms of going through 
>>> some book-keeping functions instead of directly accessing a property.
>> 
>> This is exactly the kind of thing I like it for and why I hope we might be 
>> able to keep scoped access even if it gets a new name that ends up as 
>> awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
>> 
>>> 
>>> - Dave Sweeris
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution 
>  wrote:
> 
> I do like approach #2. It would play well with extensions, look very familiar 
> to how private works in other main stream languages and it wouldn’t get in 
> the way of a possible future refinement of extensions to this model:
> 
> a) 1st party extension (extension defined and owned by the type owner): 
> extension is defined in the same module as the base type:
> 
> - allows access to private type properties and functions even if the base 
> type and extension are in different files
 This is not part of #2, only extensions to that type that are in the current 
file have access to private. 



> - allows the definition of stored properties for value and class types.
> 
> b) 3rd party extension (extension is defined and owned by the _user_ of a 
> type): extension is defined in a parent module and the base type is defined 
> in a sub-module:
> 
> - forbids access to private properties and functions from the imported type
> - forbids the definition of stored properties for value types
> - MAY allow the definition of stored properties on class types (haven’t 
> really convinced myself that this would be a good idea)
> 
> “parent module” would either mean the application that links against a module 
> (what is supported today) but also the parent module of a sub-module 
> (potential future addition).
> 
> 
> Regards,
> 
> Dietmar Planitzer
> 
> 
>> On Feb 14, 2017, at 21:31, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 14, 2017, at 3:20 AM, David Hart  wrote:
>>> 
>>> 
>>> On 14 Feb 2017, at 09:25, Goffredo Marocchi  wrote:
>>> 
 I disagree with that as well as I still think we are damaging the language 
 each time we take a known concept (like access levels) and give new 
 meanings to the same keywords. I still look baffled at the redefinition of 
 do and the addition of repeat for example...
 
 Private, the way it was before, was an admittedly curious take on how most 
 languages mean by private and we have jumped through a lot of hoops to 
 justify why we did not start with Java/C++/C# like access control and 
 augmented it instead of redefining things, omitting others, and then 
 constantly pulling the language left and right with not a lot of permanent 
 consensus either way as this discussion and others before show.
>>> 
>>> It's a curious take, but it is a curious take is perfectly coherent with 
>>> Swift extensions. How else would you access private implementation details 
>>> from an extension? But putting it in the same file, instead of having to 
>>> resort to an internal access level.
>> 
>> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
>> intentionally designed to remain familiar (and thus reuses many keywords 
>> across the language family), it often does so with slightly different 
>> meaning / behavior.  Consider ‘throw’ for example.
>> 
>> Keeping with the spirit of Swift and staying consistent with its design, I 
>> see two plausible meanings for private:
>> 
>> Private could mean either:
>> 1) private to the file (Swift 2 semantics)
>> 2) accessible only to the current type/scope and to extensions to that type 
>> that are in the current file.
>> 
>> I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote:
>> 
>> 
>> On 14 Feb 2017, at 09:25, Goffredo Marocchi > > wrote:
>> 
>>> I disagree with that as well as I still think we are damaging the language 
>>> each time we take a known concept (like access levels) and give new 
>>> meanings to the same keywords. I still look baffled at the redefinition of 
>>> do and the addition of repeat for example...
>>> 
>>> Private, the way it was before, was an admittedly curious take on how most 
>>> languages mean by private and we have jumped through a lot of hoops to 
>>> justify why we did not start with Java/C++/C# like access control and 
>>> augmented it instead of redefining things, omitting others, and then 
>>> constantly pulling the language left and right with not a lot of permanent 
>>> consensus either way as this discussion and others before show.
>> 
>> It's a curious take, but it is a curious take is perfectly coherent with 
>> Swift extensions. How else would you access private implementation details 
>> from an extension? But putting it in the same file, instead of having to 
>> resort to an internal access level.
> 
> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
> intentionally designed to remain familiar (and thus reuses many keywords 
> across the language family), it often does so with slightly different meaning 
> / behavior.  Consider ‘throw’ for example.
> 
> Keeping with the spirit of Swift and staying consistent with its design, I 
> see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that type 
> that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.

+1 for #2

I think #2 strikes a really good balance and addresses all the uses of 
file-private for me personally. I don’t think the argument of trying to prevent 
people from accessing private members or methods in an extension stands 
specially when those extension live in the same file. If I really want 
something to be private then I can declare that inside an extension in which 
case other extension could not reach it. 


// File.swift
struct MyType {
private func myMethod(){}
}

extension MyType {
private func myMethodCantBeSeen(){}
func myExtenMethod1(){
myMethod() // Okay #2, in Swift 3 this method needs to be fileprivate
}
}

extension MyType {
func myExtenMethod2(){
myMethodCantBeSeen()// inaccessible due to private protection level
}
}
// end of File.swift



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

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

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

[Jose Cheyo Jimenez via swift-evolution]

> On Jan 24, 2017, at 8:31 AM, Daniel Dunbar  wrote:
> 
>> 
>> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez > > wrote:
>> 
>> Hi Daniel, 
>> 
>> I think this is an excellent idea! This would also solve the “local only” 
>> packages problem. 
>> http://stackoverflow.com/questions/40775726/can-i-make-a-local-module-with-the-swift-package-manager
>>  
>> 
>> 
>> By treating the git repo still as a single package, we can then just allow 
>> local dependencies that live somewhere in the repo. 
>> 
>> let package = Package(
>> name: “myMainPackage",
>> dependencies: [
>>  .Package(url: “./allMyLocalPackages/packageOne/“), // don’t 
>> have to specify version because it is inherited from main package. 
>>  .Package(url: “./allMyLocalPackages/packageTwo/“),
>>  .Package(url: “./allMyLocalPackages/packageThree/“),
>>   ]
>> )
>> 
>> 
>> I think this would lower the scope of the proposal and it would address the 
>> issue of being able to split up a mono repo. 
>> 
>> Should I propose this as an alternative or collaborate on the draft that you 
>> have?
> 
> I'm not exactly sure what change you are proposing, can you elaborate? What 
> is "allMyLocalPackages" in your email?
> 
>  - Daniel

That is just a directory that it is not named sources. 

After reading the road map. I think what I am referring to here is something 
along the line of 
– Overriding Package Conventions
– Support for Top-of-Tree

But not quite Multi-package repository because I just want to be to able to 
have multiple packages in one repo but not necessary have them exposed as 
individual sub packages. 

This is the same use case as the above stackoverflow multiple local packages 
question. 

> 
>> I have a very specific example where I want to be able to split up a repo so 
>> I can test them together on CI. 
>> https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21
>>  
>> 
>> 
>> 
>> Thank you. 
>> 
>> 
>>> On Nov 12, 2016, at 9:54 PM, Daniel Dunbar via swift-evolution 
>>> > wrote:
>>> 
 
 On Nov 12, 2016, at 9:43 PM, Russ Bishop > wrote:
 
 
> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev 
> > wrote:
> 
> Hi all,
> 
> I'm reposting a request for feedback on my proposal for extending SwiftPM 
> to support multiple packages inside one repository (i.e. "monorepo" 
> support, although it is a misnomer in this use case).
> https://github.com/ddunbar/swift-evolution/blob/multi-package-repos/proposals/-swiftpm-multi-package-repos.md
>  
> 
> 
> I would like to move this proposal forward so we can start on an 
> implementation, even if we need to refine it over time, but I was hoping 
> to get at least some concrete feedback first.
> 
> Thanks,
> - Daniel
 
 
 It seems like you’re going through contortions to deal with arbitrary 
 directory layouts and some odd consequences fall out of that decision. Not 
 being able to deterministically detect non-unique sub-packages is one. 
 
 Why not just require a top-level Package.swift that explicitly specifies 
 the sub-packages? The name for the sub-package should be in the main 
 package manifest. You’d gain the ability to import all the sub-packages in 
 one go; importing the root package without any sub-packages specified 
 automatically imports all sub-packages. This also allows library authors 
 to organize a library into sub-packages later without breakage. Come up 
 with a convention, e.g. a sub-package is in “/subpackageName” but allow 
 overriding that default. That allows reorganization if needed but the 
 convention should work for most libraries.
>>> 
>>> Mostly because I am concerned this doesn't scale well to *very* large 
>>> repositories, in which commits to that file would be "contentious" (in the 
>>> lock contention sense, not subject to debate sense). Of course, this 
>>> argument is a little bogus as the current proposal doesn't scale that great 
>>> either since we have to discover the packages (although I believe we can 
>>> probably do a good job of caching this information).
>>> 
>>> It certainly would simplify the implementation & proposal to have this.
>>> 
>>> The other reason is it is yet another thing for 

Re: [swift-evolution] Strings in Swift 4

[Jose Cheyo Jimenez via swift-evolution]

Hi Ben,

I just have one concern about the slice of a string being called Substring. Why 
not StringSlice? The word substring can mean so many things, specially in 
cocoa. 

Thank you. Great manifesto. 

> On Jan 19, 2017, at 8:18 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jan 19, 2017, at 19:38, David Sweeris  wrote:
>> 
>> Regarding substrings... Instead of having separate `ArraySlice` and 
>> `Substring` types, what about having just one type, `Slice`, 
>> for anything which shares memory? Seems like it'd be easier for users who'd 
>> only have to worry about shared storage for one type, and for stdlib authors 
>> who'd only have to write it once.
> 
> Collections already do get a default SubSequence implementation of 
> Slice that is essentially like just that. 
> 
> The reason types like Array and String have their own is to customize it with 
> more than the default behavior. For example, ArraySlice provides 
> .withUnsafeBufferPointer  method just like an Array does. Substring would 
> need all the features String provides.
> 
> Now, once we get conditional conformance, we could use that to maybe increase 
> sharing, for example we could create a protocol for types backed by 
> contiguous memory that provided withUnsafeEtc, and then use conditional 
> conformance to add those features to Slice when the Base has them. This 
> probably won't improve user experience particularly though, just help library 
> authors organize/minimize the 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

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

[Jose Cheyo Jimenez via swift-evolution]

Hi Daniel, 

I think this is an excellent idea! This would also solve the “local only” 
packages problem. 
http://stackoverflow.com/questions/40775726/can-i-make-a-local-module-with-the-swift-package-manager
 


By treating the git repo still as a single package, we can then just allow 
local dependencies that live somewhere in the repo. 

let package = Package(
name: “myMainPackage",
dependencies: [
.Package(url: “./allMyLocalPackages/packageOne/“), // don’t 
have to specify version because it is inherited from main package. 
.Package(url: “./allMyLocalPackages/packageTwo/“),
.Package(url: “./allMyLocalPackages/packageThree/“),
 ]
)


I think this would lower the scope of the proposal and it would address the 
issue of being able to split up a mono repo. 

Should I propose this as an alternative or collaborate on the draft that you 
have?

I have a very specific example where I want to be able to split up a repo so I 
can test them together on CI. 
https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21
 



Thank you. 


> On Nov 12, 2016, at 9:54 PM, Daniel Dunbar via swift-evolution 
>  wrote:
> 
>> 
>> On Nov 12, 2016, at 9:43 PM, Russ Bishop > > wrote:
>> 
>> 
>>> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> I'm reposting a request for feedback on my proposal for extending SwiftPM 
>>> to support multiple packages inside one repository (i.e. "monorepo" 
>>> support, although it is a misnomer in this use case).
>>> https://github.com/ddunbar/swift-evolution/blob/multi-package-repos/proposals/-swiftpm-multi-package-repos.md
>>> 
>>> I would like to move this proposal forward so we can start on an 
>>> implementation, even if we need to refine it over time, but I was hoping to 
>>> get at least some concrete feedback first.
>>> 
>>> Thanks,
>>> - Daniel
>> 
>> 
>> It seems like you’re going through contortions to deal with arbitrary 
>> directory layouts and some odd consequences fall out of that decision. Not 
>> being able to deterministically detect non-unique sub-packages is one. 
>> 
>> Why not just require a top-level Package.swift that explicitly specifies the 
>> sub-packages? The name for the sub-package should be in the main package 
>> manifest. You’d gain the ability to import all the sub-packages in one go; 
>> importing the root package without any sub-packages specified automatically 
>> imports all sub-packages. This also allows library authors to organize a 
>> library into sub-packages later without breakage. Come up with a convention, 
>> e.g. a sub-package is in “/subpackageName” but allow overriding that 
>> default. That allows reorganization if needed but the convention should work 
>> for most libraries.
> 
> Mostly because I am concerned this doesn't scale well to *very* large 
> repositories, in which commits to that file would be "contentious" (in the 
> lock contention sense, not subject to debate sense). Of course, this argument 
> is a little bogus as the current proposal doesn't scale that great either 
> since we have to discover the packages (although I believe we can probably do 
> a good job of caching this information).
> 
> It certainly would simplify the implementation & proposal to have this.
> 
> The other reason is it is yet another thing for people to maintain (and 
> remember the syntax for). Most repos are small enough that I think the 
> current proposal would perform fine and have a tendency to do what people 
> might naively expect (even if they didn't really think about why). On the 
> other hand, this file is likely to be quite static, so I'm not sure that is a 
> very important issue.
> 
> I was already on the fence on this, but I hadn't considered the benefits you 
> mention of allowing import of the package w/ no sub package specifier to mean 
> import of all sub-packages. That tips me a little more towards thinking maybe 
> a better proposal is to KISS and require this in some root file (whether or 
> not that root file is itself a package manifest or a different kind of file 
> is another question, you assume it would be the regular package manifest but 
> I don't think it *need* be, and there is some value in not having any nesting 
> relationship amongst packages).
> 
> - Daniel
> 
>> A top-level Package.swift would also allow immediate detection of non-unique 
>> sub-packages, etc. Also if you are using things like git submodules, 
>> subtree, or some other mechanism that ends up putting package files in your 
>> source tree you 

Re: [swift-evolution] Throws? and throws!

[Jose Cheyo Jimenez via swift-evolution]

> On Jan 12, 2017, at 5:34 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull >> > wrote:
>>> 
>>> Also, ‘try’ is still required to explicitly mark a potential error 
>>> propagation point, which is what it was designed to do.  You don’t have 
>>> ‘try’ with the variants because it is by default no longer a propagation 
>>> point (unless you make it one explicitly with ’try’).
>> 
>> If this is quite safe and more convenient, why then shouldn't it be the 
>> behavior for `throws`? (That is, why not just allow people to call throwing 
>> functions without `try` and crash if the error isn't caught? It'd be a 
>> purely additive proposal that's backwards compatible for all currently 
>> compiling code.)
> 
> Swift prefers that potential runtime crash points be visible in the code. You 
> can ignore a thrown error and crash instead, but the code will say `try!`. 
> You can force-unwrap an Optional and crash if it is nil, but the code will 
> say `!`. 
> 
> Allowing `try` to be omitted would obscure those crash points from humans 
> reading the code. It would no longer be possible to read call sites and be 
> able to distinguish which ones might crash due to an uncaught error.
> 
> (There are exceptions to this rule. Ordinary arithmetic and array access are 
> checked at runtime, and the default syntax is one that may crash.)
> 

Indirectly Diving by zero [1] // the compiler won’t let you directly divide by 
zero
Overflow or underflow [2]
Array Index out of range

Aside from those, Are there any other runtime “exceptions"?


[1] https://en.wikipedia.org/wiki/Undefined_(mathematics)#In_arithmetic 


//[2] example:
let number = Int16.max
print(number+1) //crash Illegal instruction

> 
> -- 
> 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] [Pitch] Nil struct

[Jose Cheyo Jimenez via swift-evolution]

> On Nov 8, 2016, at 1:05 PM, Anton Zhilin  wrote:
> 
> 2016-11-08 23:43 GMT+03:00 Jose Cheyo Jimenez :
> 
>> Thank for thinking of this. I am not sure on the advantage of having nil as 
>> a concrete type. 
>> 
>> Have you seen this talk?
>> 
>> https://realm.io/news/swift-summit-al-skipp-monads/
>> 
>> "The concept of “nil” does not exist in Swift (despite the existence of the 
>> keyword nil!)"
>> 
>> Does that talk change your mind about this pitch?
> 
> Not much. We can talk about Swift literals being untyped as much as we want, 
> but still all of them, except for nil, have an internal storage type, which 
> is also picked by default.
> 
Having nil be a concrete type would be extremely confusing to me. I believe 
currently nil gets stripped out during compilation and it gets replaced with 
their respective Optional.none
 nil is just a convenient way to work with optionals. The same goes to implicit 
unwrap optionals !

I guess I don't see a reason why nil should be a concrete at all.  

> For example, integer literals are Builtin.Int2048, if I’m not mistaken. But 
> we just can’t store nil without creating an instance of a potentially complex 
> type.
> 
> And this proposal is not about adding nil to all types. You can do this now 
> with Any, in any case:
> 
> let optionalInt1: Any = 42
> let optionalInt2: Any = ()   // ewww
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Nil struct

[Jose Cheyo Jimenez via swift-evolution]

Thank for thinking of this. I am not sure on the advantage of having nil as a 
concrete type. 

Have you seen this talk?

https://realm.io/news/swift-summit-al-skipp-monads/

"The concept of “nil” does not exist in Swift (despite the existence of the 
keyword nil!)"

Does that talk change your mind about this pitch? 





> On Nov 8, 2016, at 12:30 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Gist link
> 
> Introduction
> 
> Change nil literal type from () to Nil.
> Before:
> 
> public protocol ExpressibleByNilLiteral {
>   init(nilLiteral: ())
> }
> After:
> 
> public struct Nil {
>   init()
> }
> public protocol ExpressibleByNilLiteral {
>   associatedtype NilLiteralType = Nil
>   init(nilLiteral: NilLiteralType)
> }
> Motivation
> 
> Currently, nil differs from other literals: it doesn’t have its own type.
> But in some cases we want to deal directly with it, without creating any 
> instances.
> 
> The most important use case is comparison of an Optional to nil.
> Currently, this operation is implemented using a hidden struct 
> _OptionalNilComparisonType,
> which is needed precisely because because nil does not have its own type.
> Removal of such underscored types is one of the goals stated in Generics 
> manifesto.
> 
> Additionally, declaration of ExpressibleByNilLiteral differs from all other 
> Expressibles,
> because it doesn’t have a Literal type. It is generally beneficial to 
> eliminate special cases.
> 
> Proposed solution
> 
> Introduce a struct Nil, which becomes the default type for nil literals:
> 
> public struct Nil : ExpressibleByNilLiteral {
>   init()
>   init(nilLiteral: NilLiteralType)
> }
> 
> let a = nil
> print(type(of: a))   //=> Nil
> Rewrite ExpressibleByNilLiteral:
> 
> public protocol ExpressibleByNilLiteral {
>   associatedtype NilLiteralType = Nil
>   init(nilLiteral: NilLiteralType)
> }
> Make use of Nil in the standard library:
> 
> public func == (left: T?, right: Nil)
> public func == (left: Nil, right: T?)
> public func != (left: T?, right: Nil)
> public func != (left: Nil, right: T?)
> public func ~= (left: Nil, right: T?)
> Source compatibility
> 
> Nil identifier is taken, therefore applications that already use it will stop 
> compiling.
> Automatic migration is somewhat possible by renaming of the old entity; 
> manual migration is recommended.
> 
> Applications that use declare ExpressibleByNilLiteral conformances will stop 
> compiling.
> Automatic migration is possible.
> 
> Effect on ABI stability
> 
> Applications that use Nil identifier will have to make ABI-breaking changes.
> 
> Otherwise, the change can mostly be applied in an ABI-compatible manner.
> 
> ___
> 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] Replace the ternary operator with an in-language function

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> Preamble: I've read over the threads that already exist about the ternary 
> operator and to be honest they're a complete mess without a single fully 
> formed proposal.
> 

You state the issue beautifully. Previous attempts have been "Complete mess" I 
agree. This is a commonly proposed feature and your solution unfortunately is 
not new. :( 

Replace ?: ternary operator: Definitely magical, but it serves a very important 
use-case for terse selection of different values. Proposals for alternatives 
have been intensely discussed, but none have been "better enough" for it to 
make sense to diverge from the precedent established by the C family of 
languages.



> Pitch: I'd like to simplify the syntax, compiler complexity and learning 
> curve for newcomers when it comes to dealing with the ternary function. The 
> best way to do that, in my opinion, is to remove it entirely and add a new 
> function with better semantics that takes care of ternary operations entirely 
> within the Swift language.
> 
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
> 
> Replace the `?:` operator with an in-language function
> 
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata)
> Editor: [Soroush Khanlou](https://github.com/khanlou)
> Review Manager: TBD
> Status: TBD
> 
> Introduction
> 
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
> 
> As a quick refresher, here's what the ternary operator looks like:
> 
> let a = 10
> let b = 20
> // If a is less than b, sets e to "foo", else sets e to "bar"
> let e = a < b ? "foo" : "bar"
> 
> Advantages of The Ternary Operator
> 
> The primary advantage of this operator is its terseness and expressive
> capability. It's shorthand for (e.g.):
> 
> let a = 10
> let b = 20
> let e: String
> if a < b {
>   e = "foo"
> } else {
>   e = "bar"
> }
> 
> The second advantage of Swift supporting the ternary operator is continuity
> with C, and other common languages in the extended C family (C++, Objective-C,
> Java, C#, Javascript, etc).  People coming to Swift from these other languages
> may reasonably expect this operator to exist.  That said, there are also
> popular languages which have kept the majority of C operators but dropped the
> ternary operator (e.g. 
> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form) and 
> [Rust](https://github.com/rust-lang/rfcs/issues/1362)).
> 
> 
> Disadvantages of The Ternary Operator
> 
> 1. The existence of the ternary operator as a holdover from C is to increase
> the familiarity of the Swift language for C family developers, at the expense
> of newcomers.  Established developers do much better with learning concepts
> than newcomers to programming and probably don't need their hands held
> with this carry over of an operator.
> 
> 2. The ternary operator adds complexity to the compiler, because it requires
> special handling.  It is the only operator that requires two components to
> work (both the `?` and the `:`), it uses a character that is excluded from
> being used in other operators (`:`), and it isn't defined in the standard
> library.
> 
> 3. The ternary operator's usage of `?` can be confusing
> to new users.  Every other instance of `?` is associated with
> `Optional` values.
> 
> 4. The ternary operator uses `:`, which is already a heavily overloaded
> symbol in Swift.  `:` is used in hash tables, type annotations for variables,
> class inheritance, and protocol conformance.
> 
> 5. The ternary operator's short length lends it to being abused in the
> nested ternary operator anti-pattern.  This is similar to the `++` and
> `--` operators, which were removed in Swift 3.  While they worked fine and 
> were
> readable enough when used alone, using them multiple times in a single
> expression like `function(a++, ++a)` made them highly unreadable and
> confusing.
> 
> 6. This operator is only applicable to a single type, `Bool`.
> 
> 7. If the ternary operator weren't in common usage, it would not be proposed
> for Swift.  Higher clarity can be achieved with common language features by
> creating an extension to `Bool`.
> 
> 8. The ternary operator was created for and is much more suited to a language
> like C, where there were no generics and as such no alternative to an
> unintuitive operator.
> 
> 9. Several other modern languages, like Rust and Go discussed earlier, have
> eschewed the usage of the ternary operator entirely.  Other languages that 
> have
> special constructs similar to `?:`, such as `if then else` in Haskell have
> [discussed removing 
> 

Re: [swift-evolution] A unified error handling mechanism?

[Jose Cheyo Jimenez via swift-evolution]

Hi Fernando, 

Some projects use a result type to unify the error handling. 
https://github.com/antitypical/Result 

There has been discussions about this and Chris L thinks that we may get a 
native (constrained) result type at some point. 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007858.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008057.html
 


I can see a future where these get unified but the main issue imo is cocoa 
compatibility. 

Probably swift 5+

Cheers!,
J. Cheyo



> On Aug 5, 2016, at 4:50 PM, Fernando Rodríguez via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I do a lot of training and one of the features of Swift that seems more 
> confusing to students (and myself) is error handling. There are too many ways 
> of doing it, and none seems satisfactory.
> 
> Let's take for example an initializer. There are 2 different ways of handling 
> errors within an init:
> 
> a) Old School: return nil. This was very simple in Objective C, because the 
> uncommon case of an error could be easily ignored...until everything crashed.
> 
> In Swift it's not easy (nor advisable IMHO) to completely ignore the 
> possibility of an error. Besides, it has 2 complications.
> 
> First of all, you return an Optional, and Optionals have a tendency to go 
> viral. Suddenly, all your code has to deal with optionals.
> 
> Secondly, you have no information about the error itself.
> 
> b) do/try/catch
> 
> This allows you to have information about the error, but also causes the 
> newly created object to be "trapped" inside a do block.
> 
> Are there any plans to address this situation? I believe there should be a 
> single, obvious and convenient way of handling errors in the language.
> 
> What do you guys think?
> 
> 
> 
> -- 
> 
> 
> 
>  
> 
> Fernando Rodríguez
> m. +34 610 965 332
> t. +34 91 629 57 61
> fernando@k eepcoding.io 
>   
> KeepCoding.io
> 2120 University Avenue, Berkeley, CA
> 
> Avda. Fuencarral, 44, Ed. 8, Loft 30
> 28108 Alcobendas (Madrid) Spain
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 27, 2016, at 5:58 AM, Brent Royal-Gordon  
> wrote:
> 
>> On Jul 26, 2016, at 5:45 PM, Brent Royal-Gordon  
>> wrote:
>> 
>> I'm working on an implementation (so far I just have `dropFirst` renamed, 
>> but I've only spent about half an hour on it, mostly waiting for tests), but 
>> the diff isn't really going to tell you much.
> 
> Now finished: https://github.com/apple/swift/pull/3793/files
> 
> The diff shows a lot of lines touched, but that's mainly unrelated 
> documentation—it turns out an awful lot of examples use `index(of:)`!—and 
> tests.

Nice work! Thanks for putting this together. Very helpful. 

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

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

[Jose Cheyo Jimenez via swift-evolution]

I think we are missing some sort of diff to show the impact of this proposal 
similar to what we had for the “grand renaming"


> On Jul 26, 2016, at 1:23 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Jul 26 2016, Anton Zhilin  > wrote:
> 
>> I double Nevin on everything he said, especially about incomplete ranges.
>> 
>> 2016-07-26 21:13 GMT+03:00 Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org >:
>> 
>>> 
>>> on Tue Jul 26 2016, Nevin Brackett-Rozinsky <
>>> nevin.brackettrozinsky-AT-gmail.com> wrote:
>>> 
* What is your evaluation of the proposal?
 
 “It’s complicated”
 
 First, I agree with the prevailing sentiment that the incomplete-range
 portion ought to be separated and postponed.
>>> 
>>> FWIW, I don't see any evidence that such a sentiment prevails.
>>> 
>>> tail-wagging-the-dog?-ly y'rs,
> 
> Looks like I had missed some messages in the thread.  I see the evidence
> now.
> 
> Sorry,
> 
> -- 
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0132: Rationalizing Sequence end-operation names" begins 
> now and runs through July 26.  Apologies for the short review cycle, but 
> we’re right up against the end of source breaking changes for Swift 3.  The 
> proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?

+1 

In the future section :

I strongly dislike every(where:) but I would not be opposed to select(where:) 
but I think filter, map, reduce etc are way better names. 


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

Yes. There was too much inconsistency.  


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

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

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 24, 2016, at 11:18 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0134: Rename two UTF8-related properties on String" begins 
> now and runs through July 26.  Apologies for the short review cycle, but 
> we’re right up against the end of source breaking changes for Swift 3.  The 
> proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
+1
>* 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?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
Read thread. 
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs 
> through July 26.  Apologies for the short review cycle, but we’re right up 
> against the end of source breaking changes for Swift 3.  The proposal is 
> available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
-1
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

I don't thinks so. 

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

I think we would loose readability. I appreciate having flatten() specially 
when I have to combine it with joined().

This to me would be unfortunate when reading:
[["hey"], ["what"]].joined().joined()


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

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

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jose Cheyo Jimenez via swift-evolution]

[["hey"], ["what"]].joined().joined() // proposed

vs

[["hey"], ["what"]].flatten().joined(separator: “”) // now

I do agree that having two way of doing it now seems odd. 

[["hey"], ["what"]].joined(separator: []).joined(separator: “”)  // now




> On Jul 24, 2016, at 5:47 PM, Jacob Bandes-Storch  wrote:
> 
> The thing is, joined also works on arrays-of-arrays today. The only 
> difference is that flatten doesn't have a separator.
> 
> We wouldn't lose what your example shows — you could do this:
> 
> [["hey"], ["what"]].joined().joined(separator: “")
> On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez  > wrote:
> Here is a quick example that we would loose.
> 
> [["hey"], ["what"]].flatten().joined(separator: “")
> 
> [["hey"], ["what"]].flatten() //  ["hey", "what”]
> 
> The way I think of it is flatten works on array of arrays while joined works 
> on arrays of strings. 
> 
> I guess we could do this too
> 
> [["hey"], ["what"]].joined(separator: []).joined(separator: "")
> 
> 
> 
>> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez > > wrote:
>> 
>> -1 for this. To me there needs to be a difference between String (which is 
>> not a normal collection) and other regular collections. 
>> 
>> In addition, I really don’t think this proposal has the needed strong 
>> support for the change. 
>> 
>> 
>> 
>> 
>>> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
>>> Here's a proposal draft. Comments welcome:
>>> 
>>> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington >> > wrote:
>>> 
>>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch >> > > wrote:
>>> >
>>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington >> >> > wrote:
>>> >>
>>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>> >>>
>>> >>> In the swift-lang Slack channel, a few of us were discussing 
>>> >>> joined(separator:) and realized that flatten() does almost exactly the 
>>> >>> same thing.
>>> >>>
>>> >>> Is there interest in renaming flatten() to joined()?  Since joined 
>>> >>> takes a separator that's any Sequence, we can't have a default value 
>>> >>> for the separator parameter, but we can have a variant of joined() with 
>>> >>> no arguments.
>>> >>
>>> >> I'd like default separators for the joined() methods.
>>> >>
>>> >> >> >> >
>>> >>
>>> >> But renaming flatten() to joined() seems complicated.
>>> >>
>>> >> >> >>  
>>> >> >
>>> >> >> >>  
>>> >> >
>>> >
>>> > What makes it seem complicated? At the very least, one could just rename 
>>> > the flatten() function. There might also be an opportunity to combine the 
>>> > two files and delete some code from stdlib.
>>> 
>>> There's only one joined() method (for a sequence of sequences):
>>> 
>>> extension Sequence {
>>>   func joined(separator: Separator) -> 
>>> JoinedSequence
>>> }
>>> 
>>> There are many flatten() methods (`where` clauses omitted for brevity):
>>> 
>>> extension Sequence {
>>>   func flatten() -> FlattenSequence
>>> }
>>> 
>>> extension LazySequenceProtocol {
>>>   func flatten() -> LazySequence
>>> }
>>> 
>>> extension LazyCollectionProtocol {
>>>   func flatten() -> LazyCollection
>>> }
>>> 
>>> extension Collection {
>>>   func flatten() -> FlattenCollection
>>> }
>>> 
>>> extension BidirectionalCollection {
>>>   func flatten() -> FlattenBidirectionalCollection
>>> }
>>> 
>>> So it's not a simple one-to-one rename.
>>> 
>>> When there's no `separator` argument, will FlattenIterator perform better 
>>> than JoinedIterator?
>>> 
>>> >> And what would happen to the flatMap() methods? Is flatten() a term of 
>>> >> art?
>>> >>
>>> >> >> >>  
>>> >> >
>>> >
>>> > I'd say flatMap is more a "term of art" than flatten. "flatten" just 
>>> > describes literally what is being done. Frankly I'm surprised it was 
>>> > never named 

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jose Cheyo Jimenez via swift-evolution]

Here is a quick example that we would loose.

[["hey"], ["what"]].flatten().joined(separator: “")

[["hey"], ["what"]].flatten() //  ["hey", "what”]

The way I think of it is flatten works on array of arrays while joined works on 
arrays of strings. 

I guess we could do this too

[["hey"], ["what"]].joined(separator: []).joined(separator: "")



> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez  wrote:
> 
> -1 for this. To me there needs to be a difference between String (which is 
> not a normal collection) and other regular collections. 
> 
> In addition, I really don’t think this proposal has the needed strong support 
> for the change. 
> 
> 
> 
> 
>> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> Here's a proposal draft. Comments welcome:
>> 
>> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 
>> 
>> 
>> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington > > wrote:
>> 
>> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch > > > wrote:
>> >
>> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington > >> > wrote:
>> >>
>> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>> >>>
>> >>> In the swift-lang Slack channel, a few of us were discussing 
>> >>> joined(separator:) and realized that flatten() does almost exactly the 
>> >>> same thing.
>> >>>
>> >>> Is there interest in renaming flatten() to joined()?  Since joined takes 
>> >>> a separator that's any Sequence, we can't have a default value for the 
>> >>> separator parameter, but we can have a variant of joined() with no 
>> >>> arguments.
>> >>
>> >> I'd like default separators for the joined() methods.
>> >>
>> >> > >> >
>> >>
>> >> But renaming flatten() to joined() seems complicated.
>> >>
>> >> > >>  
>> >> >
>> >> > >> >
>> >
>> > What makes it seem complicated? At the very least, one could just rename 
>> > the flatten() function. There might also be an opportunity to combine the 
>> > two files and delete some code from stdlib.
>> 
>> There's only one joined() method (for a sequence of sequences):
>> 
>> extension Sequence {
>>   func joined(separator: Separator) -> 
>> JoinedSequence
>> }
>> 
>> There are many flatten() methods (`where` clauses omitted for brevity):
>> 
>> extension Sequence {
>>   func flatten() -> FlattenSequence
>> }
>> 
>> extension LazySequenceProtocol {
>>   func flatten() -> LazySequence
>> }
>> 
>> extension LazyCollectionProtocol {
>>   func flatten() -> LazyCollection
>> }
>> 
>> extension Collection {
>>   func flatten() -> FlattenCollection
>> }
>> 
>> extension BidirectionalCollection {
>>   func flatten() -> FlattenBidirectionalCollection
>> }
>> 
>> So it's not a simple one-to-one rename.
>> 
>> When there's no `separator` argument, will FlattenIterator perform better 
>> than JoinedIterator?
>> 
>> >> And what would happen to the flatMap() methods? Is flatten() a term of 
>> >> art?
>> >>
>> >> > >>  
>> >> >
>> >
>> > I'd say flatMap is more a "term of art" than flatten. "flatten" just 
>> > describes literally what is being done. Frankly I'm surprised it was never 
>> > named flattened(). Anyway, flatMap should stay.
>> 
>> ## Future directions
>> 
>> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
>> 
>> That's an interesting idea. It seems to be purely additive, however, so I 
>> imagine it wouldn't happen until after Swift 3.
>> 
>> 
>> -- Ben
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

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

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

[Jose Cheyo Jimenez via swift-evolution]

-1 for this. To me there needs to be a difference between String (which is not 
a normal collection) and other regular collections. 

In addition, I really don’t think this proposal has the needed strong support 
for the change. 




> On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Here's a proposal draft. Comments welcome:
> 
> https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 
> 
> 
> On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington  > wrote:
> 
> > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch  > > wrote:
> >
> >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington  >> > wrote:
> >>
> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
> >>>
> >>> In the swift-lang Slack channel, a few of us were discussing 
> >>> joined(separator:) and realized that flatten() does almost exactly the 
> >>> same thing.
> >>>
> >>> Is there interest in renaming flatten() to joined()?  Since joined takes 
> >>> a separator that's any Sequence, we can't have a default value for the 
> >>> separator parameter, but we can have a variant of joined() with no 
> >>> arguments.
> >>
> >> I'd like default separators for the joined() methods.
> >>
> >>  >> >
> >>
> >> But renaming flatten() to joined() seems complicated.
> >>
> >>  >>  
> >> >
> >>  >> >
> >
> > What makes it seem complicated? At the very least, one could just rename 
> > the flatten() function. There might also be an opportunity to combine the 
> > two files and delete some code from stdlib.
> 
> There's only one joined() method (for a sequence of sequences):
> 
> extension Sequence {
>   func joined(separator: Separator) -> 
> JoinedSequence
> }
> 
> There are many flatten() methods (`where` clauses omitted for brevity):
> 
> extension Sequence {
>   func flatten() -> FlattenSequence
> }
> 
> extension LazySequenceProtocol {
>   func flatten() -> LazySequence
> }
> 
> extension LazyCollectionProtocol {
>   func flatten() -> LazyCollection
> }
> 
> extension Collection {
>   func flatten() -> FlattenCollection
> }
> 
> extension BidirectionalCollection {
>   func flatten() -> FlattenBidirectionalCollection
> }
> 
> So it's not a simple one-to-one rename.
> 
> When there's no `separator` argument, will FlattenIterator perform better 
> than JoinedIterator?
> 
> >> And what would happen to the flatMap() methods? Is flatten() a term of art?
> >>
> >>  >>  
> >> >
> >
> > I'd say flatMap is more a "term of art" than flatten. "flatten" just 
> > describes literally what is being done. Frankly I'm surprised it was never 
> > named flattened(). Anyway, flatMap should stay.
> 
> ## Future directions
> 
> Will the flatMap(_:) methods also have flatMap(separator:_:) variants?
> 
> That's an interesting idea. It seems to be purely additive, however, so I 
> imagine it wouldn't happen until after Swift 3.
> 
> 
> -- Ben
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Rename `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Jose Cheyo Jimenez via swift-evolution]

Is your proposal going to make the swift3 window? 

On Jul 24, 2016, at 8:23 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 24, 2016, at 2:58 AM, Tim Vermeulen via swift-evolution 
>>  wrote:
>> 
>> `firstIndex` is completely unambiguous, whereas with `index` people might 
>> wonder which index is returned. Also, if `lastIndex` methods ever get added 
>> to the standard library, they will be a lot more consistent with 
>> `firstIndex` than with `index`.
>> 
>> On the other hand, `index` is short and simple, and people might not care 
>> whether it is the first index that matches or a different one. Still I think 
>> `firstIndex` is more in line with the naming guidelines.
>> 
>> Thoughts?
> 
> Working on it! 
> https://github.com/brentdax/swift-evolution/blob/09be1007c5138be2370f33d761b05b8b6700a9a3/proposals/-sequence-end-ops.md
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Jose Cheyo Jimenez via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

> On Jul 24, 2016, at 2:21 AM, Boris Wang <kona.m...@gmail.com> wrote:
> 
> just write code in playground：
> struct MyStruct ｛
> var t = 0
> ｝
> sizeof(MyStruct)
> 
> Compiler error：
> Missing '.self' for reference to metatype of type 'MyStruct'
> 
> The metatype is from swift it self!
> 
> What the hell was the .self?
> 
> 
> Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org>于2016年7月24日 
> 周日04:45写道：
>> I'm finding it really hard to see the advantage of this proposal with out 
>> reconciling the possibility of .self going away. I think this should be 
>> postponed after .self is reviewed in swift 4. Premature optimization imo. 
>> 
>>> On Jul 22, 2016, at 3:20 PM, David Hart via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Where do these double generics come from? Never saw them...
>>> 
>>>> On 22 Jul 2016, at 17:54, Anton Zhilin <antonyzhi...@gmail.com> wrote:
>>>> 
>>>> 2016-07-22 18:51 GMT+03:00 David Hart <da...@hartbit.com>:
>>>>> Isn't the solution to a lot of these issues allowing explicit 
>>>>> generalization instead of this meta type business?
>>>> 
>>>> And what would you suggest for "double generics" in initializers?
>>>> ExampleType()  // not good
>>> ___
>>> 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] [Revision] [Pitch] Rename `T.Type`

[Jose Cheyo Jimenez via swift-evolution]

I'm finding it really hard to see the advantage of this proposal with out 
reconciling the possibility of .self going away. I think this should be 
postponed after .self is reviewed in swift 4. Premature optimization imo. 

> On Jul 22, 2016, at 3:20 PM, David Hart via swift-evolution 
>  wrote:
> 
> Where do these double generics come from? Never saw them...
> 
>> On 22 Jul 2016, at 17:54, Anton Zhilin  wrote:
>> 
>> 2016-07-22 18:51 GMT+03:00 David Hart :
>>> Isn't the solution to a lot of these issues allowing explicit 
>>> generalization instead of this meta type business?
>> 
>> And what would you suggest for "double generics" in initializers?
>> ExampleType()  // not good
> ___
> 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 access level as the default for its members?

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 22, 2016, at 7:05 PM, Félix Cloutier <felix...@yahoo.ca> wrote:
> 
> The only point that judges the proposal on its merits would be the first one, 
> and I would personally be happy to have that discussion.

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

I think that battle is lost for now. 

> 
> Félix
> 
>> Le 22 juil. 2016 à 10:14:13, Jose Cheyo Jimenez via swift-evolution 
>> <swift-evolution@swift.org> a écrit :
>> 
>> 
>> 
>> On Jul 22, 2016, at 3:34 AM, Eric-Paul Lecluse via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> To illustrate my question below, here are three publicly modified entities: 
>>> a struct, an enum and an extension, whose properties lack explicit access 
>>> modifiers:
>>> 
>>> public struct Car {
>>> var wheel: [Wheel]
>>> var licensePlate: String
>>>
>>> func combust() { ... }
>>> }
>>> 
>>> public enum Wheel {
>>> case big
>>> case small
>>> 
>>> var revolutionDistance: Double { ... }
>>> }
>>> 
>>> public extension Car {
>>> func park() { ... }
>>> }
>>> 
>>> The default access level for every member is `internal` for all members of 
>>> an original type. Therefore both `combust()` and `revolutionDistance` are 
>>> publicly inaccessible. For extensions, this is different, `park()` _is_ 
>>> publicly accessible (as would be computed properties if it had any) because 
>>> the extension is marked `public`. There's no option to modify an enum's 
>>> cases individually (nor should there be), they're inherently linked to the 
>>> enum's access level.
>>> 
>>> When modifying any of the entities to `private`, their members become 
>>> inaccessible by association. If a type isn't accessible, neither are its 
>>> members. Thus for the `private` case, the behavior feels more like what the 
>>> extension modifier did in the first place. 
>>> 
>>> Not immediately apparent from this example is that the struct has an 
>>> implicit constructor (lacking any explicit ones), whose access level also 
>>> defaults to `internal`. This means the Car-struct can't be constructed 
>>> outside of its defining module, until we create an explicit initializer 
>>> with the `public` access modifier.
>>> 
>>> # Problems
>>> The current approach is very verbose for any kind of access modification. 
>>> Public structs that are intended to expose their members, require 
>>> explicitly marked `public` modifiers everywhere. Consider the case where 
>>> you want to expose a previously hidden (internal or private) type, you need 
>>> to modify every individual member. Except if you're modifying an extension, 
>>> in that case you only need to modify in one place. This means that 
>>> conceptually, putting a `public` or `private` modifier on a type behaves 
>>> differently from putting one one an extension, with regard to a type's 
>>> members, which can lead to confusion (and has in my case, and with several 
>>> fellow developers).
>>> 
>>> # Idea
>>> What if the default access level were chosen differently? Instead of being 
>>> `internal` by default, or `private` by association, what if the 
>>> _type-level_ access modifier would determine the default for _all_ members, 
>>> unless explicitly modified, including `public` and to-be-introduced ones?
>> 
>> I don't think this is going fly:
>> - internal is the default because the team wants any public API to be 
>> explicit. 
>> - There was a rejected proposal (119?) that tried to make extensions work 
>> just like types. 
>> - This is a breaking change and we are out of time for swift3
>> - What you want is already offered by public extensions. (Some people find 
>> this confusing but it looks like this is stay in swift 3). 
>> 
>> 
>>> 
>>> This would...
>>> 1. equalize the conceptual behavior between access levels of an original 
>>> type and the ones of their extensions.
>>> 2. greatly reduce verbosity on members due to explicit access level 
>>> modifiers.
>>> 3. make it easier to modify the access level of an entire type, without 
>>> requiring modification of individual members.
>>> 4. reduce the requirement of public constructors where they would match the 
>>> implicit ones

Re: [swift-evolution] Type access level as the default for its members?

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 22, 2016, at 3:34 AM, Eric-Paul Lecluse via swift-evolution 
>  wrote:
> 
> To illustrate my question below, here are three publicly modified entities: a 
> struct, an enum and an extension, whose properties lack explicit access 
> modifiers:
> 
> public struct Car {
> var wheel: [Wheel]
> var licensePlate: String
>
> func combust() { ... }
> }
> 
> public enum Wheel {
> case big
> case small
> 
> var revolutionDistance: Double { ... }
> }
> 
> public extension Car {
> func park() { ... }
> }
> 
> The default access level for every member is `internal` for all members of an 
> original type. Therefore both `combust()` and `revolutionDistance` are 
> publicly inaccessible. For extensions, this is different, `park()` _is_ 
> publicly accessible (as would be computed properties if it had any) because 
> the extension is marked `public`. There's no option to modify an enum's cases 
> individually (nor should there be), they're inherently linked to the enum's 
> access level.
> 
> When modifying any of the entities to `private`, their members become 
> inaccessible by association. If a type isn't accessible, neither are its 
> members. Thus for the `private` case, the behavior feels more like what the 
> extension modifier did in the first place. 
> 
> Not immediately apparent from this example is that the struct has an implicit 
> constructor (lacking any explicit ones), whose access level also defaults to 
> `internal`. This means the Car-struct can't be constructed outside of its 
> defining module, until we create an explicit initializer with the `public` 
> access modifier.
> 
> # Problems
> The current approach is very verbose for any kind of access modification. 
> Public structs that are intended to expose their members, require explicitly 
> marked `public` modifiers everywhere. Consider the case where you want to 
> expose a previously hidden (internal or private) type, you need to modify 
> every individual member. Except if you're modifying an extension, in that 
> case you only need to modify in one place. This means that conceptually, 
> putting a `public` or `private` modifier on a type behaves differently from 
> putting one one an extension, with regard to a type's members, which can lead 
> to confusion (and has in my case, and with several fellow developers).
> 
> # Idea
> What if the default access level were chosen differently? Instead of being 
> `internal` by default, or `private` by association, what if the _type-level_ 
> access modifier would determine the default for _all_ members, unless 
> explicitly modified, including `public` and to-be-introduced ones?

I don't think this is going fly:
- internal is the default because the team wants any public API to be explicit. 
- There was a rejected proposal (119?) that tried to make extensions work just 
like types. 
- This is a breaking change and we are out of time for swift3
- What you want is already offered by public extensions. (Some people find this 
confusing but it looks like this is stay in swift 3). 


> 
> This would...
> 1. equalize the conceptual behavior between access levels of an original type 
> and the ones of their extensions.
> 2. greatly reduce verbosity on members due to explicit access level modifiers.
> 3. make it easier to modify the access level of an entire type, without 
> requiring modification of individual members.
> 4. reduce the requirement of public constructors where they would match the 
> implicit ones.
> 5. still allow exceptions on an individual level
> 
> What do you think?
> Regards,
> Eric-Paul
> 
> --
> Notes:
> * I'm using the word 'entity' to lump types and extensions together under one 
> term. There must be a better term, please do share!
> * My examples are based off of my experience with Swift 2.2, even though I 
> believe the concepts still apply in 2.3 and the 3.0-beta.
> * Protocols don't allow access modification on individual members, of course, 
> similar to an enum's cases.
> * Didn't find any similar topics in the [commonly rejected 
> list](https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md)
> * There's a [newly accepted 
> proposal](https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#proposed-solution)
>  that adds `fileprivate` as a fourth access level modifier.
> 
> Other discussions about access levels, yet not what I was looking for:
> * [Default access control / Access control blocks] 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013683.html)
> * [Access modifier blocks] 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 21, 2016, at 7:15 PM, Duan via swift-evolution 
>  wrote:
> 
> Great proposal. I want to second that areSame may mislead user to think this 
> is about identity.
> 
> I like areEquivalent() but there may be better names.

what about areEqual() ?

> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Jul 21, 2016, at 6:32 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu  wrote:
>>> 
>>> This is nice. Is `areSame()` being proposed because static `==` is the 
>>> status quo and you're trying to make the point that `==` in the future need 
>>> not guarantee the same semantics?
>> 
>> Yep!  Equivalence and equality are strictly very different things.
>> 
>>> 
>>> Nit: I think the more common term in stdlib would be `areEquivalent()`. Do 
>>> you think `same` in that context (independent of the word "ordering") might 
>>> erroneously suggest identity?
>> 
>> There is room for improvement here.  Keep ‘em coming.
>> 
>>> 
>>> 
 On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via swift-evolution 
  wrote:
 Hello Swift Community,
 
 Harlan Haskins, Jaden Geller, and I have been working on a proposal to 
 clean up the semantics of ordering relations in the standard library.  We 
 have a draft that you can get as a gist.  Any feedback you might have 
 about this proposal helps - though please keeps your comments on 
 Swift-Evolution and not on the gist.
 
 Cheers,
 
 ~Robert Widmann
 
 
 
 
 
 ___
 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] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Jose Cheyo Jimenez via swift-evolution]

>   * What is your evaluation of the proposal?
+1 as before but for the first implementation. 

I want to like implementation 2 but I really don’t see the need for it because 
extensions. 

The only reason for 2 is if the core team thinks that we will never get stored 
properties can be added via extensions. 


>   * 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?
n/1
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
reviewed the last two iterations. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 20, 2016, at 10:36 AM, Leonardo Pessoa <m...@lmpessoa.com> wrote:
> 
> I like this syntax better. But do you guys think we could remove this
> "subscript" prefix?
I like the subscripts to be explicit. 

> Could we actually bring subscripts closer to
> computed properties by doing something like "var self[externaName
> internalName : ParamType] : ElemenType"? That could also support the
> idea of creating named subscripts by replacing self with another name.

:) I can already see how this could turn swift into Objc. 
I don’t think I like that idea. ;( People already abuse subscripts as it is.

> L
> 
> 
> On 20 July 2016 at 14:17, Jose Cheyo Jimenez via swift-evolution
> <swift-evolution@swift.org> wrote:
>> 
>> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution
>> <swift-evolution@swift.org> wrote:
>> 
>> +1 to clean up the syntax of subscripts. They acts as properties, not
>> methods, so it is natural to express them with `:` and not with `->`.
>> 
>> Actually, I'd prefer additional change to use [] instead of () in
>> declaration like:
>> 
>> subscript[externalName internalName: ParamType] : ElementType {
>>   get { … }
>>   set { … }
>> }
>> 
>> 
>> I got to second this suggestion. To me this is an elegant solution.
>> 
>> If subscripts are so special that Swift decided to give it its own name (as
>> oppose to just making it two functions),
>> why not declare it in a special way like the above?
>> 
>> I think that in addition to replacing -> with : if we replaced () with []
>> then it would be much clearer that this is not a function or property.
>> 
>> subscript[externalName internalName: ParamType] : ElementType {
>>get { … }
>>set { … }
>> }
>> 
>> 
>> I don’t see another place in the language where [] would make more sense
>> than here:
>> Otherwise I don’t see  replacing -> with : as a big win like Dmitri Gribenko
>> said down thread ->
>> 
>> I think by changing subscripts to use colons we would end in the opposite,
>> but
>> totally symmetrical situation compared to what we have now.
>> 
>> 
>> 
>> 
>> 
>> especially if thinking about "Future directions" and confusion with
>> parameterised accessor syntax(both declared with `()` but first used with
>> `[]` and second with `()`).
>> 
>> On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0122: Use colons for subscript declarations " begins now
>> and runs through July 24. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and contribute to the direction of Swift.
>> When writing your review, here are some questions you might want to answer
>> in your review:
>> 
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a change to
>> Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have used other languages or libraries with a similar feature, how
>> do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick reading,
>> or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> ___
>> 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-0122: Use colons for subscript declarations

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> +1 to clean up the syntax of subscripts. They acts as properties, not 
> methods, so it is natural to express them with `:` and not with `->`.
> 
> Actually, I'd prefer additional change to use [] instead of () in declaration 
> like:
> 
> subscript[externalName internalName: ParamType] : ElementType {
>get { … }
>set { … }
> }

I got to second this suggestion. To me this is an elegant solution. 

If subscripts are so special that Swift decided to give it its own name (as 
oppose to just making it two functions), 
why not declare it in a special way like the above?

I think that in addition to replacing -> with : if we replaced () with [] then 
it would be much clearer that this is not a function or property. 

subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}

I don’t see another place in the language where [] would make more sense than 
here: 
Otherwise I don’t see  replacing -> with : as a big win like Dmitri Gribenko 
said down thread ->

>> I think by changing subscripts to use colons we would end in the opposite, 
>> but
>> totally symmetrical situation compared to what we have now.


 

> 
> especially if thinking about "Future directions" and confusion with 
> parameterised accessor syntax(both declared with `()` but first used with 
> `[]` and second with `()`).
> 
> On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
>> Hello Swift community,
>> 
>> The review of "SE-0122: Use colons for subscript declarations " begins now 
>> and runs through July 24. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 19, 2016, at 4:13 AM, James Froggatt via swift-evolution 
>  wrote:
> 
> Based on the discussion, I think the real danger of subclassing is unexpected 
> behaviour - in other words, overriding methods. There doesn't seem to be a 
> need to penalise subclasses which just add properties and extra methods based 
> on them.
> 
> I'd be in favour of keeping current behaviour for classes, but having to mark 
> methods explicitly as overrideable, virtual, open, or whatever semantics we 
> decide upon. This seems like the safest syntax.
> 
> I'd also support a grouping mechanism for marking methods in this way, 
> similar to extensions' current auto-annotation for ‘public’.
The is a proposal waiting to be merged that seeks to disallow public extensions 
auto-annotation. I think extensions would be better with out it. 


> 
>  Begin Message  
> Group: gmane.comp.lang.swift.evolution 
> MsgID: <2c9b4c5a-52c2-4e0e-8b9e-6e5444629...@apple.com> 
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> - End Message - 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 18, 2016, at 1:49 PM, L. Mihalkovic via swift-evolution 
>  wrote:
> 
> Regards
> (From mobile)
> 
>> On Jul 18, 2016, at 9:53 PM, Károly Lőrentey via swift-evolution 
>>  wrote:
>> 
>> If people were generally happy with having public members of open classes 
>> overridable by default, then we certainly wouldn't need to have a separate 
>> qualifier for that. (Although as "internal" demonstrates, it's nice to have 
>> a formal name for such things.)
>> 
>> 
>> 
>> However, (1) having a default would allow API designers to define public 
>> APIs with very little additional thought, and (2) it seems to me we're very 
>> very far from consensus on which default would be best. I'd like to avoid 
>> arguing even more about the theoretical merits of choosing open vs final vs 
>> dynamic by default. (Note that there are highly respectable app developers 
>> who honestly consider "open" much too restricting.)
>> 
>> 
>> 
>> I'm enthusiastic about sealed-by-default classes, but to be honest, I 
>> personally have no idea what default (if any) would be best for class 
>> members. Ask me again after I've worked with the new classes for a couple of 
>> months.
>> 
> This is what i find so unique about this situation: there is not 2 months to 
> decide, there is not a couple of implementations to compare.. there is here 
> and now to decide for the next 20 years, with zero experience with the api 
> and very little external references (which nobody seems to have sahed any 
> practical experience with) ... nonetheless it must all be fleshed out before 
> the 28th. I cincerely hope the core team is more prepared than they currently 
> let out.

It's going to be okay.  The ax is already at the root of the tree; We are just 
trying to make sure it falls safely. Once it is on the ground, we will make 
lumber and some firewood, then we will build a cabin with a nice porch. We will 
invite the neighbors to celebrate by making s'mores on the fire provided by the 
fallen tree.  So yeah, if you want s'mores you better get away from the falling 
tree; You should probably run when you hear it falling.  

> 
>> 
>> Karoly
>> 
>> @lorentey
>> 
>> 
>> 
>> On 2016-07-18 18:45:14 +, Nevin Brackett-Rozinsky via swift-evolution 
>> said:
>> 
>> 
>> 
>> Garth makes an excellent point. Károly is correct that we can already 
>> achieve “sealed” by making a `final` member call through to an `internal` 
>> one.
>> 
>> 
>> 
>> Therefore, it seem clear that “open” should only be applicable to classes, 
>> not to members. This should simplify the proposal nicely.
>> 
>> 
>> 
>> Nevin
>> 
>> 
>> 
>> 
>> 
>> On Mon, Jul 18, 2016 at 2:39 PM, Garth Snyder via swift-evolution 
>>  wrote:
>> 
>> > Károly wrote: I suggest we change the proposal to remove the implicit 
>> > "sealed" level of public member overridability, and support only "open" or 
>> > "final" class members. For members, "open" should mean the opposite of 
>> > "final", with no levels in between. Member-level openness should be 
>> > entirely independent of visibility; so it should be possible to say 
>> > "internal open" to mean an internally overridable member that's not at all 
>> > visible outside the module -- the same as today's default.
>> 
>> 
>> 
>> What is the distinction between this approach and simply omitting the 
>> ability to apply the “open” keyword to anything but a class?
>> 
>> 
>> 
>> The current behavior is (IIUC) that you cannot override a superclass’s final 
>> method. Aside from that, you can override any other method that’s visible to 
>> you, wherever you stand with regard to the superclass’s origin. If there’s 
>> no sealed status for members, why is any change to member annotations needed 
>> at all?
>> 
>> 
>> 
>> Garth
>> 
>> ___
>> 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