Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[L. Mihalkovic via swift-evolution]

> On Jun 15, 2016, at 3:57 AM, Jon Akhtar via swift-evolution 
>  wrote:
> 
> How about the goal of it being a delightful language to program in.

Historyprooves that goals are rarely enterely wrong... It is how they are 
carried out that more often is questionable.


> I think that is getting lost in proposals like these. Optimizing for some 
> mythical new user, who really isn’t present on this list to give an opinion 
> seems like a false argument to make, and your technical sophistication makes 
> you a less qualified than most to say what is and what isn’t confusing to new 
> users because you haven’t been one in a long time.

Now the problem with that is : do you design for day 1 or do you design for 
day-n (where n > bigEnoughToDoLot). I hope NEITHER, which makes hte complete 
beginer equally disqualified as I am then. Swift is here to stay for next 20 
years at least... it can't just be designed for the extremes, and the role of 
chris and team is to see past the knee-jerk reactions of newcomers to see how 
they can put mechanisms in place that will secure the future. 

> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There are 
> far more confusing aspects to the language than this.

But there are limited opportunity to hide great power behind simple looking 
constructs, and that is a fact, regardless of the number of users who can 
see/understand it. Objc thrived for 30 years because the apple world was very 
closed onto itself. Today arguably the most powerful language (richness of 
abstractions, universality) for writing appleOS apps is in the hands of 
microsoft. Maybe apple will settle for this situation, leaving people who feel 
limited by swift to switch to c#. But make no mistake, other languages will 
come (rust is already usable to make ios apps), and many of the people who are 
7 today and learning, will already feel limited 2 years from now if swift does 
not step up where it can.

> 
> Cheers
> 
> From:  on behalf of Xiaodi Wu via 
> swift-evolution 
> Reply-To: Xiaodi Wu 
> Date: Tuesday, June 14, 2016 at 13:50
> To: "L. Mihalkovic" , David Waite 
> 
> Cc: swift-evolution 
> Subject: Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops
> 
> Why are you unhappy about this design goal? Simple != simplistic, and 
> powerful != complicated. Approachability has to do with the slope of the 
> learning curve, not how high the curve goes.
> 
> 
>> On Tue, Jun 14, 2016 at 14:18 L. Mihalkovic  
>> wrote:
>> 
>> 
>> Regards
>> (From mobile)
>> 
>> On Jun 14, 2016, at 7:16 PM, David Waite via swift-evolution 
>>  wrote:
>> 
>>> I’m a bit late to this conversation, and I don’t totally understand the 
>>> goal.
>>> 
>>> There are a *lot* of things you can do in for…in loop with pattern matching 
>>> that also would supposedly go against this interpretation of 
>>> approachability. Pattern matching in general might be considered to go 
>>> against this interpretation.
>>> 
>>> Is this pitch saying statements such as:
>>> 
>>> for i in 1..<100 where i%2 == 1 {…} 
>>> 
>>> should be disallowed, while statements like
>>> 
>>> for case let view? in views { … }
>>> 
>>> are still approachable enough to warrant being supported in the language?
>>> 
>>> FWIW, I wouldn’t support removing where based on current arguments without 
>>> either the keyword “where" being eliminated completely from the language, 
>>> and/or adding equivalent intuitive functionality to Sequence with 
>>> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…). 
>>> 
>>> I’ve known about and used the feature since it was first added to Swift 
>>> (learned via the language book), and don’t fully understand the confusion 
>>> that some developers may have - especially since ‘while’ is already a 
>>> keyword and could have been used if that was the actual semantics.
>>> 
>>> -DW
>>> 
 On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution 
  wrote:
 
 And from the WWDC Platforms SOTU: "Swift is super simple and 
 approachable It's great as a first language. And in fact, we think 
 this is so important that when we designed Swift this was an explicit 
 design goal."
>> 
>> Yup... Doesn't bode well for power users... "Swift.. Address your needs from 
>> 7 till 77... unifies the entire family"
>> 
 I would be absolutely against adding any more sugar to the for loop. In 
 that sense, `where` sets a terrible example that certain features of 
 sequences deserve contextual sugar. (And before someone points it out 
 again, I've already argued why `for...in` holds its own weight, namely 
 difficulty of writing a correct `while` replacement and progressive 
 

Re: [swift-evolution] Access modifier blocks

[Charlie Monroe via swift-evolution]

Your approach has a major flaw: methods from extensions can't be overridden (at 
least for now). As long as you want to your controller to be subclassed and 
allow overriding your public/internal methods, you need to move them from 
extensions to the main class scope. Which simply sucks and may be fine for 
final classes (or classes that you don't plan on subclassing), but is in no way 
a good way to design a root class which is meant to be subclassed.

I am kind of on and off on this proposal - I like the way you can group vars 
together based on access control, but I'd leave it at that, not extending it to 
methodsm since it would introduce horizontal space issues (code starting at 
indentation level 4).

> On Jun 14, 2016, at 10:18 PM, David Hart  wrote:
> 
> I dont agree. I think extensions serve this purpose very well. Here is what I 
> do:
> 
> I start with the type declaration only containing properties (public or 
> private). I then create one extension per access level required and one per 
> protocol conformance and per superclass overrides. We get:
> 
> class MyViewController: UIViewController {
>public let publicProp: Int = 0
>@IBOutlet private var tableView: UITableView!
> }
> 
> //MARK: - Public
> public extension MyViewController {
>// Public functions
> }
> 
> //MARK: - UIViewController
> public extension MyViewController {
>override func viewDidLoad() {
>}
> }
> 
> //MARK: UITableViewDataSource
> extension MyViewController: UITableViewDataSource {
>override func numberOfSectionsInTableView(tableView: UITableView) {
>return 1
>}
> }
> 
> //MARK: Private
> private extension MyViewController {
>// Private functions
> }
> 
>> On 13 Jun 2016, at 01:14, Raphaël Wach via swift-evolution 
>>  wrote:
>> 
>> Yes, extensions serve a different purposes. It doesn’t seem right for me to 
>> just split every class content into 3 different extensions only to group 
>> together items with a similar access level.
>> It would just make the codebase of a framework more messy. Access modifier 
>> block allows to not break the structure of a class but make it more easy to 
>> organize, to write and to read which seems nice for our « write less, 
>> achieve more » new favorite language, Swift. :)
>> 
>> Raph
>> 
>> 
>> 
>>> Le 13 juin 2016 à 10:04, Charlie Monroe  a écrit 
>>> :
>>> 
>>> Extensions can't have stored properties.
>>> 
 On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution 
  wrote:
 
 What does this do that breaking a structure down into local extensions 
 with the appropriate level of access control doesn't?
 
 ~Robert Widmann
 
 2016/06/13 0:55、Raphaël Wach via swift-evolution 
  のメッセージ:
 
> Hello Swifters,
> 
> While working on some framework programming, I had this idea that I would 
> like to share with you.
> If some other people like it, I would be more than happy to write a 
> proposal.
> 
> Here is a little draft I wrote as a starting point to discuss.
> Sorry if there is mistakes, I am not an english native speaker.
> Thank you for your feedback.
> 
> 
> 
> Swift proposal: Access modifier blocks
> 
> This proposal introduces a refinement of the way to define access 
> modifier and visibility scope.
> 
> The current keywords private, internal and public are nice, simple to use 
> and makes sense. But, especially in the context of framework development, 
> it can quickly becomes messy and confusing to define the visibility for 
> each member variable, function or enum. Also it takes more time to write 
> and is not ideal to visualize the public interface of a class.
> 
> If a class A has only a few members, that’s ok to write 
> 
> class A {
> public var member1: Int
> var member2: Int
> private var member3: Int
> }
> 
> With a bigger class B, it will looks far less nice
> 
> class B {
> public var member1: Int
> var member2: Int
> private var member3: Int
> public var member4: Int
> var member5: Int
> private var member6: Int
> public var member7: Int
> var member8: Int
> private var member9: Int
> public var member10: Int
> private var member11: Int
> var member12: Int
> public var member13: Int
> var member14: Int
> private var member15: Int
> }
> 
> And now, it’s really messy, takes more time to write and we need to think 
> twice to visualize what could be the public interface of our framework.
> 
> The purpose of this proposal is to allow the definition of the access 
> modifiers for a block of declarations.
> Then our class B could be:
> 
> class B {
> // Ok then this is part of the public 

Re: [swift-evolution] Property with class and protocol type

[Adrian Zubarev via swift-evolution]

One more thing for clarity:

Any-class requirement: This must be the first requirement, if present. This 
requirement consists of the keyword class, and requires the existential to be 
of any class type.

Class requirement: This must be the first requirement, if present. This 
requirement consists of the name of a class type, and requires the existential 
to be of a specific class or its subclasses. There can be only one class name 
constraint, and it is mutually exclusive with the any-class requirement.

Nested any<...>: This requirement consists of another any<...> construct.



-- 
Adrian Zubarev
Sent with Airmail

Am 14. Juni 2016 um 23:42:00, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Which addresses the fact that nons of the proposals so far truly prevent 
absurde declarations like:

Let v: Any< UIViewController, UIWindow, UITableViewDelegate>
Let v: UIViewController & UIWindow & UITableViewDelegate
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Property with class and protocol type

[Adrian Zubarev via swift-evolution]

Not true, we already stated a clear rule how existentials should work with 
class-requirements long time ago (don’t mind lowercased any here):

Nested any<...>

A nested any<...> may declare a class or any-class constraint, even if its 
parent any<...> contains a class or any-class constraint, or a sibling any<...> 
constraint declares a class or any-class constraint. However, one of the 
classes must be a subclass of every other class declared within such 
constraints, or all the classes must be the same. This class, if it exists, is 
chosen as the any<...> construct’s constraint.

// Can be any type that is a UITableView conforming to ProtocolA.
// UITableView is the most specific class, and it is a subclass of the other
// two classes.
let a : any>>

// REDUNDANT: could be banned by another proposal.
// Identical to any
let b : any>

// NOT ALLOWED: no class is a subclass of all the other classes. This cannot be
// satisfied by any type.
let c : any>>
Using typealiases, it is possible for any<...> existentials to be composed. 
This allows API requirements to be expressed in a more natural, modular way:

// Any custom UIViewController that serves as a delegate for a table view.
typealias CustomTableViewController = any

// Pull in the previous typealias and add more refined constraints.
typealias PiedPiperResultsViewController = any
Any any<...> containing nested any<...>s can be conceptually ‘flattened’ and 
written as an equivalent any<...> containing no nested any<...> requirements. 
The two representations are exactly interchangeable.

That said, your example won’t work just because UIViewController and UIWindow 
are not compatible. The whole class-requirement is not based on the base types 
of all provided classes, but checked their own relationship instead.



-- 
Adrian Zubarev
Sent with Airmail

Am 14. Juni 2016 um 21:25:31, L. Mihalkovic (laurent.mihalko...@gmail.com) 
schrieb:

Which addresses the fact that nons of the proposals so far truly prevent 
absurde declarations like:

Let v: Any< UIViewController, UIWindow, UITableViewDelegate>
Let v: UIViewController & UIWindow & UITableViewDelegate
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Brent Royal-Gordon via swift-evolution]

> What about just this?
> for i % 2 == 0 in sequence { ... }
> 
> The first new identifier gets to be the index variable and subsequent new 
> identifiers are errors.

If that weren't a syntax error, I would expect it to loop over `[true, false, 
true, false, …]`.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Access modifier blocks

[Ross O'Brien via swift-evolution]

Your style may vary, but in my experience the access level of two functions
has very little effect on how they should be grouped.

Let's take an example: a class with two init functions. (If you want a
concrete example: a subclass of UIView has init(frame) and init(coder)).
While the inits take different arguments, they share a lot of
initialisation steps, so to avoid unnecessary duplication, we create a
private 'sharedInitialisation()' function which both init()s call once
they've set the class's values.

For readability's sake, in the Swift file, I write the two init() functions
one after the other, and then I write the sharedInitialisation() function
immediately below them. That way they're all on the screen simultaneously -
I don't need to click or scroll to the 'private extension' to understand
how this class is set up.

If the intent of this is to group functions together so that it's easier to
find only the ones which can be called from the internal/public levels,
then I think there are better ways. Xcode generates interface counterpart
files of Swift types which strip the type and its functions to just their
declarations.

Are there other advantages to segregating functions by access levels?

Ross

On Tue, Jun 14, 2016 at 9:21 PM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> And if you want to be able to declare properties in extensions, which I'm
> not a fan of, I think it would still be more a appropriate proposal than
> one that adds another way to group access modifiers.
>
> > On 14 Jun 2016, at 13:18, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I dont agree. I think extensions serve this purpose very well. Here is
> what I do:
> >
> > I start with the type declaration only containing properties (public or
> private). I then create one extension per access level required and one per
> protocol conformance and per superclass overrides. We get:
> >
> > class MyViewController: UIViewController {
> >public let publicProp: Int = 0
> >@IBOutlet private var tableView: UITableView!
> > }
> >
> > //MARK: - Public
> > public extension MyViewController {
> >// Public functions
> > }
> >
> > //MARK: - UIViewController
> > public extension MyViewController {
> >override func viewDidLoad() {
> >}
> > }
> >
> > //MARK: UITableViewDataSource
> > extension MyViewController: UITableViewDataSource {
> >override func numberOfSectionsInTableView(tableView: UITableView) {
> >return 1
> >}
> > }
> >
> > //MARK: Private
> > private extension MyViewController {
> >// Private functions
> > }
> >
> >> On 13 Jun 2016, at 01:14, Raphaël Wach via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Yes, extensions serve a different purposes. It doesn’t seem right for
> me to just split every class content into 3 different extensions only to
> group together items with a similar access level.
> >> It would just make the codebase of a framework more messy. Access
> modifier block allows to not break the structure of a class but make it
> more easy to organize, to write and to read which seems nice for our «
> write less, achieve more » new favorite language, Swift. :)
> >>
> >> Raph
> >>
> >>
> >>
> >>> Le 13 juin 2016 à 10:04, Charlie Monroe  a
> écrit :
> >>>
> >>> Extensions can't have stored properties.
> >>>
>  On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  What does this do that breaking a structure down into local
> extensions with the appropriate level of access control doesn't?
> 
>  ~Robert Widmann
> 
>  2016/06/13 0:55、Raphaël Wach via swift-evolution <
> swift-evolution@swift.org> のメッセージ:
> 
> > Hello Swifters,
> >
> > While working on some framework programming, I had this idea that I
> would like to share with you.
> > If some other people like it, I would be more than happy to write a
> proposal.
> >
> > Here is a little draft I wrote as a starting point to discuss.
> > Sorry if there is mistakes, I am not an english native speaker.
> > Thank you for your feedback.
> >
> > 
> >
> > Swift proposal: Access modifier blocks
> >
> > This proposal introduces a refinement of the way to define access
> modifier and visibility scope.
> >
> > The current keywords private, internal and public are nice, simple
> to use and makes sense. But, especially in the context of framework
> development, it can quickly becomes messy and confusing to define the
> visibility for each member variable, function or enum. Also it takes more
> time to write and is not ideal to visualize the public interface of a class.
> >
> > If a class A has only a few members, that’s ok to write
> >
> > class A {
> > public var member1: Int
> > var member2: Int
> > private var member3: Int
> > }
> 

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[David Sweeris via swift-evolution]

> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon > > wrote:
>> 
>>> Upon accepting SE-0099, the core team is removing `where` clauses from 
>>> condition clauses, writing "the 'where' keyword can be retired from its 
>>> purpose as a boolean condition introducer." 
>>> 
>>> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for 
>>> in` loops, where they are better expressed (and read) as guard conditions. 
>> 
>> Do you propose to remove `for case` as well? That can equally be handled by 
>> a `guard case` in the loop body.
>> 
>> Alternate proposal: Move `where` clauses to be adjacent to the 
>> pattern—rather than the sequence expression—in a `for` loop, just as they 
>> are in these other syntaxes.
>> 
>>  for n where n.isOdd in 1...1_000 { … }
>> 
>> This makes them more consistent with the syntax in `switch` cases and 
>> `catch` statements, while also IMHO clarifying the role of the `where` 
>> clause as a filter on the elements seen by the loop.
> 
> I saw your post on that *after* I finished sending this. Moving `where` next 
> to the pattern, like you'd find in `catch` and switch `case`, the code would 
> look like this:
> 
> for i where i % 2 == 0 in sequence {
> // do stuff
> }

What about just this?
for i % 2 == 0 in sequence { ... }

The first new identifier gets to be the index variable and subsequent new 
identifiers are errors.

- Dave Sweeris

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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Xiaodi Wu via swift-evolution]

Why are you unhappy about this design goal? Simple != simplistic, and
powerful != complicated. Approachability has to do with the slope of the
learning curve, not how high the curve goes.


On Tue, Jun 14, 2016 at 14:18 L. Mihalkovic 
wrote:

>
>
> Regards
> (From mobile)
>
> On Jun 14, 2016, at 7:16 PM, David Waite via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’m a bit late to this conversation, and I don’t totally understand the
> goal.
>
> There are a *lot* of things you can do in for…in loop with pattern
> matching that also would supposedly go against this interpretation of
> approachability. Pattern matching in general might be considered to go
> against this interpretation.
>
> Is this pitch saying statements such as:
>
> for i in 1..<100 where i%2 == 1 {…}
>
> should be disallowed, while statements like
>
> for case let view? in views { … }
>
> are still approachable enough to warrant being supported in the language?
>
> FWIW, I wouldn’t support removing where based on current arguments without
> either the keyword “where" being eliminated completely from the language,
> and/or adding equivalent intuitive functionality to Sequence with
> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>
> I’ve known about and used the feature since it was first added to Swift
> (learned via the language book), and don’t fully understand the confusion
> that some developers may have - especially since ‘while’ is already a
> keyword and could have been used if that was the actual semantics.
>
> -DW
>
> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> And from the WWDC Platforms SOTU: "Swift is super simple and
> approachable It's great as a first language. And in fact, we think this
> is so important that when we designed Swift this was an explicit design
> goal."
>
>
> Yup... Doesn't bode well for power users... "Swift.. Address your needs
> from 7 till 77... unifies the entire family"
>
> I would be absolutely against adding any more sugar to the for loop. In
> that sense, `where` sets a terrible example that certain features of
> sequences deserve contextual sugar. (And before someone points it out
> again, I've already argued why `for...in` holds its own weight, namely
> difficulty of writing a correct `while` replacement and progressive
> disclosure to the learner so that the concept of iterators can be learned
> afterwards.)
>
> In short, I would very much be opposed to adding keywords "for fun."
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 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] Access modifier blocks

[David Hart via swift-evolution]

And if you want to be able to declare properties in extensions, which I'm not a 
fan of, I think it would still be more a appropriate proposal than one that 
adds another way to group access modifiers.

> On 14 Jun 2016, at 13:18, David Hart via swift-evolution 
>  wrote:
> 
> I dont agree. I think extensions serve this purpose very well. Here is what I 
> do:
> 
> I start with the type declaration only containing properties (public or 
> private). I then create one extension per access level required and one per 
> protocol conformance and per superclass overrides. We get:
> 
> class MyViewController: UIViewController {
>public let publicProp: Int = 0
>@IBOutlet private var tableView: UITableView!
> }
> 
> //MARK: - Public
> public extension MyViewController {
>// Public functions
> }
> 
> //MARK: - UIViewController
> public extension MyViewController {
>override func viewDidLoad() {
>}
> }
> 
> //MARK: UITableViewDataSource
> extension MyViewController: UITableViewDataSource {
>override func numberOfSectionsInTableView(tableView: UITableView) {
>return 1
>}
> }
> 
> //MARK: Private
> private extension MyViewController {
>// Private functions
> }
> 
>> On 13 Jun 2016, at 01:14, Raphaël Wach via swift-evolution 
>>  wrote:
>> 
>> Yes, extensions serve a different purposes. It doesn’t seem right for me to 
>> just split every class content into 3 different extensions only to group 
>> together items with a similar access level.
>> It would just make the codebase of a framework more messy. Access modifier 
>> block allows to not break the structure of a class but make it more easy to 
>> organize, to write and to read which seems nice for our « write less, 
>> achieve more » new favorite language, Swift. :)
>> 
>> Raph
>> 
>> 
>> 
>>> Le 13 juin 2016 à 10:04, Charlie Monroe  a écrit 
>>> :
>>> 
>>> Extensions can't have stored properties.
>>> 
 On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution 
  wrote:
 
 What does this do that breaking a structure down into local extensions 
 with the appropriate level of access control doesn't?
 
 ~Robert Widmann
 
 2016/06/13 0:55、Raphaël Wach via swift-evolution 
  のメッセージ:
 
> Hello Swifters,
> 
> While working on some framework programming, I had this idea that I would 
> like to share with you.
> If some other people like it, I would be more than happy to write a 
> proposal.
> 
> Here is a little draft I wrote as a starting point to discuss.
> Sorry if there is mistakes, I am not an english native speaker.
> Thank you for your feedback.
> 
> 
> 
> Swift proposal: Access modifier blocks
> 
> This proposal introduces a refinement of the way to define access 
> modifier and visibility scope.
> 
> The current keywords private, internal and public are nice, simple to use 
> and makes sense. But, especially in the context of framework development, 
> it can quickly becomes messy and confusing to define the visibility for 
> each member variable, function or enum. Also it takes more time to write 
> and is not ideal to visualize the public interface of a class.
> 
> If a class A has only a few members, that’s ok to write 
> 
> class A {
> public var member1: Int
> var member2: Int
> private var member3: Int
> }
> 
> With a bigger class B, it will looks far less nice
> 
> class B {
> public var member1: Int
> var member2: Int
> private var member3: Int
> public var member4: Int
> var member5: Int
> private var member6: Int
> public var member7: Int
> var member8: Int
> private var member9: Int
> public var member10: Int
> private var member11: Int
> var member12: Int
> public var member13: Int
> var member14: Int
> private var member15: Int
> }
> 
> And now, it’s really messy, takes more time to write and we need to think 
> twice to visualize what could be the public interface of our framework.
> 
> The purpose of this proposal is to allow the definition of the access 
> modifiers for a block of declarations.
> Then our class B could be:
> 
> class B {
> // Ok then this is part of the public interface of my framework
> public { 
>var member1: Int
>var member4: Int
>var member7: Int
>var member10: Int
>var member13: Int
> }
> // This can be used anywhere in my framework
> internal {
>var member2: Int
>var member5: Int
>var member8: Int
>var member12: Int
>var member14: Int
> }
> // Here remains my private stuff. Don’t touch it ! Leave me alone ! My 
> preciouuusss

Re: [swift-evolution] Access modifier blocks

[David Hart via swift-evolution]

I dont agree. I think extensions serve this purpose very well. Here is what I 
do:

I start with the type declaration only containing properties (public or 
private). I then create one extension per access level required and one per 
protocol conformance and per superclass overrides. We get:

class MyViewController: UIViewController {
public let publicProp: Int = 0
@IBOutlet private var tableView: UITableView!
}

//MARK: - Public
public extension MyViewController {
// Public functions
}

//MARK: - UIViewController
public extension MyViewController {
override func viewDidLoad() {
}
}

//MARK: UITableViewDataSource
extension MyViewController: UITableViewDataSource {
override func numberOfSectionsInTableView(tableView: UITableView) {
return 1
}
}

//MARK: Private
private extension MyViewController {
// Private functions
}

> On 13 Jun 2016, at 01:14, Raphaël Wach via swift-evolution 
>  wrote:
> 
> Yes, extensions serve a different purposes. It doesn’t seem right for me to 
> just split every class content into 3 different extensions only to group 
> together items with a similar access level.
> It would just make the codebase of a framework more messy. Access modifier 
> block allows to not break the structure of a class but make it more easy to 
> organize, to write and to read which seems nice for our « write less, achieve 
> more » new favorite language, Swift. :)
> 
> Raph
> 
> 
> 
>> Le 13 juin 2016 à 10:04, Charlie Monroe  a écrit :
>> 
>> Extensions can't have stored properties.
>> 
>>> On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution 
>>>  wrote:
>>> 
>>> What does this do that breaking a structure down into local extensions with 
>>> the appropriate level of access control doesn't?
>>> 
>>> ~Robert Widmann
>>> 
>>> 2016/06/13 0:55、Raphaël Wach via swift-evolution 
>>>  のメッセージ:
>>> 
 Hello Swifters,
 
 While working on some framework programming, I had this idea that I would 
 like to share with you.
 If some other people like it, I would be more than happy to write a 
 proposal.
 
 Here is a little draft I wrote as a starting point to discuss.
 Sorry if there is mistakes, I am not an english native speaker.
 Thank you for your feedback.
 
 
 
 Swift proposal: Access modifier blocks
 
 This proposal introduces a refinement of the way to define access modifier 
 and visibility scope.
 
 The current keywords private, internal and public are nice, simple to use 
 and makes sense. But, especially in the context of framework development, 
 it can quickly becomes messy and confusing to define the visibility for 
 each member variable, function or enum. Also it takes more time to write 
 and is not ideal to visualize the public interface of a class.
 
 If a class A has only a few members, that’s ok to write 
 
 class A {
 public var member1: Int
 var member2: Int
 private var member3: Int
 }
 
 With a bigger class B, it will looks far less nice
 
 class B {
 public var member1: Int
 var member2: Int
 private var member3: Int
 public var member4: Int
 var member5: Int
 private var member6: Int
 public var member7: Int
 var member8: Int
 private var member9: Int
 public var member10: Int
 private var member11: Int
 var member12: Int
 public var member13: Int
 var member14: Int
 private var member15: Int
 }
 
 And now, it’s really messy, takes more time to write and we need to think 
 twice to visualize what could be the public interface of our framework.
 
 The purpose of this proposal is to allow the definition of the access 
 modifiers for a block of declarations.
 Then our class B could be:
 
 class B {
 // Ok then this is part of the public interface of my framework
 public { 
 var member1: Int
 var member4: Int
 var member7: Int
 var member10: Int
 var member13: Int
 }
 // This can be used anywhere in my framework
 internal {
 var member2: Int
 var member5: Int
 var member8: Int
 var member12: Int
 var member14: Int
 }
 // Here remains my private stuff. Don’t touch it ! Leave me alone ! My 
 preciouuusss
 private {
 var member3: Int
 var member6: Int
 var member9: Int
 var member11: Int
 var member15: Int
 }
 }
 
 It increases readability, avoid to write many times the same keywords, 
 which is quiet boring, and helps visualizing the architecture of the 
 framework by highlighting what can create a dependency with other classes 
 inside the framework and with code outside of the framework.

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

[John McCall via swift-evolution]

> On Jun 12, 2016, at 9:08 PM, Charlie Monroe  wrote:
>> On Jun 11, 2016, at 3:51 AM, Andrew Bennett via swift-evolution 
>> > wrote:
>> 
>> Unavailable doesn't mean un-callable.
>> If you're marking an override or required initialiser as unavailable, it's 
>> still possible it's called dynamically, or by super.
>> If you're marking it unavailable for some OS versions, it could still be 
>> called by the other OS versions.
>> If it's neither of those two categories, you probably don't even need the 
>> function declaration.
>> It's not clear what default behaviour you would want in an unavailable 
>> method, calling super, calling a new method, a runtime error, ...
>> 
>> An undefined implementation lacks clarity, as Erica says, "this is an 
>> example where concision is overrated".
>> 
>> Likewise, as Brent says, you may want the old unavailable API to call 
>> through to the new API.  A new version of a library may be dynamically 
>> linked by something compiled against an older version.

> As Andrew says - I have several cases where I mark a method on a subclass as 
> unavailable to ensure subclasses do not call it directly, but it is required 
> by the root class to be implemented (which it is and gets called).
> 
> Example:
> 
> class Root {
>   func doSomething() {
>   print("Root")
>   }
> }
> 
> class Subclass {
>   @available(*, unavailable)
>   override func doSomething() {
>   super.doSomething()
>   print("Subclass")
>   }   
> }
> 
> And you can still do:
> 
> let instance: Root = Subclass()
> instance.doSomething()
> 
> and it will call Root Subclass.
> 
> If it's renamed, you should really first deprecate it and just call the new 
> API and after a while make it unavailable with no change in the code.
> 
> If it's meant for abstract classes, then it's kind of a different issue.

In many of the cases you guys are describing, we ought to have enough 
information to do the right thing.  For example, library evolution shouldn't be 
done with an ordinary unavailable attribute; it should use something that 
indicates that the API was added in v2.6c, deprecated in v2.7, and made illegal 
in v2.8.  With that information, we clearly would still require a function body 
if the build configuration says that we need to support pre-v2.8 clients.

My point was just that there is a clear use case for an attribute that says 
"don't allow this declaration to be used at all", including indirectly such as 
via a protocol requirement or overridden method, and those use cases should not 
require an actual function body.  I recognize that there are also use cases for 
a more relaxed attribute that just prohibits direct uses but still requires a 
function body.  Perhaps that should just be a completely different attribute, 
or perhaps we can differentiate based on the attribute arguments, or perhaps we 
can address all of those use cases with targeted language features.  However, 
we should still get to a point where we don't require function bodies for the 
true-unavailable cases.

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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 14, 2016, at 7:16 PM, David Waite via swift-evolution 
>  wrote:
> 
> I’m a bit late to this conversation, and I don’t totally understand the goal.
> 
> There are a *lot* of things you can do in for…in loop with pattern matching 
> that also would supposedly go against this interpretation of approachability. 
> Pattern matching in general might be considered to go against this 
> interpretation.
> 
> Is this pitch saying statements such as:
> 
>   for i in 1..<100 where i%2 == 1 {…} 
> 
> should be disallowed, while statements like
> 
>   for case let view? in views { … }
> 
> are still approachable enough to warrant being supported in the language?
> 
> FWIW, I wouldn’t support removing where based on current arguments without 
> either the keyword “where" being eliminated completely from the language, 
> and/or adding equivalent intuitive functionality to Sequence with same-class 
> performance, e.g. a .where(...) equivalent to .lazy.filter(…). 
> 
> I’ve known about and used the feature since it was first added to Swift 
> (learned via the language book), and don’t fully understand the confusion 
> that some developers may have - especially since ‘while’ is already a keyword 
> and could have been used if that was the actual semantics.
> 
> -DW
> 
>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> And from the WWDC Platforms SOTU: "Swift is super simple and 
>> approachable It's great as a first language. And in fact, we think this 
>> is so important that when we designed Swift this was an explicit design 
>> goal."

Yup... Doesn't bode well for power users... "Swift.. Address your needs from 7 
till 77... unifies the entire family"

>> I would be absolutely against adding any more sugar to the for loop. In that 
>> sense, `where` sets a terrible example that certain features of sequences 
>> deserve contextual sugar. (And before someone points it out again, I've 
>> already argued why `for...in` holds its own weight, namely difficulty of 
>> writing a correct `while` replacement and progressive disclosure to the 
>> learner so that the concept of iterators can be learned afterwards.)
>> 
>> In short, I would very much be opposed to adding keywords "for fun."
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 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] Retiring `where` from for-in loops

[Xiaodi Wu via swift-evolution]

We're going in circles again. I addressed this with relation to `guard`,
and I would reply in the same way about `for case`:

The fact is that there are even experienced users of Swift who see `where`
and affirmatively believe it does what it does not do. The same cannot be
said for `for case`. That is, a user might say, 'What in the world does for
case mean?', but even a totally new user is unlikely to say, 'I can guess
what for case means, and it means [something that for case does not in fact
mean].'

On Tue, Jun 14, 2016 at 12:55 Ryan Lovelett via swift-evolution <
swift-evolution@swift.org> wrote:

> On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote:
>
> On Tue, Jun 14, 2016 at 12:16 PM, David Waite <
> da...@alkaline-solutions.com> wrote:
>
> I’m a bit late to this conversation, and I don’t totally understand the
> goal.
>
> There are a *lot* of things you can do in for…in loop with pattern
> matching that also would supposedly go against this interpretation of
> approachability. Pattern matching in general might be considered to go
> against this interpretation.
>
> Is this pitch saying statements such as:
>
> for i in 1..<100 where i%2 == 1 {…}
>
> should be disallowed, while statements like
>
> for case let view? in views { … }
>
> are still approachable enough to warrant being supported in the language?
>
>
> Language design has to weigh many factors simultaneously, I think you'd
> agree. The argument, essentially, is that `where` is not approachable *for
> the functionality that it provides* (namely, as an alternative for a
> trivial `guard...continue` statement). Pattern matching is daunting no
> doubt, but it offers functionality not conducive to much simpler syntax.
> (Or could it be much simpler? If so, then I would support a proposal to
> that effect.)
>
> Put simply, `where` is a less-than-straightforward expression of a very
> straightforward concept (filtering an array), whereas pattern matching is
> an advanced concept with a commensurately difficult syntax. Others have
> brought up generics, for example, but again that's an advanced *concept*;
> filtering an array is not.
>
>
> So you do not see that for case syntax as "a less-than-straightforward
> expression of a very straightforward concept (filtering an array)"?
>
> That's strange to me. Seems like that would be the _poster_ child for such
> a syntax.
>
> enum Things {
>   case One
>   case Two
>   case Three
>   case Four
> }
>
> let things: [Things] = [.One, .Two, .One, .Three, .Four, .One]
> for case .One in things {
>   print("Found a .One")
> }
>
> That code prints "Found a .One" three times. If the `where` syntax is
> non-obvious with regard to `continue` or `break` then surely _that_ code is
> down right opaque!
>
>
>
>
>
> FWIW, I wouldn’t support removing where based on current arguments without
> either the keyword “where" being eliminated completely from the language,
> and/or adding equivalent intuitive functionality to Sequence with
> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>
>
>
>
> I feel bad sending clearly passionate people over to crush another
> conversation, but I think you'll find in the Swift repository the
> beginnings of some explorations by a certain member of the core team to
> rename `.filter()` to `.where()` :D
>
> As to whether certain methods should be lazy or eager by default, that's a
> discussion certainly appropriate for this list.
>
>
> I’ve known about and used the feature since it was first added to Swift
> (learned via the language book), and don’t fully understand the confusion
> that some developers may have - especially since ‘while’ is already a
> keyword and could have been used if that was the actual semantics.
>
>
> One source of confusion was that `while...where` was supported and had
> breaking semantics. Now that's gone with SE-0099. Still, the point is that
> `where` is favored by some *because* you don't have to write explicitly
> what happens when something doesn't pass the filter, whereas the
> counterpoint argument is that not writing explicitly what happens when a
> rejected element is encountered *is* the very source of confusion.
>
>
>
>
> -DW
>
>
>
> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> And from the WWDC Platforms SOTU: "Swift is super simple and
> approachable It's great as a first language. And in fact, we think this
> is so important that when we designed Swift this was an explicit design
> goal."
>
> I would be absolutely against adding any more sugar to the for loop. In
> that sense, `where` sets a terrible example that certain features of
> sequences deserve contextual sugar. (And before someone points it out
> again, I've already argued why `for...in` holds its own weight, namely
> difficulty of writing a correct `while` replacement and progressive
> disclosure to the learner so that the concept of iterators can be learned
> afterwards.)
>
> In 

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Ryan Lovelett via swift-evolution]

On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote:
> On Tue, Jun 14, 2016 at 12:16 PM, David Waite  solutions.com> wrote:
>> I’m a bit late to this conversation, and I don’t totally understand
>> the goal.
>>
>> There are a *lot* of things you can do in for…in loop with pattern
>> matching that also would supposedly go against this interpretation of
>> approachability. Pattern matching in general might be considered to
>> go against this interpretation.
>>
>> Is this pitch saying statements such as:
>>
>> for i in 1..<100 where i%2 == 1 {…}
>>
>> should be disallowed, while statements like
>>
>> for case let view? in views { … }
>>
>> are still approachable enough to warrant being supported in the
>> language?
>
> Language design has to weigh many factors simultaneously, I think
> you'd agree. The argument, essentially, is that `where` is not
> approachable *for the functionality that it provides* (namely, as an
> alternative for a trivial `guard...continue` statement). Pattern
> matching is daunting no doubt, but it offers functionality not
> conducive to much simpler syntax. (Or could it be much simpler? If so,
> then I would support a proposal to that effect.)
>
> Put simply, `where` is a less-than-straightforward expression of a
> very straightforward concept (filtering an array), whereas pattern
> matching is an advanced concept with a commensurately difficult
> syntax. Others have brought up generics, for example, but again that's
> an advanced *concept*; filtering an array is not.
 
So you do not see that for case syntax as "a less-than-straightforward
expression of a very straightforward concept (filtering an array)"?
 
That's strange to me. Seems like that would be the _poster_ child for
such a syntax.
 
enum Things {
case One
case Two
case Three
case Four
}
 
let things: [Things] = [.One, .Two, .One, .Three, .Four, .One]
for case .One in things {
print("Found a .One")
}
 
That code prints "Found a .One" three times. If the `where` syntax is
non-obvious with regard to `continue` or `break` then surely _that_ code
is down right opaque!
 
>
>>
>> FWIW, I wouldn’t support removing where based on current arguments
>> without either the keyword “where" being eliminated completely from
>> the language, and/or adding equivalent intuitive functionality to
>> Sequence with same-class performance, e.g. a .where(...) equivalent
>> to .lazy.filter(…).
>>
>>
>
> I feel bad sending clearly passionate people over to crush another
> conversation, but I think you'll find in the Swift repository the
> beginnings of some explorations by a certain member of the core team
> to rename `.filter()` to `.where()` :D
>
> As to whether certain methods should be lazy or eager by default,
> that's a discussion certainly appropriate for this list.
>
>> I’ve known about and used the feature since it was first added to
>> Swift (learned via the language book), and don’t fully understand the
>> confusion that some developers may have - especially since ‘while’ is
>> already a keyword and could have been used if that was the actual
>> semantics.
>
> One source of confusion was that `while...where` was supported and had
> breaking semantics. Now that's gone with SE-0099. Still, the point is
> that `where` is favored by some *because* you don't have to write
> explicitly what happens when something doesn't pass the filter,
> whereas the counterpoint argument is that not writing explicitly what
> happens when a rejected element is encountered *is* the very source of
> confusion.
>
>>
>>
>> -DW
>>
>>
>>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> And from the WWDC Platforms SOTU: "Swift is super simple and
>>> approachable It's great as a first language. And in fact, we
>>> think this is so important that when we designed Swift this was an
>>> explicit design goal."
>>>
>>> I would be absolutely against adding any more sugar to the for loop.
>>> In that sense, `where` sets a terrible example that certain features
>>> of sequences deserve contextual sugar. (And before someone points it
>>> out again, I've already argued why `for...in` holds its own weight,
>>> namely difficulty of writing a correct `while` replacement and
>>> progressive disclosure to the learner so that the concept of
>>> iterators can be learned afterwards.)
>>>
>>> In short, I would very much be opposed to adding keywords "for fun."
>>
>>
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> 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] Retiring `where` from for-in loops

[Xiaodi Wu via swift-evolution]

On Tue, Jun 14, 2016 at 12:37 PM, Xiaodi Wu  wrote:

> On Tue, Jun 14, 2016 at 12:16 PM, David Waite <
> da...@alkaline-solutions.com> wrote:
>
>> I’m a bit late to this conversation, and I don’t totally understand the
>> goal.
>>
>> There are a *lot* of things you can do in for…in loop with pattern
>> matching that also would supposedly go against this interpretation of
>> approachability. Pattern matching in general might be considered to go
>> against this interpretation.
>>
>> Is this pitch saying statements such as:
>>
>> for i in 1..<100 where i%2 == 1 {…}
>>
>> should be disallowed, while statements like
>>
>> for case let view? in views { … }
>>
>> are still approachable enough to warrant being supported in the language?
>>
>
> Language design has to weigh many factors simultaneously, I think you'd
> agree. The argument, essentially, is that `where` is not approachable *for
> the functionality that it provides* (namely, as an alternative for a
> trivial `guard...continue` statement). Pattern matching is daunting no
> doubt, but it offers functionality not conducive to much simpler syntax.
> (Or could it be much simpler? If so, then I would support a proposal to
> that effect.)
>
> Put simply, `where` is a less-than-straightforward expression of a very
> straightforward concept (filtering an array), whereas pattern matching is
> an advanced concept with a commensurately difficult syntax. Others have
> brought up generics, for example, but again that's an advanced *concept*;
> filtering an array is not.
>
>
>>
>> FWIW, I wouldn’t support removing where based on current arguments
>> without either the keyword “where" being eliminated completely from the
>> language
>>
>
I should add, if this proposal is adopted along with the enclosed
suggestion to replace `where` with `if` in `case` and `catch`, the `where`
keyword would be completely eliminated except in the context of generics.
If the enclosed suggestion is not adopted here, alternatives will follow on
shortly.


> and/or adding equivalent intuitive functionality to Sequence with
>> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>>
>>
> I feel bad sending clearly passionate people over to crush another
> conversation, but I think you'll find in the Swift repository the
> beginnings of some explorations by a certain member of the core team to
> rename `.filter()` to `.where()` :D
>
> As to whether certain methods should be lazy or eager by default, that's a
> discussion certainly appropriate for this list.
>
>
>> I’ve known about and used the feature since it was first added to Swift
>> (learned via the language book), and don’t fully understand the confusion
>> that some developers may have - especially since ‘while’ is already a
>> keyword and could have been used if that was the actual semantics.
>>
>
> One source of confusion was that `while...where` was supported and had
> breaking semantics. Now that's gone with SE-0099. Still, the point is that
> `where` is favored by some *because* you don't have to write explicitly
> what happens when something doesn't pass the filter, whereas the
> counterpoint argument is that not writing explicitly what happens when a
> rejected element is encountered *is* the very source of confusion.
>
>
>>
>> -DW
>>
>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> And from the WWDC Platforms SOTU: "Swift is super simple and
>> approachable It's great as a first language. And in fact, we think this
>> is so important that when we designed Swift this was an explicit design
>> goal."
>>
>> I would be absolutely against adding any more sugar to the for loop. In
>> that sense, `where` sets a terrible example that certain features of
>> sequences deserve contextual sugar. (And before someone points it out
>> again, I've already argued why `for...in` holds its own weight, namely
>> difficulty of writing a correct `while` replacement and progressive
>> disclosure to the learner so that the concept of iterators can be learned
>> afterwards.)
>>
>> In short, I would very much be opposed to adding keywords "for fun."
>>
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Xiaodi Wu via swift-evolution]

On Tue, Jun 14, 2016 at 12:16 PM, David Waite 
wrote:

> I’m a bit late to this conversation, and I don’t totally understand the
> goal.
>
> There are a *lot* of things you can do in for…in loop with pattern
> matching that also would supposedly go against this interpretation of
> approachability. Pattern matching in general might be considered to go
> against this interpretation.
>
> Is this pitch saying statements such as:
>
> for i in 1..<100 where i%2 == 1 {…}
>
> should be disallowed, while statements like
>
> for case let view? in views { … }
>
> are still approachable enough to warrant being supported in the language?
>

Language design has to weigh many factors simultaneously, I think you'd
agree. The argument, essentially, is that `where` is not approachable *for
the functionality that it provides* (namely, as an alternative for a
trivial `guard...continue` statement). Pattern matching is daunting no
doubt, but it offers functionality not conducive to much simpler syntax.
(Or could it be much simpler? If so, then I would support a proposal to
that effect.)

Put simply, `where` is a less-than-straightforward expression of a very
straightforward concept (filtering an array), whereas pattern matching is
an advanced concept with a commensurately difficult syntax. Others have
brought up generics, for example, but again that's an advanced *concept*;
filtering an array is not.


>
> FWIW, I wouldn’t support removing where based on current arguments without
> either the keyword “where" being eliminated completely from the language,
> and/or adding equivalent intuitive functionality to Sequence with
> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>
>
I feel bad sending clearly passionate people over to crush another
conversation, but I think you'll find in the Swift repository the
beginnings of some explorations by a certain member of the core team to
rename `.filter()` to `.where()` :D

As to whether certain methods should be lazy or eager by default, that's a
discussion certainly appropriate for this list.


> I’ve known about and used the feature since it was first added to Swift
> (learned via the language book), and don’t fully understand the confusion
> that some developers may have - especially since ‘while’ is already a
> keyword and could have been used if that was the actual semantics.
>

One source of confusion was that `while...where` was supported and had
breaking semantics. Now that's gone with SE-0099. Still, the point is that
`where` is favored by some *because* you don't have to write explicitly
what happens when something doesn't pass the filter, whereas the
counterpoint argument is that not writing explicitly what happens when a
rejected element is encountered *is* the very source of confusion.


>
> -DW
>
> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> And from the WWDC Platforms SOTU: "Swift is super simple and
> approachable It's great as a first language. And in fact, we think this
> is so important that when we designed Swift this was an explicit design
> goal."
>
> I would be absolutely against adding any more sugar to the for loop. In
> that sense, `where` sets a terrible example that certain features of
> sequences deserve contextual sugar. (And before someone points it out
> again, I've already argued why `for...in` holds its own weight, namely
> difficulty of writing a correct `while` replacement and progressive
> disclosure to the learner so that the concept of iterators can be learned
> afterwards.)
>
> In short, I would very much be opposed to adding keywords "for fun."
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[David Waite via swift-evolution]

I’m a bit late to this conversation, and I don’t totally understand the goal.

There are a *lot* of things you can do in for…in loop with pattern matching 
that also would supposedly go against this interpretation of approachability. 
Pattern matching in general might be considered to go against this 
interpretation.

Is this pitch saying statements such as:

for i in 1..<100 where i%2 == 1 {…} 

should be disallowed, while statements like

for case let view? in views { … }

are still approachable enough to warrant being supported in the language?

FWIW, I wouldn’t support removing where based on current arguments without 
either the keyword “where" being eliminated completely from the language, 
and/or adding equivalent intuitive functionality to Sequence with same-class 
performance, e.g. a .where(...) equivalent to .lazy.filter(…). 

I’ve known about and used the feature since it was first added to Swift 
(learned via the language book), and don’t fully understand the confusion that 
some developers may have - especially since ‘while’ is already a keyword and 
could have been used if that was the actual semantics.

-DW

> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> And from the WWDC Platforms SOTU: "Swift is super simple and approachable 
> It's great as a first language. And in fact, we think this is so important 
> that when we designed Swift this was an explicit design goal."
> 
> I would be absolutely against adding any more sugar to the for loop. In that 
> sense, `where` sets a terrible example that certain features of sequences 
> deserve contextual sugar. (And before someone points it out again, I've 
> already argued why `for...in` holds its own weight, namely difficulty of 
> writing a correct `while` replacement and progressive disclosure to the 
> learner so that the concept of iterators can be learned afterwards.)
> 
> In short, I would very much be opposed to adding keywords "for fun."

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

[swift-evolution] Property with class and protocol type

[Adrian Śliwa via swift-evolution]

Hi all,

In Obj-C we have:

@property UIViewController *viewController;

Is there any reason we don't have in Swift:

var viewController: UViewController

Do you think it will be nice feature to have in Swift?
One example I have is is to have VC's container with view controllers(some
forms) which implement Validable protocol to enforce them to have
implementation of this method and to prevent situation that there is
somewhere default implementation of the method "isValid" e.g. in superclass
or protocol extension.
What are your thoughts?

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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Xiaodi Wu via swift-evolution]

And from the WWDC Platforms SOTU: "Swift is super simple and
approachable It's great as a first language. And in fact, we think this
is so important that when we designed Swift this was an explicit design
goal."

I would be absolutely against adding any more sugar to the for loop. In
that sense, `where` sets a terrible example that certain features of
sequences deserve contextual sugar. (And before someone points it out
again, I've already argued why `for...in` holds its own weight, namely
difficulty of writing a correct `while` replacement and progressive
disclosure to the learner so that the concept of iterators can be learned
afterwards.)

In short, I would very much be opposed to adding keywords "for fun."

On Tue, Jun 14, 2016 at 11:18 AM Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> FWIW I don't think we need all "4", just like we don't need `unless` as a
> pair to current `if` or `until` as a pair for current `while` loop.
>
> I.e. we have "continue" with current `where`, and you can use boolean
> inversion `!`. As for "break"(while) - my opinion the for-in loop will be
> more powerful and adds fun for coding (from wwdc keynote - "Swift is a
> powerful language.. writing Swift code is *fun*..." my opinion: using
> guard-continue or guard-break is *not* fun ).
>
> So in your words, it is better add *one* then remove *one*.
>
> The only question I'm not sure about if we should keep 'where' and 'while'
> keywords for these features, or rename them. For me it's OK to have 'where'
> and 'while' but probably I'll support another more clear keywords.
>
> On 14.06.2016 18:01, Erica Sadun via swift-evolution wrote:
> >
> >> On Jun 14, 2016, at 7:50 AM, plx via swift-evolution <
> swift-evolution@swift.org> wrote:
> >> For those particular keywords, I’d prefer having them (or equivalents).
> I’m not sure if I’d prefer having *all* of them—`where/unless` and
> `while/until`—or just one from each “pair”…I could go either way.
> >
> > In the proposal, my recommendations for including all 4 are:
> >
> > break: while / until
> > continue: if (formerly `where`) / unless
> >
> > As the thread has had sufficient redundancy, I'll refrain from making my
> case again for why I think it's better to remove the one than add the three.
> >
> > -- E
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Vladimir.S via swift-evolution]

FWIW I don't think we need all "4", just like we don't need `unless` as a 
pair to current `if` or `until` as a pair for current `while` loop.


I.e. we have "continue" with current `where`, and you can use boolean 
inversion `!`. As for "break"(while) - my opinion the for-in loop will be 
more powerful and adds fun for coding (from wwdc keynote - "Swift is a 
powerful language.. writing Swift code is *fun*..." my opinion: using 
guard-continue or guard-break is *not* fun ).


So in your words, it is better add *one* then remove *one*.

The only question I'm not sure about if we should keep 'where' and 'while' 
keywords for these features, or rename them. For me it's OK to have 'where' 
and 'while' but probably I'll support another more clear keywords.


On 14.06.2016 18:01, Erica Sadun via swift-evolution wrote:



On Jun 14, 2016, at 7:50 AM, plx via swift-evolution 
 wrote:
For those particular keywords, I’d prefer having them (or equivalents). I’m not 
sure if I’d prefer having *all* of them—`where/unless` and `while/until`—or 
just one from each “pair”…I could go either way.


In the proposal, my recommendations for including all 4 are:

break: while / until
continue: if (formerly `where`) / unless

As the thread has had sufficient redundancy, I'll refrain from making my case 
again for why I think it's better to remove the one than add the three.

-- E


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


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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Xiaodi Wu via swift-evolution]

The equivalent in Swift would be .filter(), and you're free to use it if
you prefer to express yourself that way.

Notice how these are almost never paired with loops. It's like mixing
chocolate and steak.

On Tue, Jun 14, 2016 at 8:50 AM plx via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I am 100% with Charlie on this. Expressiveness has to do with the
> *effectiveness* of conveying a thought or a feeling.
> >>
> >> Keep "where". It is expressive. It conveys a specific idea effectively
> and concisely.
> >
> > For those of you in favor of retaining `where`, how do you feel about
> adding `while`, `until`, `unless`, etc?
>
> In the interest of advancing the “what kind of language would I prefer
> swift become?”, here are my final thoughts on this topic:
>
> For those particular keywords, I’d prefer having them (or equivalents).
> I’m not sure if I’d prefer having *all* of them—`where/unless` and
> `while/until`—or just one from each “pair”…I could go either way.
>
> As a general consideration, I’d be in favor of having them b/c I’d really
> like Swift to have a comprehension-style construct (and associated syntax
> etc.).
>
> Comprehension syntax is IMHO pretty common outside the C family—within the
> C family really only C# has something like it—and in general comprehension
> syntax has pretty similar structure from language to language. This link
> illustrates the syntax for 28 languages’  comprehension constructs, so it
> isn’t a bad overview:
>
>
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)
>
> …(note that “comprehension syntax” isn’t quite the same thing as “list
> comprehensions”, but for “comparative syntax” purposes that link should be
> sufficient).
>
> For me the appeal of “comprehension syntax” is that it allows writing code
> that feels more “semantic” than “mechanical”, and that paraphrases much
> closer to the intended meaning.
>
> Here’s a toy example:
>
>   // with a comprehension-like syntax
>   // outside loop: “what items do we care about?"
>   for visitor in queue where visitor.hasTicket until venue.isFull {
> // inside loop: “…and what do we do with them?"
> venue.admit(visitor)
>   }
>
> …which to my eyes paraphrases more-or-less how I’d describe what we’re
> doing:
>
> - “keep admitting visitors with tickets until the venue is full”
>
> …whereas without it, you get something like this:
>
>   // without comprehension-style syntax
>   // outside loop: where, mechanically, are we sourcing items from
>   for visitor in queue {
> // inside loop: muddled mix of filtering, app logic, and flow-control
> // filtering:
> guard visitor.hasTicket else { continue }
> // app logic:
> venue.admit(visitor)
> // flow-control:
> if venue.isFull { break }
>   }
>
> …which *is* closer to the underlying mechanics, but paraphrases more like
> something you'd see in a badly-translated 80s VCR programing manual:
>
> - “Start considering visitors. If the visitor doesn't have a ticket, move
> on to the next visitor. Otherwise, admit the visitor. If the venue is full,
> stop considering visitors.”
>
> Sure, they’re both equivalent—and even in the 80s, some people managed to
> program their VCRs!—but given the option I’d strongly prefer to write in
> the first style; I like having a clean segregation between “what items are
> of interest?” and “what do we do with them?”
>
> So that’s what I like about comprehension-like constructs.
>
> The current `for-in-where` is a bit of an anomaly; it could be grown into
> something a little richer—`for _ in _ where _ while _`  and/or `for _ in _
> where _ until _` (etc.).—or it could be dropped and some better construct
> proposed.
>
> But, my personal preference would be to keep it around until either the
> richer construct is available or definitively declared as “not swift-y, not
> happening”:
>
> - if a “comprehension” construct is approved, an automatic migrator would
> likely do a *much* better job translating those `for _ in _ where` loops
> than it’d do with their more-imperative equivalents
> - if a “comprehension” construct is definitively-rejected, at least I can
> keep using something I like until the hammer drops
>
> >
> > -- E
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Default Closure Arguments

[T.J. Usiyan via swift-evolution]

What would this help you express? It is fairly difficult to read the type
and understand your motivation from this reduced example. It is clear what
you want but not what it wins you or us.

On Tue, Jun 14, 2016 at 3:40 AM, Andrew Bennett via swift-evolution <
swift-evolution@swift.org> wrote:

> I'd like to be able to do this:
>
> func callSomething(callback: (test: (arg: Int = 4) -> Void) -> Void) {
>
>   callback(test: { print($0) })
>
> }
>
>
> callSomething { test in
>
>   test()
>
> }
>
>
>
> Ideally the default argument would be part of the closure's type signature.
>
> If-not then it could be part of callSomething's signature, and it could
> lose the defaulted arguments if passed around.
>
> What do you think?
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Erica Sadun via swift-evolution]

> On Jun 14, 2016, at 7:50 AM, plx via swift-evolution 
>  wrote:
> For those particular keywords, I’d prefer having them (or equivalents). I’m 
> not sure if I’d prefer having *all* of them—`where/unless` and 
> `while/until`—or just one from each “pair”…I could go either way.

In the proposal, my recommendations for including all 4 are:

break: while / until
continue: if (formerly `where`) / unless

As the thread has had sufficient redundancy, I'll refrain from making my case 
again for why I think it's better to remove the one than add the three.

-- E


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

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

[L. Mihalkovic via swift-evolution]

> On Jun 14, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to me, 
> because it has knock on effects of making other things more complicated. But 
> I do see how for the most simple case of unwrapping a single Optional, it 
> makes sense.
> 
> As much as I would like Brent’s proposal to make things easier to type, I 
> think nesting things inside a tuple, where a reader must keep track of which 
> input matches which output, could lead to harder to follow code.

Isomehow I think last yesterday's keynote should recast some expectations about 
the degree of complexity (richness) the language will ever reach... Somehow 
xamarin/c# might endupmbeing swift++ for many people


> 
> In my own code I will probably stick to using the long form `guard let a = 
> opt1, let b = opt2, let c = opt3 else { … }`, not because I would like typing 
> it, but because it will be the most clear.
> 
> I would have loved for SE-0099 to have gone with semicolon/newline separators 
> so I could write it like this, but alas:
> 
> guard
>   let a = opt1
>   let b = opt2
>   let c = opt3
> else {
>   …
> }
> 
> 
> A different thought — maybe if Xcode had autocompletion to unwrap Optionals 
> when inside an `if` or `guard` statement it would make things a lot easier. 
> Just type the full name of the optional, then press escape, and then code 
> will be suggested to unwrap it. Is the pain this proposal targets mainly in 
> the writing more than reading?
> 
> 
> guard opt·|·
> 
> 
> guard let <#placeholder#> = opt1
> 
> 
> guard let a = opt1
> 
> 
> guard let a = opt1, opt2·|·
> 
> 
> guard let a = opt1, let <#placeholder#> = opt2
> 
> 
> guard let a = opt1, let b = opt2
> 
> 
> 
> Patrick
> 
>> On 14 Jun 2016, at 2:07 PM, Xiaodi Wu  wrote:
>> 
>> Also, see: 
>> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>> 
>> 
>>> On Mon, Jun 13, 2016 at 11:06 PM, Xiaodi Wu  wrote:
>>> This has been suggested before, I believe. The core team has weighed in 
>>> several times; it seemed like there was some disagreement amongst them 
>>> whether the current syntax is the wisest, but the concluding statement 
>>> seemed uncontroversial: "I don't think it's something we can change."
>>> 
>>> Source:
>>> http://article.gmane.org/gmane.comp.lang.swift.evolution/15879/
>>> 
>>> 
 On Mon, Jun 13, 2016 at 10:32 PM, Patrick Smith via swift-evolution 
  wrote:
 If Pyry’s suggestion remained the preferred way of unwrapping a tuple, 
 could it also become the only way for unwrapping a single item?
 
 guard case let a? = opt1 {
 ...
 }
 
 Or even shortened for matching optionals only:
 
 guard let a? = opt1 {
 ...
 }
 
 Or even as has often been requested, to keep the same name:
 
 guard let opt1? {
 ...
 }
 
 Multiples:
 
 guard let (opt1?, opt2?, opt3?) {
 ...
 }
 
 guard let (a?, b?, c?) = (opt1, opt2, opt3) {
 ...
 }
 
 Sorry, not trying to derail, but it always has seemed like something 
 shorter and more self explanatory could be made for optionals. `?` in 
 pattern matching is a special syntax anyway, so why not make this common 
 use case easier?
 
 Patrick
 
 _
 From: Pyry Jahkola via swift-evolution 
 Sent: Sunday, June 12, 2016 10:04 PM
 Subject: Re: [swift-evolution] [Draft] Tuple-Based Compound Optional 
 Binding
 To: Brent Royal-Gordon 
 Cc: swift-evolution List 
 
 
 
 
 On 12 Jun 2016, at 14:46, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 guard let (a, b, c) = (opt1, opt2, opt3) else { ... }
 
 You mention `guard case` in the motivation, but I think for the 
 uninitiated reader it would be fair to point out that the following 
 example already works equivalently, with only a few extra characters:
 
 guard case let (a?, b?, c?) = (opt1, opt2, opt3) else { ... }
 
 Aside of that, it's yet more magic to our `if let` syntax but I don't 
 mind, it would be useful at times.
 
 — Pyry
 
 
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[plx via swift-evolution]

> On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I am 100% with Charlie on this. Expressiveness has to do with the 
>> *effectiveness* of conveying a thought or a feeling.
>> 
>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>> concisely.
> 
> For those of you in favor of retaining `where`, how do you feel about adding 
> `while`, `until`, `unless`, etc?

In the interest of advancing the “what kind of language would I prefer swift 
become?”, here are my final thoughts on this topic:

For those particular keywords, I’d prefer having them (or equivalents). I’m not 
sure if I’d prefer having *all* of them—`where/unless` and `while/until`—or 
just one from each “pair”…I could go either way.

As a general consideration, I’d be in favor of having them b/c I’d really like 
Swift to have a comprehension-style construct (and associated syntax etc.).

Comprehension syntax is IMHO pretty common outside the C family—within the C 
family really only C# has something like it—and in general comprehension syntax 
has pretty similar structure from language to language. This link illustrates 
the syntax for 28 languages’  comprehension constructs, so it isn’t a bad 
overview:

https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)

…(note that “comprehension syntax” isn’t quite the same thing as “list 
comprehensions”, but for “comparative syntax” purposes that link should be 
sufficient).

For me the appeal of “comprehension syntax” is that it allows writing code that 
feels more “semantic” than “mechanical”, and that paraphrases much closer to 
the intended meaning.

Here’s a toy example:

  // with a comprehension-like syntax
  // outside loop: “what items do we care about?"
  for visitor in queue where visitor.hasTicket until venue.isFull {
// inside loop: “…and what do we do with them?"
venue.admit(visitor)
  }

…which to my eyes paraphrases more-or-less how I’d describe what we’re doing:

- “keep admitting visitors with tickets until the venue is full”

…whereas without it, you get something like this:

  // without comprehension-style syntax
  // outside loop: where, mechanically, are we sourcing items from
  for visitor in queue {
// inside loop: muddled mix of filtering, app logic, and flow-control
// filtering:
guard visitor.hasTicket else { continue }
// app logic:
venue.admit(visitor)
// flow-control:
if venue.isFull { break }
  }

…which *is* closer to the underlying mechanics, but paraphrases more like 
something you'd see in a badly-translated 80s VCR programing manual:

- “Start considering visitors. If the visitor doesn't have a ticket, move on to 
the next visitor. Otherwise, admit the visitor. If the venue is full, stop 
considering visitors.”

Sure, they’re both equivalent—and even in the 80s, some people managed to 
program their VCRs!—but given the option I’d strongly prefer to write in the 
first style; I like having a clean segregation between “what items are of 
interest?” and “what do we do with them?”

So that’s what I like about comprehension-like constructs.

The current `for-in-where` is a bit of an anomaly; it could be grown into 
something a little richer—`for _ in _ where _ while _`  and/or `for _ in _ 
where _ until _` (etc.).—or it could be dropped and some better construct 
proposed.

But, my personal preference would be to keep it around until either the richer 
construct is available or definitively declared as “not swift-y, not 
happening”: 

- if a “comprehension” construct is approved, an automatic migrator would 
likely do a *much* better job translating those `for _ in _ where` loops than 
it’d do with their more-imperative equivalents
- if a “comprehension” construct is definitively-rejected, at least I can keep 
using something I like until the hammer drops

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

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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Vladimir.S via swift-evolution]

On 13.06.2016 18:59, L. Mihalkovic via swift-evolution wrote:

I don’t dispute that we *could* live without “where” - that is not
the point. We could also live without classes or generics or any
of a variety of other features - but why should we when we don’t
have to?

The corollary question every parent has to deal with is to learn to make
a sacrifice now for a better outcome tomorrow. Maybe this is another way
to look at this question?



Yes, if you know *for sure* it it will be "better outcome" tomorrow. I.e. 
we even don't have any thoughts about what LINQ for Swift can look like, 
and when we'll only start to discuss this(4.x? 5.x? 6.x?), but we 
definitely needs to remove handful feature now and then keep the hope it 
will return in more powerful way. Probably we need to be very close to 
situation when 'where' in 'for-in' loop prevents introduction of LINQ-like 
feature to remote this 'where'? (probably with for-in loop together).


Again, we have sugar of `for-in` to be able to iterate 
sequences in handy way, we need it only for this purpose. We 
have 'where' feature in 'for-in' to be able to filter the iterating 
sequence. Filtering is essential operation for sequences/collections 
(.filter is one of main 3 operations : filter/map/reduce). As we have a 
special sugar to iterate sequences I find it very logical to have in it a 
sugar to filter iterated sequences. Force people to use guard-continue 
instead of 'where' for me is equal to force to use 'while' loop to iterate 
sequences instead of `for-in` loop.


Also, as was mentioned, in some situations you want to apply logically 
'main' filter in 'where' clause and then use guard-continue for additional 
filters/checks in body.


And 'where' in for-in loops does exist now in Swift. IMO you need really 
strong arguments to remove it. I've read all the messages of Xiaodi and 
Erica(and others), and I didn't find any argument that clearly shows that 
'where' is a bad thing and must be removed, I saw your opinions or your 
view of Swift future or your understanding of Swift goals or your 
understanding of core-team thoughts or your preferable style for coding etc.


If it is not clear if 'where' has 'continue if fails' behavior - IMO we 
need to *rename* it. It is just not logically to remove the feature if 
keyword is not clear enough(*for some beginners who see it the first time) 
- make the keyword clear, then you have no main argument to remove the 
_feature_.

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

[swift-evolution] [Discussion] Default Closure Arguments

[Andrew Bennett via swift-evolution]

I'd like to be able to do this:

func callSomething(callback: (test: (arg: Int = 4) -> Void) -> Void) {

  callback(test: { print($0) })

}


callSomething { test in

  test()

}



Ideally the default argument would be part of the closure's type signature.

If-not then it could be part of callSomething's signature, and it could
lose the defaulted arguments if passed around.

What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

[Patrick Smith via swift-evolution]

Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to me, 
because it has knock on effects of making other things more complicated. But I 
do see how for the most simple case of unwrapping a single Optional, it makes 
sense.

As much as I would like Brent’s proposal to make things easier to type, I think 
nesting things inside a tuple, where a reader must keep track of which input 
matches which output, could lead to harder to follow code.

In my own code I will probably stick to using the long form `guard let a = 
opt1, let b = opt2, let c = opt3 else { … }`, not because I would like typing 
it, but because it will be the most clear.

I would have loved for SE-0099 to have gone with semicolon/newline separators 
so I could write it like this, but alas:

guard
  let a = opt1
  let b = opt2
  let c = opt3
else {
  …
}


A different thought — maybe if Xcode had autocompletion to unwrap Optionals 
when inside an `if` or `guard` statement it would make things a lot easier. 
Just type the full name of the optional, then press escape, and then code will 
be suggested to unwrap it. Is the pain this proposal targets mainly in the 
writing more than reading?


guard opt·|·


guard let <#placeholder#> = opt1


guard let a = opt1


guard let a = opt1, opt2·|·


guard let a = opt1, let <#placeholder#> = opt2


guard let a = opt1, let b = opt2



Patrick

> On 14 Jun 2016, at 2:07 PM, Xiaodi Wu  wrote:
> 
> Also, see: 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md 
> 
> 
> 
> On Mon, Jun 13, 2016 at 11:06 PM, Xiaodi Wu  > wrote:
> This has been suggested before, I believe. The core team has weighed in 
> several times; it seemed like there was some disagreement amongst them 
> whether the current syntax is the wisest, but the concluding statement seemed 
> uncontroversial: "I don't think it's something we can change."
> 
> Source:
> http://article.gmane.org/gmane.comp.lang.swift.evolution/15879/ 
> 
> 
> 
> On Mon, Jun 13, 2016 at 10:32 PM, Patrick Smith via swift-evolution 
> > wrote:
> If Pyry’s suggestion remained the preferred way of unwrapping a tuple, could 
> it also become the only way for unwrapping a single item?
> 
> guard case let a? = opt1 {
> ...
> }
> 
> Or even shortened for matching optionals only:
> 
> guard let a? = opt1 {
> ...
> }
> 
> Or even as has often been requested, to keep the same name:
> 
> guard let opt1? {
> ...
> }
> 
> Multiples:
> 
> guard let (opt1?, opt2?, opt3?) {
> ...
> }
> 
> guard let (a?, b?, c?) = (opt1, opt2, opt3) {
> ...
> }
> 
> Sorry, not trying to derail, but it always has seemed like something shorter 
> and more self explanatory could be made for optionals. `?` in pattern 
> matching is a special syntax anyway, so why not make this common use case 
> easier?
> 
> Patrick
> 
> _
> From: Pyry Jahkola via swift-evolution  >
> Sent: Sunday, June 12, 2016 10:04 PM
> Subject: Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding
> To: Brent Royal-Gordon  >
> Cc: swift-evolution List  >
> 
> 
> 
> 
> On 12 Jun 2016, at 14:46, Brent Royal-Gordon via swift-evolution 
> > wrote:
> 
> guard let (a, b, c) = (opt1, opt2, opt3) else { ... }
> 
> You mention `guard case` in the motivation, but I think for the uninitiated 
> reader it would be fair to point out that the following example already works 
> equivalently, with only a few extra characters:
> 
> guard case let (a?, b?, c?) = (opt1, opt2, opt3) else { ... }
> 
> Aside of that, it's yet more magic to our `if let` syntax but I don't mind, 
> it would be useful at times.
> 
> — Pyry
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> 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] Retiring `where` from for-in loops

[Austin Zheng via swift-evolution]

> On Jun 14, 2016, at 1:22 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 14 Jun 2016, at 07:54, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> And a language feature being undocumented wouldn't explain why the entire 
>> stdlib uses it only three times :)
> 
> I sometimes wonder whether the stdlib is always the best example of pure 
> Swift coding practices, it has after all been developed while the language 
> itself is in flux so chunks of it were being written while language features 
> were actively changing, and it has a lot of patterns in it that I just don’t 
> use in Swift. For example, I still haven’t figured out why the Indexable 
> protocol has an IndexableBase parent (other than to make figuring out why my 
> types don’t conform a lot harder),

AFAIK this is because associated types currently can't define a recursive 
protocol conformance constraint. For example, `SignedIntegerType` has a 
`Distance` associated type which should also be a `SignedIntegerType`, but has 
to be implemented using a shadow protocol (`_SignedIntegerType`) instead.

> and there’s stuff going on in .gyb files that remains a mystery to me. 
> There’s also a lot of little hidden features that we don’t have access to in 
> our own code (I can't find a method that retrieves object identifiers, for 
> comparing two types without knowing what they are, outside of the stdlib for 
> example, yet you’ll find them used inside AnyIndex and similar types).

Is the publicly exposed `ObjectIdentifier` type what you're looking for?

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

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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Haravikk via swift-evolution]

> On 14 Jun 2016, at 07:54, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> And a language feature being undocumented wouldn't explain why the entire 
> stdlib uses it only three times :)

I sometimes wonder whether the stdlib is always the best example of pure Swift 
coding practices, it has after all been developed while the language itself is 
in flux so chunks of it were being written while language features were 
actively changing, and it has a lot of patterns in it that I just don’t use in 
Swift. For example, I still haven’t figured out why the Indexable protocol has 
an IndexableBase parent (other than to make figuring out why my types don’t 
conform a lot harder), and there’s stuff going on in .gyb files that remains a 
mystery to me. There’s also a lot of little hidden features that we don’t have 
access to in our own code (I can't find a method that retrieves object 
identifiers, for comparing two types without knowing what they are, outside of 
the stdlib for example, yet you’ll find them used inside AnyIndex and similar 
types).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 14, 2016, at 8:41 AM, Charlie Monroe  wrote:
> 
>> I used to do low latency java for trading systems... the kind of coding 
>> where we would go out of our way to avoid ANY intraday gc activity (yes it 
>> can be done, even for parsing xml files). So we cared about a lot of 
>> things... But when you look at the numbers above on a 4_000_000 iterations 
>> loop and say the differential matters? I say you are probably using the 
>> wrong tools to write your code in the first place, and you should be using 
>> accelerate.
> 
> Yes, I say it does matter. Of course, 4 million iterations is a fictional 
> example that rarely occurrs on its own, but gives you an idea that there's 
> more going on behind the scenes other than pure iteration.
> 
> You're looking at it from a point where one app does one thing and the loop 
> will have just a few iterations. Try to look at it from a point where the 
> entire OS, all the processes and kernel  are written in Swift (might be 
> distant future, but Swift is heading that way, isn't it?).
> 
> In such case if each for-loop takes a few extra instruction, then - again - 
> yes, it matters. I know we're not talking about all for-loops, just those 
> filtering the sequence - which seems not that common of a case - but my point 
> is valid, that Swift should provide easily-reachable means to be a "good 
> citizen". Removing it will lead developers to use .filter(_:) instead, in 
> order to save lines of code and additional typing.
> 
> While many searches in open source code found a minimum usage of 
> for-in-where, I think this is not due to it being confusing, but just not 
> well known, otherwise it would be used a lot more. Most developers that have 
> prior programming experience will only skim through the Language Guide 
> itself, which doesn't mention that `where` can be used in for loops (!!!), or 
> even while loops and there isn't a single example where it would be used.
> 
> Both
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html
> and the ePub download on 
> https://swift.org/documentation/#the-swift-programming-language
> 
> Maybe I'm missing something, but the language guide only mentions `where` for 
> the switch-case scenario. So the argument (which floated around here) that 
> this is not being actively used is kind of moot since how could anyone be 
> using it since it's not properly documented and no one who doesn't closely 
> watch release notes can possibly know about this.

Non-argument... everything that has been removed was documented prior to its 
removal.

> 
> 
>> 
>> As for the '
>> 
>>> 
>>> I've previously noted that if/guard-continue come in really close 
>>> speed-wise, which makes them candidates for a fix-it in case `where` is 
>>> indeed removed.
>>> 
>>> My response here was solely to Jean-Daniel's note that he mustn't forget to 
>>> include the lazy accessor, pointing out that even the lazy accessor is 
>>> slower than using an inline check.
>>> 
>>> 
 
 -- 
 Brent Royal-Gordon
 Architechies
 
>>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 14, 2016, at 7:01 AM, Charlie Monroe  wrote:
> 
> 
>> On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon  
>> wrote:
>> 
 See the benchmarks me and Erica have posted here a few days back - even 
 with the lazy accessor, if you decided to use filter(_:), you lost 10+% of 
 performance. Correct way to do this without `where` and without 
 performance penalization is to use guard within the for-in loop.
>>> 
>>> 10% on a microbenchmark repeater 400 times is hardly a justification 
>>> for going on way or the other.
>> 
>> You're right: 10% on a microbenchmark isn't the best possible data. If you 
>> have better data, we are all ears.
> 
> I never said that it's a deal-breaker, but it is definitely something to 
> consider. Since we're discussing performance of the loop itself, you can't 
> perform much in the body of the for loop since it would skew the result 
> (obviously). 

This is a potentially very questionable statement as it stands!  Rule #1 of 
micro benchmarking is: they measure something for sure, but do you know what? 
Unless you do understand your compiler and how to make it do what you want, 
micro-benchmarks should always be assumed to be a misleading waste of time. If 
however you manage to convince yourself that what you measure is what your 
think you are measuring, then they can be a useful tool (disassembling is a 
good starting point).

Benchmarks like that should be considered wit their use-case. The numbers 
(provided they can be validated) would indicate that the difference is 
negligeable altogether. And someone doing heavy math would hopefully use 
accelerate for vectorization, rather than code like this.

> 
> I've previously noted that if/guard-continue come in really close speed-wise, 
> which makes them candidates for a fix-it in case `where` is indeed removed.
> 
> My response here was solely to Jean-Daniel's note that he mustn't forget to 
> include the lazy accessor, pointing out that even the lazy accessor is slower 
> than using an inline check.
> 
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Xiaodi Wu via swift-evolution]

The performance of stdlib methods is not fixed in stone.

And a language feature being undocumented wouldn't explain why the entire
stdlib uses it only three times :)
On Tue, Jun 14, 2016 at 1:42 AM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> I used to do low latency java for trading systems... the kind of coding
> where we would go out of our way to avoid ANY intraday gc activity (yes it
> can be done, even for parsing xml files). So we cared about a lot of
> things... But when you look at the numbers above on a 4_000_000 iterations
> loop and say the differential matters? I say you are probably using the
> wrong tools to write your code in the first place, and you should be using
> accelerate.
>
>
> Yes, I say it does matter. Of course, 4 million iterations is a fictional
> example that rarely occurrs on its own, but gives you an idea that there's
> more going on behind the scenes other than pure iteration.
>
> You're looking at it from a point where one app does one thing and the
> loop will have just a few iterations. Try to look at it from a point where
> the entire OS, all the processes and kernel  are written in Swift (might be
> distant future, but Swift is heading that way, isn't it?).
>
> In such case if each for-loop takes a few extra instruction, then - again
> - yes, it matters. I know we're not talking about all for-loops, just those
> filtering the sequence - which seems not that common of a case - but my
> point is valid, that Swift should provide easily-reachable means to be a
> "good citizen". Removing it will lead developers to use .filter(_:)
> instead, in order to save lines of code and additional typing.
>
> While many searches in open source code found a minimum usage of
> for-in-where, I think this is not due to it being confusing, but just not
> well known, otherwise it would be used a lot more. Most developers that
> have prior programming experience will only skim through the Language Guide
> itself, which doesn't mention that `where` can be used in for loops (!!!),
> or even while loops and there isn't a single example where it would be used.
>
> Both
>
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html
> and the ePub download on
> https://swift.org/documentation/#the-swift-programming-language
>
> Maybe I'm missing something, but the language guide only mentions `where`
> for the switch-case scenario. So the argument (which floated around here)
> that this is not being actively used is kind of moot since how could anyone
> be using it since it's not properly documented and no one who doesn't
> closely watch release notes can possibly know about this.
>
>
>
> As for the '
>
>
> I've previously noted that if/guard-continue come in really close
> speed-wise, which makes them candidates for a fix-it in case `where` is
> indeed removed.
>
> My response here was solely to Jean-Daniel's note that he mustn't forget
> to include the lazy accessor, pointing out that even the lazy accessor is
> slower than using an inline check.
>
>
>
> --
>
> 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] [Pitch] Retiring `where` from for-in loops

[Charlie Monroe via swift-evolution]

> I used to do low latency java for trading systems... the kind of coding where 
> we would go out of our way to avoid ANY intraday gc activity (yes it can be 
> done, even for parsing xml files). So we cared about a lot of things... But 
> when you look at the numbers above on a 4_000_000 iterations loop and say the 
> differential matters? I say you are probably using the wrong tools to write 
> your code in the first place, and you should be using accelerate.

Yes, I say it does matter. Of course, 4 million iterations is a fictional 
example that rarely occurrs on its own, but gives you an idea that there's more 
going on behind the scenes other than pure iteration.

You're looking at it from a point where one app does one thing and the loop 
will have just a few iterations. Try to look at it from a point where the 
entire OS, all the processes and kernel  are written in Swift (might be distant 
future, but Swift is heading that way, isn't it?).

In such case if each for-loop takes a few extra instruction, then - again - 
yes, it matters. I know we're not talking about all for-loops, just those 
filtering the sequence - which seems not that common of a case - but my point 
is valid, that Swift should provide easily-reachable means to be a "good 
citizen". Removing it will lead developers to use .filter(_:) instead, in order 
to save lines of code and additional typing.

While many searches in open source code found a minimum usage of for-in-where, 
I think this is not due to it being confusing, but just not well known, 
otherwise it would be used a lot more. Most developers that have prior 
programming experience will only skim through the Language Guide itself, which 
doesn't mention that `where` can be used in for loops (!!!), or even while 
loops and there isn't a single example where it would be used.

Both
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html
 

and the ePub download on 
https://swift.org/documentation/#the-swift-programming-language 


Maybe I'm missing something, but the language guide only mentions `where` for 
the switch-case scenario. So the argument (which floated around here) that this 
is not being actively used is kind of moot since how could anyone be using it 
since it's not properly documented and no one who doesn't closely watch release 
notes can possibly know about this.


> 
> As for the '
> 
>> 
>> I've previously noted that if/guard-continue come in really close 
>> speed-wise, which makes them candidates for a fix-it in case `where` is 
>> indeed removed.
>> 
>> My response here was solely to Jean-Daniel's note that he mustn't forget to 
>> include the lazy accessor, pointing out that even the lazy accessor is 
>> slower than using an inline check.
>> 
>> 
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 

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