Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Taras Zakharko via swift-evolution]

You could use the pointer/raw memory API to implement that. 

One reason why I dislike the idea of introducing fixed-size arrays as a 
first-class language feature is that it adds an additional construct with quite 
niche use. Non-type generic parameters instead give you a powerful tool that 
you can use to implement all kinds of things. 

BTW, another way to have fixed-size arrays would be to extend the tuple type. 
However, if i understand correctly, the biggest optimisation potential comes 
from knowing the size of the array at the compile time. So we do need some sort 
of specialisation parameter. 

Best, 

 Taras

> I don't think that non-type generic arguments are enough to create fixed-size 
> arrays. How would you fill in `struct Vector<T, count: Int>{ ... }`?
> 
> Seems to me that the first step would be actual language support for 
> non-parametrizable fixed-size arrays.
> 
> Félix
> > Le 5 août 2016 à 04:53:20, Taras Zakharko via 
> > swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>a
> >  écrit :
> > 
> > 
> > > A few things immediately spring to mind:
> > > • Fixed-size arrays
> > > • An optimized Matrix type
> > > • Swifty syntax for Fourier transforms
> > > • A numerical integrator (or diff-eq solver!)
> > > • BigInt capabilities
> > > 
> > > The first of these (fixed-size arrays) will probably require compiler 
> > > support.
> > 
> > Fixed-size arrays should be easy enough to implement if the Swift generics 
> > are enhanced with support for constraints beyond type variables. E.g.
> > 
> > struct Vector<T, count: Int>{ … }
> > 
> > var x : Vector<Float, count=16>
> > 
> > or even
> > 
> > struct SparseTensor<T, dimensions : [Int]>{ … }
> > 
> > var x: SparseTensor<Float, dimensions = [100, 100, 100, 100]>= 
> > SparseTensor(withValue: 0)
> > 
> > I believe that something like this was mentioned in the discussion of the 
> > Generics Manifesto. If you are interested in making Swift more suitable for 
> > numerical operations, I’d say that the first order of business is to work 
> > towards implementing this sort of generic constants.
> > 
> > Best,
> > 
> > Taras
> > 
> > > 
> > > The rest can already be done in a library, except I believe they will hit 
> > > the “generics cannot be specialized across module boundaries” slowdown, 
> > > and must be explicitly specialized for common numeric types to avoid it. 
> > > (Has this been fixed yet? Are there plans to?)
> > > 
> > > Nevin
> > > 
> > > 
> > > 
> > > On Wed, Aug 3, 2016 at 8:41 AM, Björn 
> > > Forster<swift-evolution@swift.org(mailto:swift-evolution@swift.org)(mailto:swift-evolution@swift.org)>wrote:
> > > > Hello Swift community,
> > > > to make use of Swift more appealing and useful for science, engineering 
> > > > and finance and everything else involving actually calculating things, 
> > > > I think it would be a big step forward if Swift would ship with its own 
> > > > math/numerics library.
> > > > 
> > > > Wouldn't it be great if Swift would offer functionality similar to 
> > > > Numpy in its native math lib? It think it would be great to have a 
> > > > "standard" annotation for vector arithmetic that the Swift community 
> > > > has agreed on and that scientific packages can build on.
> > > > 
> > > > Which functionality should be covered by a Swift's math lib and where 
> > > > should be drawn the line?
> > > > 
> > > > Any thoughts?
> > > > 
> > > > (If it is not the right time now to talk this topic, as it is not 
> > > > mentioned in the goals for Swift 4 by Chris, I apologize for bringing 
> > > > this up now. But I think then this should be discussed later at some 
> > > > point not in the infinite future)
> > > > 
> > > > Björn
> > > > ___
> > > > swift-evolution mailing list
> > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)(mailto:swift-evolution@swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > 
> > > 
> > > 
> > > 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Taras Zakharko via swift-evolution]

> A few things immediately spring to mind:
> • Fixed-size arrays
> • An optimized Matrix type
> • Swifty syntax for Fourier transforms
> • A numerical integrator (or diff-eq solver!)
> • BigInt capabilities
> 
> The first of these (fixed-size arrays) will probably require compiler support.

Fixed-size arrays should be easy enough to implement if the Swift generics are 
enhanced with support for constraints beyond type variables. E.g.

  struct Vector { … } 

  var x : Vector

or even 

 struct SparseTensor { … }

 var x: SparseTensor = 
SparseTensor(withValue: 0)

I believe that something like this was mentioned in the discussion of the 
Generics Manifesto. If you are interested in making Swift more suitable for 
numerical operations, I’d say that the first order of business is to work 
towards implementing this sort of generic constants. 

Best, 

 Taras

> 
> The rest can already be done in a library, except I believe they will hit the 
> “generics cannot be specialized across module boundaries” slowdown, and must 
> be explicitly specialized for common numeric types to avoid it. (Has this 
> been fixed yet? Are there plans to?)
> 
> Nevin
> 
> 
> 
> On Wed, Aug 3, 2016 at 8:41 AM, Björn 
> Forsterwrote:
> > Hello Swift community,
> > to make use of Swift more appealing and useful for science, engineering and 
> > finance and everything else involving actually calculating things, I think 
> > it would be a big step forward if Swift would ship with its own 
> > math/numerics library.
> > 
> > Wouldn't it be great if Swift would offer functionality similar to Numpy in 
> > its native math lib? It think it would be great to have a "standard" 
> > annotation for vector arithmetic that the Swift community has agreed on and 
> > that scientific packages can build on.
> > 
> > Which functionality should be covered by a Swift's math lib and where 
> > should be drawn the line?
> > 
> > Any thoughts?
> > 
> > (If it is not the right time now to talk this topic, as it is not mentioned 
> > in the goals for Swift 4 by Chris, I apologize for bringing this up now. 
> > But I think then this should be discussed later at some point not in the 
> > infinite future)
> > 
> > Björn
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[Taras Zakharko via swift-evolution]

Great news! Given that this was probably the most polarising proposal ever, I 
am very impressed with the patience and professionalism the core team has shown 
in handling the situation and ultimately converging on an elegant solution — 
all that under oppressive deadline! A barrel of whiskey would be more then 
appropriate :)

--T

> On 28 Jul 2016, at 00:06, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> The third review of "SE-0177: Allow distinguishing between public access and 
> public overridability" ran from Active review July 21...25. The proposal has 
> been *accepted with revisions*.
> 
> This proposal was far better received by the community than previous versions 
> of the proposal, and the “first design” was the favored path within it.  
> However, there were some concerns raised about the complexity of the model, 
> stemming from non-obvious combinations like “open private”.  As such, the 
> core team has requested that the proposal be revised to make “open” function 
> as another access control specifier.  “open” is now simply “more public than 
> public”, providing a very simple and clean model.
> 
> John has already revised the proposal to the new model, I encourage you to 
> read it if you haven’t already.
> 
> Thank you to John McCall and also Javier Soto for driving this discussion 
> forward!  John is already working on an implementation of this now.
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Taras Zakharko via swift-evolution]

> On 22 Jul 2016, at 12:11, L. Mihalkovic <laurent.mihalko...@gmail.com> wrote:
> 
> 
> 
> Regards
> (From mobile)
> 
> On Jul 22, 2016, at 9:22 AM, Taras Zakharko via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> To be honest, I have difficulty with the terminology here. Why use the term 
>> ‚metatype‘ 
> 
> It is the literature's terminology (types about types) and also the 
> compiler's own naming.


I am certainly not contesting these facts. However, I am not sure how helpful 
this particular terminology is in the relevant context. After all, we are 
talking here about operations on types themselves, not types of a type. While 
it is true that any type variable/parameter itself is of a metatype type, I 
don’t see any utility gained by making this fact explicit. Something like Type 
or TypeInfo accomplishes the same and is probably easier to understand. 

For instance, I have difficulty understanding why you suggest to rename 
type(of:) to metatype(of:). Unless I am completely confused, the return value 
is a type, isn’t it? its just that the type of the return value is a metatype. 

This is a different thing in languages like Python, where metatypes have a 
clear practical purpose (it is possible to directly create and manipulate 
metatypes).

— T. 

P.S. I hope my naive questions are not too inappropriate. I am honestly trying 
to understand the topic. While I do have some background in higher-order logic 
and type theory, and I have done a fair share of programming with types and 
types of types, the way Swift works in this regard eludes me. 

> 
>> in the first place? Why not just ‚Type'? Or ‚TypeDescriptor‘ (in analogy to 
>> ObjectIdentifier)? What do we actually gain by the technical distinction 
>> between a type and a type of a type? I would understand it if we had the 
>> ability to construct higher-order types, such as custom metatypes or even 
>> metatype types in Swift.  
>> 
>> But in general, I am sympathetic with the proposal.Swift type/metatype 
>> facilities are very confusing (I still don’t  get how the .Type, .Self, 
>> .self etc. stuff works) and bringing some clarity will be most welcome. 
>> 
>> — T. 
>> 
>> 
>>> On 22 Jul 2016, at 00:40, Adrian Zubarev via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md
>>>  
>>> <https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md>
>>> Rename T.Type
>>> 
>>> Proposal: SE–0126 
>>> 
>>> Authors: Adrian Zubarev <https://github.com/DevAndArtist>, Anton Zhilin 
>>> <https://github.com/Anton3>
>>> Status: Revision
>>> Review manager: Chris Lattner <http://github.com/lattner>
>>> Revision: 2
>>> Previous Revisions: 1 
>>> <https://github.com/apple/swift-evolution/blob/83707b0879c83dcde778f8163f5768212736fdc2/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md>
>>> Introduction
>>> 
>>> This proposal renames the current metatype T.Type notation and the global 
>>> function from SE–0096 to match the changes.
>>> 
>>> Swift-evolution threads: 
>>> 
>>> [Pitch] Rename T.Type 
>>> [Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror 
>>> 
>>> [Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror 
>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024772.html>
>>> [Discussion] Seal T.Type into Type 
>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023818.html>
>>> Motivation
>>> 
>>> In Swift metatypes have the following notation: T.Type
>>> 
>>> As already showed in SE–0096 and SE–0090 the Swift community strongly is in 
>>> favor of (re)moving magical intstance or type properties.
>>> 
>>> SE–0096 moves instanceOfT.dynamicType to type(of: T) -> T.Type.
>>> 
>>> SE–0090 aims to remove .self completely.
>>> 
>>> We propose to rename T.Type to a generic-like notation Metatype. To be 
>>> able to achieve this notation we have to resolve a few issues first.
>>> 
>>> Known issues of metatypes:
>>> 
>>> Assume this function that checks if an Int type conforms to a specific 
>>> protocol. This check uses current model of metatypes combined in a generic 
>>&

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

[Taras Zakharko via swift-evolution]

To be honest, I have difficulty with the terminology here. Why use the term 
‚metatype‘ in the first place? Why not just ‚Type'? Or ‚TypeDescriptor‘ (in 
analogy to ObjectIdentifier)? What do we actually gain by the technical 
distinction between a type and a type of a type? I would understand it if we 
had the ability to construct higher-order types, such as custom metatypes or 
even metatype types in Swift.  

But in general, I am sympathetic with the proposal.Swift type/metatype 
facilities are very confusing (I still don’t  get how the .Type, .Self, .self 
etc. stuff works) and bringing some clarity will be most welcome. 

— T. 


> On 22 Jul 2016, at 00:40, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md
>  
> 
> Rename T.Type
> 
> Proposal: SE–0126 
> 
> Authors: Adrian Zubarev , Anton Zhilin 
> 
> Status: Revision
> Review manager: Chris Lattner 
> Revision: 2
> Previous Revisions: 1 
> 
> Introduction
> 
> This proposal renames the current metatype T.Type notation and the global 
> function from SE–0096 to match the changes.
> 
> Swift-evolution threads: 
> 
> [Pitch] Rename T.Type 
> [Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror 
> 
> [Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror 
> 
> [Discussion] Seal T.Type into Type 
> 
> Motivation
> 
> In Swift metatypes have the following notation: T.Type
> 
> As already showed in SE–0096 and SE–0090 the Swift community strongly is in 
> favor of (re)moving magical intstance or type properties.
> 
> SE–0096 moves instanceOfT.dynamicType to type(of: T) -> T.Type.
> 
> SE–0090 aims to remove .self completely.
> 
> We propose to rename T.Type to a generic-like notation Metatype. To be 
> able to achieve this notation we have to resolve a few issues first.
> 
> Known issues of metatypes:
> 
> Assume this function that checks if an Int type conforms to a specific 
> protocol. This check uses current model of metatypes combined in a generic 
> context:
> 
> func intConforms(to _: T.Type) -> Bool {
>return Int.self is T.Type
> }
> 
> intConforms(to: CustomStringConvertible.self) //=> false
> 
> Int.self is CustomStringConvertible.Type  //=> true
> [1] When T is a protocol P, T.Type is the metatype of the protocol type 
> itself, P.Protocol. Int.self is not P.self.
> 
> [2] There isn’t a way to generically expression P.Type yet.
> 
> [3] The syntax would have to be changed in the compiler to get something that 
> behaves like .Type today.
> 
> Written by Joe Groff: [1] 
>  [2] 
>  [3] 
> 
> A possible workaround might look like the example below, but does not allow 
> to decompose P.Type:
> 
> func intConforms(to _: T.Type) -> Bool {
>   return Int.self is T
> }
> 
> intConforms(to: CustomStringConvertible.Type.self) //=> true
> We can extend this issue and find the second problem by checking against the 
> metatype of Any:
> 
> func intConforms(to _: T.Type) -> Bool {
> return Int.self is T
> }
> 
> intConforms(to: Any.Type.self) //=> true
> 
> intConforms(to: Any.self)  //=> true
> 
> Int.self is Any.Type   //=> Always true
> When using Any the compiler does not require .Type at all and returns true 
> for both variations.
> 
> The third issue will show itself whenever we would try to check protocol 
> relationship with another protocol. Currently there is no way (that we know 
> of) to solve this problem:
> 
> protocol P {}
> protocol R : P {}
> 
> func rIsSubtype(of _: T.Type) -> Bool {
> return R.self is T
> }
> 
> rIsSubtype(of: P.Type.self) //=> false
> 
> R.self is Any.Type //=> Always true
> R.self is P.Type   //=> true
> R.self is R.Type   //=> true
> We also believe that this issue is the reason why the current global 
> functions sizeof, strideof and alignof make use of generic (_: T.Type) 
> declaration notation instead of (_: Any.Type).
> 
> Proposed solution
> 
> Rename any occurrence of T.Type and T.Protocol to Metatype.
> 
> Revise metatypes internally. 
> 
> When T is a protocol, T.self should always return an instance of Metatype 
> (old T.Type) and never a T.Protocol. Furthermore, metatypes should reflect 
> the same type relationship behavior like the actual types 

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

[Taras Zakharko via swift-evolution]

This is definitively something very useful but it also introduces a strong 
asymmetry into Swift statements. In all control-flow statements, the condition 
is part of the outer scope. Or, to be more precise, its part of an intermediate 
scope between the outer and the inner scope (as you can declare variables in 
the condition which are invisible to the outer scope but visible to the inner 
scope). Your suggestion essentially moves the condition of repeat {} while () 
to the inner scope. I think that the more complex semantics is not worth the 
change. 

Here is how I deal with it btw:

process: do {

   let success = …


   guard success else { continue process }
}

Again, goto FTW :p

T.


> On 18 Jul 2016, at 19:52, Braeden Profile via swift-evolution 
>  wrote:
> 
> Good morning, Swift community!
> 
> I’ve come across a situation a number of times where I write code that has to 
> try something one or more times using a `repeat…while` loop and the condition 
> relies upon variables that should be declared within the scope of the loop.
> 
> repeat
> {
>   let success = doSomething()
> }
> while !success
> 
> The compiler unnecessarily prohibits this:  “Use of unresolved identifier 
> four.”  In this simple case, we can write:
> 
> repeat
> { }
> while !doSomething()
> 
> But in a more complex situation, we are forced to write:
> 
> var success: Bool
> repeat
> {
>   success = doSomething()
> }
> while !success
> 
> 
> We could change this so that the declarations within the top level scope of 
> the loop are accessible from the condition.
> 
> Thanks for reading my first post to the Swift discussion board!
> —Braeden
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Taras Zakharko via swift-evolution]

> On 18 Jul 2016, at 18:31, Xiaodi Wu  wrote:
> 
> At the same time, your solution results in a lot of unnecessary boilerplate.
>  
> It's an exaggeration to say that it's *a lot* of boilerplate. It's one line 
> or two in the base class.

> Sure, it might be rare with methods, but don’t forget about properties! It 
> makes perfect sense to have properties that should be only overridable 
> internally while being accessible publicly.
> 
> My first reaction here was: of course, good point! But then, on reflection, 
> what properties should behave this way? Can you give an example of a property 
> that makes sense to override in internal subclasses but not in external 
> subclasses, but that must be accessible publicly?
>  

Well, boilerplate is boilerplate. I can imagine a number of situations where 
you’d need it — any time where you can some sort of logical division in your 
class design, where some functionality relies on internal invariants that are 
no business of the user while functionality is tweakable. At the same time, 
after thinking about it for a while, I agree that such cases might be rare:

1. If your class requires a lot of sealed members, then probably there is a 
better design somewhere that splits that class in multiple components. 
2. If your members are overriden internally but sealed publicly, the 
performance argument seems to be diminished to me — the compiler still needs to 
do some sort of vtable dispatch if 
the identity of the instance type is not known at compile-time. 
3. I did a quick rudimentary regex through AppKit headers looking for stuff 
like "((n't)|(not)).{1,15}override“ and its true that there seem to be only a 
few dozens of documented methods where the documentation explicitly warns 
agains overriding them.  I have no idea how reliable the headers are or what 
the documentation is generated from, but that appears to me to be quite strong 
evidence 
in support of Károly’s and others arguments. 

I still think that explicit open is a better design conceptually, as it 
requires one to grant per-declaration permission instead than per-declaration 
prohibition, but I agree that it might be a sub optional design from the 
practical standpoint because of low frequency of sealed members in practice. In 
retrospect, It might be indeed worth seriously considering making ‚open‘ a 
class-level annotation only. But then, there are good arguments for having an 
additional ‚sealed‘ keyword for the relatively rare case where we want to 
explicitly exclude a method/property from being overridable. 

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

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

[Taras Zakharko via swift-evolution]

> On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution 
>  wrote:
> 
> 
> I see no drawback to this pattern; it is quite clear and simple. Therefore, 
> in the interest of keeping the language free of needless complexity, I 
> suggest we change the proposal to remove the implicit "sealed" level of 
> public member overridability, and support only "open" or "final" class 
> members.


At the same time, your solution results in a lot of unnecessary boilerplate. 
Sure, it might be rare with methods, but don’t forget about properties! It 
makes perfect sense to have properties that should be only overridable 
internally while being accessible publicly. Imagine adding that boilerplate to 
every such property.. 

Basically, if we do it your way, then it won’t be long that someone submits a 
proposal for a keyword for synthesising the boilerplate, which more or less 
brings us back to square one.  

T.


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

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

[Taras Zakharko via swift-evolution]

> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 

The proposal (and additional comments) explain this point fairly well. Usually, 
it makes sense to be overridable only for few select members — and compiler 
can’t easily figure out which entry points these are as the API invariants are 
not explicit. By making members sealed by default, the API contracts are made 
more clear.  Second (and a very important reason) is performance — if 
everything is open by default, the compiler can’t devirtualize property 
accessors even though it would be appropriate most of the time. The compiler 
can infer the ‚final‘ status of definitions within a module easily and optimise 
accordingly, which wot work if these definitions can be overridden externally. 
To put it differently, its much easier for the compiler to determine what can 
be safely considered final than what can be safely considered sealed. The 
design choices in the proposal follow naturally from these considerations. 

The final keyword still has its use, although I think its utility will be 
somewhat diminished after this proposal. You can still use it for things that 
can’t be overridden internally. Like classes that are intended only to be used 
as ‚structs  with reference semantics‘. 

— T



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

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

[Taras Zakharko via swift-evolution]

>   * What is your evaluation of the proposal?

+1. Looks much better than the previous version and makes a lot of sense to me. 

A quick clarification question (I didn’t find any mention of this in the 
proposal, but I might have missed it): what happens if a class is declared 
open, but does not contain any open member declarations? Is this legal? 

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

Most likely

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

Yes

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

A quick reading. I was also following the previous discussion. 


> On 16 Jul 2016, at 07:52, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Taras Zakharko via swift-evolution]

I have deliberately kept away from the discussion on this topic, as I didn’t 
feel like I can contribute in any meaningful way. In all honesty, I have barely 
used ‚traditional’ OOP paradigms in the last few years at all. While OOP is a 
useful tool and its great for modelling certain relationship and problems, I 
agree with the sentiment expressed by the core team that ‚open by default‘ OOP 
introduces a great deal of complexity for the framework creator, framework 
client and the compiler alike. Objective-C, with its dynamic message dispatch 
is a great example of a feature that is very flexible and quite beautiful, but 
at the same time so inherently unsafe, that it can easily be abused - AND that 
has been abused extensively. 

The fact is, the programming languages we are using currently don’t do a very 
good job in declaring, describing and enforcing invariants/contracts. More 
often than not, the invariants are expressed informally (if they are expressed 
at all). Under such circumstances, more openness means more chance to break 
things long-term. Until a more general solution can be found (API access roles? 
state invariants declarations?) anything that makes things more explicit is a 
good thing in my book. 


> On 15 Jul 2016, at 07:58, Charles Srstka via swift-evolution 
>  wrote:
> 
> Or because the framework was developed in the real world, rather than 
> Elysium, and real-world framework developers just about *never* anticipate 
> every single way someone might use their framework (Indeed, if developers 
> were capable of such a thing, there would be no need for third-party software 
> in the first place).

If I am selling a frying pen, I am really not interested in people using it as 
a hammer ;) To be honest, I don’t really understand your post. A framework has 
a particular application domain and caters to certain use cases. It either 
meets its design goals or not. What does it have to do with need for 
third-party software? And how does ability to subclass makes it any better? 

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

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko via swift-evolution]

Great!

This cleanly separates between the type and the name/signature! Simple and 
consistent. Thank you!

A clarification question: do i understand correctly that steps 2 and 3 will not 
be included in Swift 3 due time constraints?

— T


> On 14 Jul 2016, at 06:47, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> 
> Shortly after SE-0111 was accepted last week, several people newly noticed 
> the proposal and started a discussion about how it appears to be a regression 
> for closure parameters (e.g. callbacks) that could formerly carry labels, but 
> are now not allowed to.  These folks observed that it would be more 
> expressive (and consistent with the rest of Swift) to allow parameter labels 
> in function types, because the invocation site of a closure “should" be 
> required to provide those labels.  The core team has been following the 
> discussion, agrees that this is a concern, and wants to update the community 
> with a path forward.
> 
> The reality of the situation is that the current implementation of parameter 
> labels in function types is inherently broken.  Specifically, as one example, 
> there is an implicit conversion from "(a: Int) -> Int” to “(Int) -> Int”.  
> However, there is also an implicit conversion from "(Int) -> Int” to “(b : 
> Int) -> Int”.  This means that the compiler currently allows converting from 
> “(a: Int) -> Int” to “(b: Int) -> Int”, which doesn’t make sense, introduces 
> surprising behavior, introduces complexity into the compiler implementation, 
> and is generally a problem.  We do have one specific hack to prevent 
> conversion of (e.g.) “(a : Int, b : Int) -> Void” to “(b : Int, a : Int) -> 
> Void”, but this only triggers in specific cases.  There are other more 
> complex cases as well, e.g. when using generics "T<(a : Int)->Int>” cannot be 
> considered compatible with "T<(b : Int)->Int>”.
> 
> These problems are what initially motivated SE-0111.  However, given the 
> feedback, the core team went back to the drawing board to determine whether: 
> a) SE-0111 by itself is the right long term answer, b) whether there were 
> alternate models that could solve the same problems in a different way, or c) 
> whether SE-0111 was the right first step to "ultimate glory" in the field of 
> closure parameter labels.  After a long discussion, and many alternatives 
> considered, the core team believes in c), that SE-0111 (with a minor 
> modification) is the right step for Swift 3, because it paves the way for the 
> right model over the long term.
> 
> 8<
> 
> The specific revision requested by the core team to SE-0111 is that all 
> “cosmetic” labels should be required to include an API name of _.  For 
> example, this would not be allowed:
> 
>var op : (lhs : Int, rhs : Int) -> Int
> 
> instead, it should be spelled as:
> 
>var op : (_ lhs : Int, _ rhs : Int) -> Int
> 
> With this change, we believe that we have paved the way for a purely additive 
> proposal (and thus, post-Swift 3) that will restore the expressive capability 
> of closures with parameter labels.  
> 
> 8<
> 
> Here is a sketch of how that would work, in two steps:
> 
> 
> First, we extend declaration names for variables, properties, and parameters 
> to allow *parameter names* as part of their declaration name.  For example:
> 
>var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>x = op(lhs: 1, rhs: 2)   // use of the variable or property.
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // use of the parameter
>}
>foo(opToUse: +) // call of the function
> 
> This will restore the ability to express the idea of a closure parameter that 
> carries labels as part of its declaration, without requiring parameter labels 
> to be part of the type system (allowing, e.g. the operator + to be passed 
> into something that requires parameter labels).
> 
> 
> Second, extend the rules for function types to allow parameter API labels *if 
> and only if* they are used as the type of a declaration that allows parameter 
> labels, and interpret them as a sugar form for providing those labels on the 
> underlying declaration.  This means that the example above could be spelled 
> as:
> 
>var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>x = op(lhs: 1, rhs: 2)  // Same as above
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // Same as above.
>}
>foo(opToUse: +)  // Same as 

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

[Taras Zakharko via swift-evolution]

>   * What is your evaluation of the proposal?

+1. Fully support this change. ‚Optional' comparison operators hide the fact 
that the value is boxes which can lead to confusing behavior and difficult to 
find bugs. Personally, I always unbox my optionals before doing any kind of 
comparisons. 

In fact, I would go a step further and remove != operator as well. It 
can’t distinguish between a situation when inequality holds because an optional 
is nil or inequality holds because optional contains a different value, which 
can also be surprising. IMO, the only non-surprising inequality comparison is 
to a nil value. But I also have to admit that I don’t have a practical example 
where this becomes an issue. 

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?

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

A glance. 

—T

> On 12 Jul 2016, at 20:26, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0121: Remove `Optional` Comparison Operators" begins now 
> and runs through July 19. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

[Taras Zakharko via swift-evolution]

There is some truth in every joke ;) I do like goto though. It makes my C code 
cleaner and easier to maintain. But given that Swift already has a very 
reasonable restricted goto mechanism with labels, I am as happy as it gets :)

— T


> On 12 Jul 2016, at 18:21, Douglas Gregor  wrote:
> 
> 
>> On Jul 12, 2016, at 9:20 AM, Taras Zakharko  wrote:
>> 
>> I’d love to see goto in Swift, but on the other hand, do {} with labels have 
>> so far been sufficient for any practical problem I encountered so far. Goto 
>> is much more useful in languages like C, which lack nested functions and 
>> other abstraction mechanisms. 
>> 
>> Of course, I wouldn’t try to write a high-performance interpreter in Swift 
>> any time soon. 
> 
> *Sigh*.
> 
> Erica was making a joke. There shall be no ‘goto’ in Swift.
> 
>   - Doug
> 
>> 
>> — T
>> 
>>> On 12 Jul 2016, at 18:07, Leonardo Pessoa via swift-evolution 
>>>  wrote:
>>> 
>>> I'd agree with Doug, completely out of scope. The only way I'd support
>>> a goto statement was to jump to another switch case as in C#.
>>> 
>>> L
>>> 
>>> 
>>> On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution
>>>  wrote:
 
 On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution
  wrote:
 
 
 On Jul 11, 2016, at 4:49 PM, Chris Lattner  wrote:
 
 As for all of the other additive changes, I would strongly prefer you to
 *wait* on even proposing or discussing these things until after the Swift
 3.0 evolution cycle is done.  Not only is it distracting for the community,
 but the core team and many others won’t be be able to even read the thread
 or the responses, thus your discussion cycle will be lacking key input.
 
 On this topic, we specifically discussed this when labeled breaks were 
 being
 designed, and when they were expanded to “do” in Swift 2.  We specifically
 decided to allow break but not continue, because we didn’t want these
 control flow statements to be “another way to spell a loop”.
 
 -Chris
 
 
 So I can take it as a given that this is out of scope for Swift 3 too?
 
 https://gist.github.com/erica/a78045d09fa5bb20e6e566295140c84d
 
 
 No, *that* is out of scope for *Swift*.
 
 - Doug
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

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

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

[Taras Zakharko via swift-evolution]

I’d love to see goto in Swift, but on the other hand, do {} with labels have so 
far been sufficient for any practical problem I encountered so far. Goto is 
much more useful in languages like C, which lack nested functions and other 
abstraction mechanisms. 

Of course, I wouldn’t try to write a high-performance interpreter in Swift any 
time soon. 

— T

> On 12 Jul 2016, at 18:07, Leonardo Pessoa via swift-evolution 
>  wrote:
> 
> I'd agree with Doug, completely out of scope. The only way I'd support
> a goto statement was to jump to another switch case as in C#.
> 
> L
> 
> 
> On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution
>  wrote:
>> 
>> On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution
>>  wrote:
>> 
>> 
>> On Jul 11, 2016, at 4:49 PM, Chris Lattner  wrote:
>> 
>> As for all of the other additive changes, I would strongly prefer you to
>> *wait* on even proposing or discussing these things until after the Swift
>> 3.0 evolution cycle is done.  Not only is it distracting for the community,
>> but the core team and many others won’t be be able to even read the thread
>> or the responses, thus your discussion cycle will be lacking key input.
>> 
>> On this topic, we specifically discussed this when labeled breaks were being
>> designed, and when they were expanded to “do” in Swift 2.  We specifically
>> decided to allow break but not continue, because we didn’t want these
>> control flow statements to be “another way to spell a loop”.
>> 
>> -Chris
>> 
>> 
>> So I can take it as a given that this is out of scope for Swift 3 too?
>> 
>> https://gist.github.com/erica/a78045d09fa5bb20e6e566295140c84d
>> 
>> 
>> No, *that* is out of scope for *Swift*.
>> 
>> - Doug
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

[Taras Zakharko via swift-evolution]

There is possible impact on existing code: a switch statement inside a loop, 
that contains a continue.
 
— Taras

> On 11 Jul 2016, at 04:27, Erica Sadun via swift-evolution 
>  wrote:
> 
> A quick pitch to introduce `continue` to switch statements. This would be 
> additive and could not be considered for Swift 3.
> 
> -- E
> 
> Pitch: Introduce continue to Switch Statements
> 
>  
> Introduction
> 
> This pitch completes the switch statement's control flow transfer suite by 
> introducing continue. Doing so provides functionality that a large portion of 
> newer developers expect from (but do not get from) fallthrough.
> 
>  
> Motivation
> 
> Swift's fallthrough statement means "continue by executing the code defined 
> in the next case clause". It has at least one solid use-case, which is 
> demonstrated in this example 
> 
> Swift Evolution discussed removing fallthrough on-list in early December 
>  
> We came to the consensus that fallthroughoffers sufficient utility to retain 
> the feature in the language:
> 
>  
> The
>  Problem with Fallthrough.
> 
> In Swift, fallthrough does not mean: "execute this case and then continue 
> pattern matching", which is what many naive users expect. Given the following 
> code where x is 5, they anticipate the function to print "5" and then 
> "anything else". This is wrong. Swift prints "5" and then "6".
> 
> func test(x : Int) {
> switch x {
> case 5:
> print("5")
> fallthrough
> case 6:
> print("6")
> default:
> print("anything else")
> }
> }
> Fallthrough is better suited for situations like the following:
> 
> case simple where even more subconditions hold: ... do complex things ...; 
> fallthrough
> case simple where subconditions hold: ... do other things ...; fallthrough
> case simple: ... do base things ...
> This example produces a sieve where the most restrictive conditions execute 
> specialized code and then execute code for less restrictive conditions.
> 
> Fallthrough cannot be used for situations like the following example:
> 
> case specialized situation 1: ... code specific to situation 1 ...; 
> fallthrough
> case specialized situation 2: ... code specific to situation 2 ...; 
> fallthrough
> case specialized situation 3: ... code specific to situation 3 ...; 
> fallthrough
> case general: ... general code applicable as well to the three specialized 
> situations ...
> Those coming from C-like languages might have the insight to expect (wrongly, 
> it should be noted) "5", then "6", then "anything else", which is what you'd 
> get with the following flawed C-ish code, where case statements are missing 
> break.
> 
> int x = 5;
> switch (x) {
> case 5: NSLog(@"5"); // no break;
> case 6: NSLog(@"6"); // no break;
> default: NSLog(@"anything else");
> }
> Swift-style switch statements are more powerful and general than C-style 
> switch statements. While I do not endorse C-style switch statements, I do 
> think there's a case to be made for continue, which would mean "continue 
> pattern matching". It would look like this:
> 
> case specialized situation 1: ... code specific to situation 1 ...; continue
> case specialized situation 2: ... code specific to situation 2 ...; continue
> case specialized situation 3: ... code specific to situation 3 ...; continue
> case general: ... general code applicable as well to the three specialized 
> situations ...
> In this example, code that matched general might execute any of the three 
> specialized subconditions as well but would not have to fall through each 
> case. So if a pattern matched scenarios 1 and 3, it would execute those cases 
> and the general case, but not scenario 2.
> 
>  
> The
>  advantages of continue
> 
> If adopted, continue allows code to execute multiple matching patterns
> It naturally reduces code redundancy where fallthrough cannot be used but 
> code applies to multiple cases (such as the 1, 3, and general example above).
> It uses an existing control flow transfer keyword, using it in a reasonably 
> harmonious application that isn't that far out of step with how the keyword 
> is used in other parts of the language.
>  
> Detailed
>  Design
> 
> In the current design, switch statements support subset of control flow 
> transfer:
> 
> control-transfer-statement → break-statement
> control-transfer-statement → fallthrough-statement
> 

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko via swift-evolution]

> On 09 Jul 2016, at 15:25, Goffredo Marocchi  wrote:
> 
> 
> Sent from my iPhone
> 
> On 9 Jul 2016, at 11:31, Taras Zakharko  > wrote:
> 
>> Well, now that function type and function signature are officially separate 
>> things,
> 
> I think we may have made a mistake in doing this and the implementation work 
> is not done yet, so we are in time to reconsider things. Processes are not 
> perfect, I do hope nobody gets too offended if I am suggesting we moved too 
> hastily with this proposal without thinking everything through. It can happen.

You should probably look into the original review thread. The core team made it 
very clear that the core changes in the compiler were made a long time ago and 
that the things were working different from what many (including me) thought. 
There were also some quite compelling reasons for not making label signature 
part of the type. Specifically, look for email by Jordan Rose

> 
>> we need means to treat them as separate things. In particular, we need a way 
>> to force signatures on closure parameters (and maybe on some variables) 
>> while leaving function variables generally signature-agnostic. The proposal 
>> is incomplete in this regard. It attempts to solve one problem but actually 
>> shifts is elsewhere instead. 
> 
> ... hence why I said that this proposal may have been accepted too hastily 
> and if implementing it causes readability/usability/lack of context  problems 
> that is just as important as the hopeful benefits to the compiler. The 
> compiler needs to be allowed to do a good job and helped too, but its job is 
> to help us write better code and this proposal does not convince me as 
> achieving that and is considered incomplete by at least a few others in this 
> very thread too.

The problem is much more complicated than seems at the first glance. Swift 
designers have opened a huge can of worms by making argument labels first-class 
features :) This moves the issues from the formal type domain to linguistic 
domain, and natural language is horribly messy.  After some considerations, I 
believe that the move to separate type and signature is the simplest and 
probably the most reasonable solution (even though it makes me a bit sad), but 
we need some additional mechanism for dealing with closure arguments as well. 
Basically, we need something like a signature type/literal/syntax that enforces 
function signature, no matter the ‚kind‘ of function (func, variable, closure 
arg etc.). 

Dr. Taras Zakharko

taras.zakha...@uzh.ch
IT Officer/Software Development
-
Department of Comparative Linguistics
University of Zurich 
Plattenstrasse 54, CH-8032 Zurich



> 
>> 
>>> I wish the core team or the author of the proposal came to this thread and 
>>> engaged again with the community. 
>> 
>> 
>> I am quite sure that they are discussing this internally :) Also, its 
>> weekend, let people get some rest!
>> 
>> 
>>> On 09 Jul 2016, at 10:56, Goffredo Marocchi via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>> On 9 Jul 2016, at 00:53, Jon Shier >> > wrote:
>>> 
 While I can see why removing the labels from the type system would be a 
 good idea, I don’t see why calling the functions with labels would be 
 actively prohibited. That’s useful information for the developer to have, 
 and if the compiler doesn’t know them in some way, you can be assured 
 Xcode’s autocomplete won’t see them. 
>>> 
>>> I wish the core team or the author of the proposal came to this thread and 
>>> engaged again with the community. 
>>> 
>>> I imagine scenarios of callbacks, say for an image downloader or something 
>>> that ought to happen asynchronously, injected in a method, stored, and then 
>>> used when the asynchronous operation completed one way or the other. 
>>> How does this promote local reasoning so much stressed by Apple itself at 
>>> WWDC when you have to jump through several hoops to have any idea what the 
>>> callbacks does or what parameters and in which order it needs them?
>>> 
>>> The benefits to the compiler should be weighed against the negative effects 
>>> to every day's code and the bugs this may introduce in a safe by default 
>>> promise language like Swift.
>>> 
> On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution 
> > wrote:
> 
> I still say that this is the case where we do take a stand and do ask for 
> this proposal to be blocked and re-analised, I cannot believe that we are 
> going to be addingthis kind of incosistency to the language and take 
> readability/ease of local reasoning (which Apple stressed at the last 
> WWDC once again) away. The community and the 

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko via swift-evolution]

Well, now that function type and function signature are officially separate 
things, we need means to treat them as separate things. In particular, we need 
a way to force signatures on closure parameters (and maybe on some variables) 
while leaving function variables generally signature-agnostic. The proposal is 
incomplete in this regard. It attempts to solve one problem but actually shifts 
is elsewhere instead. 

> I wish the core team or the author of the proposal came to this thread and 
> engaged again with the community. 


I am quite sure that they are discussing this internally :) Also, its weekend, 
let people get some rest!


> On 09 Jul 2016, at 10:56, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPhone
> 
> On 9 Jul 2016, at 00:53, Jon Shier  > wrote:
> 
>> While I can see why removing the labels from the type system would be a good 
>> idea, I don’t see why calling the functions with labels would be actively 
>> prohibited. That’s useful information for the developer to have, and if the 
>> compiler doesn’t know them in some way, you can be assured Xcode’s 
>> autocomplete won’t see them. 
> 
> I wish the core team or the author of the proposal came to this thread and 
> engaged again with the community. 
> 
> I imagine scenarios of callbacks, say for an image downloader or something 
> that ought to happen asynchronously, injected in a method, stored, and then 
> used when the asynchronous operation completed one way or the other. 
> How does this promote local reasoning so much stressed by Apple itself at 
> WWDC when you have to jump through several hoops to have any idea what the 
> callbacks does or what parameters and in which order it needs them?
> 
> The benefits to the compiler should be weighed against the negative effects 
> to every day's code and the bugs this may introduce in a safe by default 
> promise language like Swift.
> 
>>> On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution 
>>> > wrote:
>>> 
>>> I still say that this is the case where we do take a stand and do ask for 
>>> this proposal to be blocked and re-analised, I cannot believe that we are 
>>> going to be addingthis kind of incosistency to the language and take 
>>> readability/ease of local reasoning (which Apple stressed at the last WWDC 
>>> once again) away. The community and the core team just finished 
>>> bikeshedding a huge change to how API's are imported and how labels are 
>>> used and how important they are and then we do this?
>>> 
>>> On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution 
>>> > wrote:
>>> 
 Aw. It's really bad that labels are gone for closures at the call site . 
 IMHO, the same principles that encourage the use of labels for "normal" 
 function calls should prevail here. 
>>> No need to feel bad — if I wasn't ignored (it's hard to notice if this 
>>> happens ;-), the argument has been considered.
>>> 
>>> Additionally, those labels may return in the future — although there is a 
>>> astoundingly long list of features that will be removed because their 
>>> implementation is flawed, and whose fans have been calmed down with the 
>>> argument that they'll be re-added in an improved form later ;-)
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

[Taras Zakharko via swift-evolution]

>   * What is your evaluation of the proposal?

In general +1, except maybe the change of to isOrderedBefore: by: in 
sort-related functions. I fear that the new label makes it less clear that the 
ordering relation is that of strict precedence. It can be particularly 
confusing for people used to other APIs.

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

Well, in the end its an arbitrary decision. Either one works on practice. 
Personally, I don’t see the issue as being very significant. 

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

Yes, it follows the spirit of the naming guidelines

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?


A glance


> On 06 Jul 2016, at 01:10, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0118: Closure Parameter Names and Labels" begins now and 
> runs through July 11. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

[Taras Zakharko via swift-evolution]

I always wrap my case blocks in curly braces. Personally, I agree with G.B. 
that the switch syntax seems inconsistent at best. While there are labels and 
limited form of goto in Swift, case labels don’t act anything like that. I’d 
prefer symmetry with if by having obligatory braces. 

— Taras


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

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

[Taras Zakharko via swift-evolution]

The designers of Swift have adopted a pragmatic approach to things: get a 
language that can be useful practically quickly, then improve it as things go. 
Its very Apple-like and I think it makes a lot of sense. We have a lot of 
useful changes in Swift 3.0, but the language is still far from complete. 
Recent discussions make it very obvious that some fundamental features are 
still in flux or are misunderstood (e.g the function argument label 
discussion), and the generics implementation has a lot of important stuff 
missing. Freezing Swift now  would mean suspending it in a beta state. 

So, no, a strong disagree with the premise of this thread from me. 

Best, 

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

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko via swift-evolution]

I would also be interested in a clarification on this point from Chris or 
someone else from the core team. 

The accepted proposal states that labels are illegal in function types (that is 
also what I was arguing for towards the end of  the review discussion) but at 
the same time Cris mentions that cosmetic labels are allowed in closure types 
(which for me is synonymous with function types). So which one is it and how 
does this change affect closure parameters?

Best, 

 Taras


> On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> Hey Charlie,
> 
> The change you reference and this must work together, I have a hard time 
> accepting that we will have a Swift 3 with this change in and no other change 
> that balances it.
> 
> If this
> 
> function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {
> 
> [...]
> 
> callback(20,40, true)
> 
> }
> 
> is the style we have to use with callbacks from now on, it will be a major 
> regression I would advise a proposal to stop right now.
> The closure passed around and arriving as a callback there gives me NO clue 
> how to send data to it. How is that for local reasoning?
> This makes me believe/hope that I am getting it all wrong, so please correct 
> me here :D.
> 
> If it is not true, then I am blowing things out of proportion and I apologise 
> for this to everyone on the list.
> 
> 
> Sent from my iPhone
> 
> On 7 Jul 2016, at 08:41, Charlie Monroe  > wrote:
> 
>> There was a fair proposal by Brent 
>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939 
>> ) of adding 
>> the labels to the name of the variable rather than adding it to the type. 
>> And I agree with that since it simplifies the type system.
>> 
>> Unfortunately, since Swift 3 is making all the code-breaking changed and 
>> Brent's counterproposal is additive, it leaves at least a year-long period 
>> of not having the parameter labels in closures.
>> 
>> I agree with the change, I don't agree with the timing where it doesn't have 
>> a replacement yet.
>> 
>>> On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution 
>>> > wrote:
>>> 
>>> This feels like making the language a lot worse. Lots of time was recently 
>>> spent bikeshedding methods names and argument labels and this proposal bans 
>>> labels use in some cases and encourage people not to use them in others.
>>> 
>>> On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution 
>>> > wrote:
>>> 
 func needsCallback(callback: (a: Int, b: Int) -> Void) {
 callback(a: 1,b: 2)
 }
 
 
 func needsCallback(callback: (Int, Int) -> Void) {
 callback(1, 2)
 }
 
 Is the first one will be forbidden?
 So you'd like to keep the second one?
>>> 
>>> I do not understand why someone would want the second example. A great 
>>> point of both Objective-C and Swift was enforcing parameter labels use to 
>>> make the code more readable. 
>>> 
>>> What if that callback were to need width and height? How is that clear 
>>> which parameter I need to pass in which order?
>>> 
>>> Considering Swift 3 is our last big chance to break code and fixing the 
>>> effects of this proposal would break quite a bit of code again... this is a 
>>> choice it would impact the language for a long time. 
>>> 
>>> 
> 在 2016年7月7日，11:06，Chris Lattner via swift-evolution 
> > 写道：
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> 
> 
> The review of "SE-0111: Remove type system significance of function 
> argument labels " ran from June 30 ... July 4, 2016. The proposal has 
> been *accepted*:
> 
> The community and core team agree that this proposal will lead to a 
> simplification and clarification of the type system, as well as a more 
> clear user model for parameter labels.  In response to community 
> feedback, the core team is accepting the proposal with a revision to 
> allow “purely cosmetic” parameter labels in closure types for 
> documentation (as outlined in the alternatives section).  The core team 
> also wants to clarify that a call to a value of closure type would not 
> allow use of any parameter labels, some interpretations thought that 
> “arbitrary” parameter labels could be used.
> 
> Thank you to Austin Zheng for driving this discussion forward!  I filed 
> SR-2009 to track implementation work on this.
> 
> -Chris Lattner
> 

Re: [swift-evolution] Bit arrays

[Taras Zakharko via swift-evolution]

> On 04 Jul 2016, at 00:44, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 3, 2016, at 2:42 PM, Daryle Walker via swift-evolution 
>>  wrote:
>> 
>> Since objects aren't addressable by default, there wouldn't be the problems 
>> with a bit-packed Boolean collection that C++'s "vector" has. Does 
>> "[Bool]" currently have the option of packed optimization, or would  it have 
>> to be added via a proposal?  Or does it have to be a separate type instead?
> 
> It has to be a separate “bitvector” type.
> 
> FWIW, C++’s vector optimization is widely considered to be a bad idea, 
> and many people have talked about trying to remove it from the C++ standard 
> entirely.

AFAIK, the problem lies within the vector implementation. Other 
bit-packed implementations (e.g. boost:dynamic_bitset) are much more efficient. 
In certain cases, there are performance advantages to the bit packed 
representation as it is more cache-friendly. 

That said, I don’t think that such specialised data structures should be part 
of the standard library. I’d leave this to a third-party solution.

— Taras 

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

Re: [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing

[Taras Zakharko via swift-evolution]

Swift already has a very useful goto operator that avoids the usual problems 
associated with arbitrary control flow. With labels and continue/break you can 
implement very complex control flow schemas, but still maintain structured 
code. I have used it at multiple occasions and this is something I absolutely 
adore about Swift. 

— Taras

> On 03 Jul 2016, at 03:27, Daryle Walker via swift-evolution 
>  wrote:
> 
> Rust and Ada (and probably others) have a iteration statement that 
> specifically goes on forever, instead of using a convention of a 
> “while”/“repeat-until”/“for" with a never-exiting test.  It’s called “loop.”  
> Would that be a good idea to add instead of continuing to use convention?  (I 
> don’t know if the compiler does infinite-loop optimization, or if it can 
> detect it through a “while true” or similar convention.)  Maybe we can label 
> a function “@noreturn” (or whatever) if it ends with a loop that doesn’t have 
> a jump statement in it (or flag an error for such loops).
> 
> Although some consider it harmful, should we add a “goto” statement?  We 
> would need to support labeling any statement, of course.  Besides needing the 
> destination label to be in the same innermost function block as the goto, 
> what other gotchas (skipping initialization and/or destruction) do we have to 
> watch for?  How would it interact with “guard”?  I would also propose a “goto 
> LABEL case EXPRESSION,” where the LABEL marks a “switch” statement that 
> surrounds the goto statement and reevaluates the switch with the new value.  
> This would help with case jumping too complex for “fallthrough” to work 
> (including jumping FROM a “default” case).
> 
> [I was going the ponder on generalizing the “zip2” stuff to more-than-two 
> sources, but that requires variadic generics and other people have already 
> got ideas for this.]
> 
> Should we have double (or multiple or predicate) dispatch added?  Or course, 
> both preferring methods to free functions and defining methods within types 
> (especially classes and protocols) bias for single dispatch.  We would have 
> to switch back to preferring free functions or have some sort of “[object1, 
> object2].myMethod” form of dispatch.  And it would go beyond what Objective-C 
> does (I think).
> 
> [OK, I saw “predicate dispatch” on Wikipedia while looking up multiple 
> dispatch, and I don’t quite understand it (yet).]
> 
> When I read an article at 
>   
> >,
>  I was surprised at Swift doesn’t make objects addressable by default.  The C 
> family assumes being able to do this, and therefore forfeits any 
> optimizations from non-addressable objects.  But I remembered that Ada also 
> does this; you have to explicitly mark objects as addressable (with the 
> “aliased” keyword).  Should we allow users to mark objects, including blocks 
> of objects, as always-addressable?  Or keep addressability as automatic, via 
> certain functions?
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

[Taras Zakharko via swift-evolution]

> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

In principle +1, but I’d prefer if the proposal also included rounding with a 
specified precision. I.e.

func rounded(_ rule: RoundingRule = toNearestOrAwayFromZero, decimalPlaces 
digits: Int = 0) -> Self



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

yes

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

yes

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

yes. I like how the proposal accounts for the rounding rule. However, what is 
missing is rounding with specified precision

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

glance

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

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko via swift-evolution]

Jordan, Thanks for the very insightful explanation! It all makes a lot of sense 
in perspective. 

Apparently I was thinking about this issue a bit while I was sleeping, and now 
it seems to me that part of the problem is because one strives for the function 
signature to be linguistically meaningful (as in natural language meaningful). 
It was mentioned that argument labels often don’t make much sense when detached 
from the function name, and that some function seem to have semantically 
compatible signatures and some don’t, e.g. the example of  drawLineTo(x: Float, 
y: Float) and drawLineWith(angle: Float, distance: Float)

So this is actually a linguistic problem. More precisely, its a problem of 
predicate frames/argument semantics. Consider verbs like ‚hit' and ‚kill'. In 
term of precise semantics, we can model them as something like

kill(killer:victim:)
hit(hitter:victim:)

However, the actual status of the arguments here is compatible. Both verbs 
describe asymmetric actions, with one argument playing an active role in 
(negatively) changing the state of the other , passive one. So both are 
compatible with a broad metatype (what we often call predicate type in 
linguistics)

P(agent:undergoer:)

However, there are plenty of verbs that are quite different. Like 
go(person:to). Also two arguments, but the semantic status of them is very 
different. 

If that is really the case, then there is indeed no general solution which 
keeps the argument labels semantically meaningful. But there is still a 
potential conflict with the tuple/function signature labels.  
The only reasonable choice that comes to my mind is to completely drop argument 
labels in closure variables and just look at the argument type. Basically, by 
assigning function variables, we drop any semantics and just look at the 
overall structure (cardinality/argument types)

 In more detail:

1. Maintain that argument labels are not part of the type, but merely hints for 
the function dispatch/programmer convenience
2. Disallow argument labels in closure variables.  I.e.:

var fun = drawLineTo(x:y:) 

   has type (Float, Float) -> (), which makes the variable explicitly 
compatible with any  function of cardinality 2 that takes Float arguments. At 
the sae time, any declaration like 

var fun : (x: Float, y: Float) -> () 

   should be illegal. This further makes clear that tuples and functions are 
not the same thing. 


3. In the long term, maybe consider removing labels from tuples. At the same 
time, there should be a new mechanism in place that allows one to elevate 
tuples to structs, with properties taking the role of the current tuple labels 
(like Python’s namedtuple)

An alternative, in order to keep the cake and eat it too, would be something 
along the lines of making predicate types explicit. E.g. creating some sort of 
function ‚semantic metatype‘ and declaring function conformance to this 
metatype. But I can’t imagine that it is a good idea. Natural languages are 
really not a good source of inspiration in this regard. 

Best, 

 Taras


> On 01 Jul 2016, at 05:33, Jordan Rose <jordan_r...@apple.com> wrote:
> 
>> 
>> On Jun 30, 2016, at 13:36, Taras Zakharko via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On 30 Jun 2016, at 22:11, Austin Zheng <austinzh...@gmail.com 
>>> <mailto:austinzh...@gmail.com>> wrote:
>>> 
>>> As for the label semantics, Swift's current behavior is actively 
>>> misleading, please see the example in the prior email. There are no 
>>> meaningful semantics in the label, because implicit conversion between 
>>> differently-labeled function types means that there is no way to usefully 
>>> enforce these invariants to begin with.
>> 
>> That is a good point. I admit to not knowing this (I strongly expected that 
>> labels would be semantically meaningful). But what exactly is the status of 
>> the argument labels than in Swift? Just a documentation device  for the 
>> programmer and a  hint for the compiler to do function dispatch? But if the 
>> compiler indeed does dispatch on argument labels, then they are not 
>> completely void of semantics, are they?  As I mentioned before, I think the 
>> problem here is much deeper. 
>> 
>> The state of affairs I would prefer is something along these lines:
>> 
>> 1. Labels are semantically meaningful
>> 2. There is an explicit casting system for function signatures
>> 3. This casting system should be in close correspondence to tuples. The 
>> "function argument lists look sort of like tuples“ is a very compelling 
>> reason actually, because of the principle of the least surprise. If I have 
>> two things in the language that look very similar,

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Taras Zakharko via swift-evolution]

IMO, this is the most mathematically meaningful and semantically transparent 
solution. Floor and ceiling might be the popular terms but roundedUp/Down is 
much cleaner. 


> On 25 Jun 2016, at 20:55, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 25 Jun 2016, at 11:06, Karl via swift-evolution 
>> > wrote:
>> 
>> floor() and ceil(), exactly like C. ceiling() is more descriptive and is a 
>> mathematical term of art .
>> nextIntegralUp() and nextIntegralDown() are more descriptive still, but 
>> possibly misleading as (4.0).nextIntegralUp() == 4.0
> I'm in favour of these capabilities being there, but in terms of naming I've 
> often wondered why it can't just be part of a rounding group of methods like 
> so:
> 
>   func roundedUp() -> Self { … }
>   func roundedUp(withPrecision:Int) -> Self { … }
>   func roundedDown() -> Self { … }
>   func roundedDown(withPrecision:Int) -> Self { … }
> 
> Since the methods with implied precision of zero are equivalent to floor and 
> ceiling surely? I know floor and ceiling are pretty common terms, but they're 
> just a form rounding when it comes down to it.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko via swift-evolution]

> On 30 Jun 2016, at 22:38, Austin Zheng <austinzh...@gmail.com> wrote:
> 
> You might like the alternative I added 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>).
>  It basically goes the other way: keep the semantic significance of labels, 
> and make them mean something by prohibiting converting between different 
> function types with the same types but different labels.

Yes, thats what I would vote for! I would also add the possibility of 
explicitly converting between different labels, as long as the types match, 
e.g.:

battingAveragePredicate = sinkBattleship as ((ofHits: Int, forRuns: Int) -> 
Bool)

or 

battingAveragePredicate = sinkBattleship as typeof(battlingAveragePredicate)


(whatever the correct syntax for this would be).


Best, 

 t. 




> On Thu, Jun 30, 2016 at 1:36 PM, Taras Zakharko <taras.zakha...@uzh.ch 
> <mailto:taras.zakha...@uzh.ch>> wrote:
> 
>> On 30 Jun 2016, at 22:11, Austin Zheng <austinzh...@gmail.com 
>> <mailto:austinzh...@gmail.com>> wrote:
>> 
>> As for the label semantics, Swift's current behavior is actively misleading, 
>> please see the example in the prior email. There are no meaningful semantics 
>> in the label, because implicit conversion between differently-labeled 
>> function types means that there is no way to usefully enforce these 
>> invariants to begin with.
> 
> That is a good point. I admit to not knowing this (I strongly expected that 
> labels would be semantically meaningful). But what exactly is the status of 
> the argument labels than in Swift? Just a documentation device  for the 
> programmer and a  hint for the compiler to do function dispatch? But if the 
> compiler indeed does dispatch on argument labels, then they are not 
> completely void of semantics, are they?  As I mentioned before, I think the 
> problem here is much deeper. 
> 
> The state of affairs I would prefer is something along these lines:
> 
> 1. Labels are semantically meaningful
> 2. There is an explicit casting system for function signatures
> 3. This casting system should be in close correspondence to tuples. The 
> "function argument lists look sort of like tuples“ is a very compelling 
> reason actually, because of the principle of the least surprise. If I have 
> two things in the language that look very similar, then its very confusing if 
> they  exhibit very different behaviour. Again, I am not proposing that one 
> goes back to model functions in terms of tuples. But as long as there is a 
> surface resemblance (and an obvious morphisms between the two), at least some 
> aspects of their design should be kept in sync. 
> 
> But again, this touches on some deep design decisions for the language, so I 
> — as an amateur — don’t feel in my plate discussing this here. I believe that 
> there currently might be some inconsistencies in the language design that 
> should be sealed with (but maybe they are no inconsistencies at all and I 
> simply have false expectations). 
> 
> Best, 
> 
>  Taras
> 
>> 
>> On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On 30 Jun 2016, at 21:20, Xiaodi Wu <xiaodi...@gmail.com 
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution 
>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> >
>>> > Hello Swift community,
>>> >
>>> > The review of "SE-0111: Remove type system significance of function 
>>> > argument labels" begins now and runs through July 4. The proposal is 
>>> > available here:
>>> >
>>> >   
>>> > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>>> >  
>>> > <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
>>> >
>>> >   * What is your evaluation of the proposal?
>>> 
>>> -1
>>> 
>>> >   * Is the problem being addressed significant enough to warrant a 
>>> > change to Swift?
>>> 
>>&g

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

[Taras Zakharko via swift-evolution]

>   * What is your evaluation of the proposal?

+1

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

Yes

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

Yes

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

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

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

[Taras Zakharko via swift-evolution]

> On 29 Jun 2016, at 15:47, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> IIRC Optional conformed to this protocol early on and that conformance was 
> removed.  In practice the idea of a protocol for "truthiness" to which 
> non-Boolean types conform caused more confusion than it provided value.  It 
> was a cool idea that just didn't work out so well.
> 
> IMO if it doesn't make sense for Optional to conform it is pretty unlikely it 
> would make sense for other types to conform.  It seems like a good idea to 
> remove the protocol.

I certainly agree that it doesn’t make much sense for Optional, but I believe 
that implicit bool conformance can be a desirable feature for a number of 
applications. For instance, imagine a logical inference library where you can 
have entities like Term or Formula. For those, Boolean conformance would make a 
lot of sense. Of course, one can also make explicit conversions e.g.:

extension Bool {
 init(x: Term) { self = x.truthValue }
}

if Bool(f1) { … }

But since Bool is a syntactically privileged construct in the language, it 
makes sense to have it as a target of built-in type conversion support, for the 
same reason why we have CustomStringConvertible etc. 

To be honest, I’d prefer to have a generic mechanism such as:

ImplicitConvertible {
var as -> T { get }
} 

to replace the Custom*Convertible and friends, but thats a different topic. 

— Taras

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

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

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

[Taras Zakharko via swift-evolution]

Just a quick clarification: I was under impression that the utility of Boolean 
was that one could extend any type to behave as a boolean type and thus be used 
in control flow constructions etc. Not something that has to do often, but nice 
to have nevertheless. I would be sad if this functionality were to go. At the 
same time, I understand the rationale behind this proposal. Maybe we could 
introduce something like CustomBoolConvertible instead (if not yet suggested)?

Best, 

 Taras


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

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

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

[Taras Zakharko via swift-evolution]

> On 09 Jun 2016, at 18:53, Ethan Eberle via swift-evolution 
>  wrote:
> 
> That said, the one process improvement I have is that proposals should 
> ideally only be “Accepted” by the core team as it is originally written (or 
> with relatively minor changes) or completely “Rejected”.  The “Accepted with 
> Revision” approach can result in new ideas being approved but not being fully 
> vetted by the community.   This also eliminates needless "surprises", which 
> is always good. Proposal are either accepted or rejected, nothing in between. 
> I actually think this approach is win-win for the core team and the community 
> – although the ultimate decision to reject or approve a proposal must rest 
> with the Core Team. 

I disagree, for practical reasons. There is only a  limited time that the Swift 
team can spend looking at proposals. We already have the situation where a lot 
of important features (like the full-feature generics) are being postponed from 
Swift 3. While it is true that your suggestion would result in a more 
transparent review process, it would also vastly increase the amount of time 
until the decision is reached. 

The core team has shown over and over again that it is able to make very sane 
and reasonable decisions, which wouldn’t be made if the community reviews would 
be the only source of input. 

Best, 

 Taras

> 
> Sent from my iPhone.
> 
> On Jun 9, 2016, at 12:35 PM, L. Mihalkovic via swift-evolution 
> > wrote:
> 
>> 
>> 
>> On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon >> > wrote:
>>> 
> I believe large syntax changes should have more discussion from more 
> developers and not a very small subset of them. The review announcement 
> needs to be broader: the swift blog needs to announce it so more people 
> know.
 
 No.
>>> 
>>> G
>>> 
 
 Firstly, for those who cannot follow the list—and I can't say I blame 
 them—the -announce list already allows them to ignore everything except 
 the beginnings of reviews. Anyone who wants to (and who speaks English) 
 can be notified of any significant proposed change to the language and can 
 submit their comments for the core team's consideration. That is enough.
>>> 
>>> I think your perspective is flawed here. You are precisely one of the "top 
>>> developers" I have been referring to. Am I surprised this is your opinion? 
>>> Not one bit.
>> 
>> But if you followed the email trail you must have noticed that the final 
>> choice was not what brent supported. I would even say that it was not any of 
>> the solutions anyone proposed.. Proof that the process worked, the team made 
>> a change nobody anticipated, yet many people can (partially) identify with. 
>> 
>>> 
>>> Mailing lists are a rather old thing...and I think many will find them 
>>> daunting or maybe somewhat annoying with all of the announcements. How many 
>>> people are subscribed to announce? It does not seem like many because 
>>> well...we don't always get a lot of feedback. We get feedback from the same 
>>> people over and over. How is this enough? How is this enough variety?
>>> 
>>> Just because "announce" is more palatable does not mean that it is being 
>>> used in the way you are describing. 
>>> 
>>> Maybe there is another problem then: people afraid to share their opinions 
>>> publicly. I wonder why this would be.
>>> 
 The purpose of reviews is not to cast ballots for or against a feature. It 
 is to submit arguments, for and against, for the core team to consider as 
 they decide whether and how to address the problem the proposal's 
 "Motivation" section describes. For that purpose, there is no need to 
 collect hundreds or thousands of reviews, and if we did, the review 
 manager would be swamped anyway. It is enough to get a reasonable variety 
 of eyes, from a reasonable variety of perspectives, on the problem.
>>> 
>>> Why do people keep saying I am asking for: "hundreds or thousands" of 
>>> reviews? I am just asking for something like 20 - 25 unique people's 
>>> feedback. We are not getting that. We get the same people over and 
>>> over...which makes the feedback seem screwed to this small group's 
>>> philosophies.
>>> 
>>> Getting feedback from the same ~10 people is not a "reasonable variety of 
>>> eyes" in my opinion. That is a very small sample. And that sample is 
>>> usually those who are very technically skilled...who I would say do not 
>>> always design the best interfaces.
>>> 
 I think that has happened here. We have not heard from every perspective, 
 but we have heard from enough of them that adding more will not help all 

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

[Taras Zakharko via swift-evolution]

A concern that I have with this is that comma seems to get inconsistent 
treatment in the language. In conditionals, commas clearly represent 
conjunctive clauses. However, the core team has also argued (review of SE-0095) 
that usage of comma implies disjunction and proposes that ‚&‘ is used for 
specifying intersection (conjunction) of types. So which is it? If we want to 
be 100% consistent, we should either adopt commas as conjunction through the 
language, or, use &/&& for conjunction. Personally, I have no problems 
accepting commas as conjunction.

— Taras


> On 09 Jun 2016, at 03:47, Joe Groff via swift-evolution 
>  wrote:
> 
> The review of SE-0099 "Restructuring Condition Clauses" ran from January 
> 13...18, 2016. The proposal has been accepted with revision for Swift 3. 
> There was near unanimous agreement that the Swift 2 grammar was inconsistent 
> and ambiguous and should be changed; most of the disagreement centered on 
> how. Many alternatives were discussed, including the following:
> 
> - The proposal as written suggests using ';' or newline as a separator. To 
> many people, this looked heavy, and it's also inconsistent with the rest of 
> the language, which never otherwise used semicolon as an intra-statement 
> separator (except in the defunct for;; loop).
> - Introducing a keyword separator, such as using 'where' everywhere or 
> introducing a new 'and' keyword, is also bulky and either reads poorly or 
> requires stealing new keywords.
> - Some commenters suggested using '&&' for consistency with simple boolean 
> conditions. This isn't workable due to precedence issues.
> - The ambiguities arise from the fact that there are comma-separated lists 
> within comma-separated lists—within the list of conditions, each 'case' or 
> 'let' condition can have multiple declarations. If we eliminated this 
> feature, so that every 'case' or 'let' condition had to start with 'case' or 
> 'let', the ambiguity is resolved, and comma can remain the condition 
> separator. This does break consistency with non-conditional 'let' 
> declarations and case clauses in 'switch' but is otherwise workable.
> 
> Of these alternatives, the core team found the last one to be the best 
> choice. 'case' and 'let' conditions should each specify a single declaration, 
> comma should remain the condition separator, and the 'where' keyword can be 
> retired from its purpose as a boolean condition introducer. Some code becomes 
> more verbose, but in common formatting patterns, it aligns more nicely, as in:
> 
>   guard
> let x = foo(),
> let y = bar(),
> let z = bas(),
> x == y || y == z else {
>   }
> 
> and though it breaks commonality between 'let' conditions and 'let' 
> declarations, it's more important to preserve higher-level consistency 
> throughout the language in how components of expressions and statements are 
> separated. Thanks everyone for the discussion, and thanks Erica and Chris for 
> the proposal! Since, aside from the approved syntax, the fundamental thrust 
> of the proposal remains the same, Chris has volunteered to revise it to be in 
> line with the approved decision.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Add conversion String -> Bool

[Taras Zakharko via swift-evolution]

IMO, that is too idiosyncratic to be a standard language feature. You should 
extend Bool based on the specific needs of your application. Thats what the 
extensions are for. 

Best, 

 t. 

> On 04 Jun 2016, at 15:10, Arsen Gasparyan via swift-evolution 
>  wrote:
> 
> Hello,
> 
> It would be great if we had `init?(_ text: String)` for Bool class. Because 
> sometime when you're processing JSON/XML it can help you a lot.
> 
> Examples:
> 
> Bool("true") -> true
> Bool("false") -> false
> Bool("TrUE") -> true
> Bool(" true ") -> nil
> Bool("1") -> nil
> Bool("Y") -> nil
> Bool("whatever") -> nil 
> 
> 
> via https://bugs.swift.org/browse/SR-1282 
> 
> 
> Thanks.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 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] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Taras Zakharko via swift-evolution]

I never had any problems with commas, as I always read them as conjunctive 
clauses, but I understand that an explicit conjunction may be less confusing. 
Personally, I’d prefer if there was no special syntax (aka Any<>) for 
existential types, whether generalised or not. I fail to see a principal 
difference between an existential type vardecl and a non-existential type 
vardecl: both can be described as sets of factual types, with non-existential 
declarations trivially being sets of cardinality one. Under this perspective, 
adopting different syntax for these cases feels like an idiosyncratic decision 
to me. I also disagree that Any<> makes existential types more readable, on 
contrary, they introduce visual clutter. A considerably complex existential 
definition could always be hidden behind a typealias.

Ideally, I’d like ALL type references in variable declarations be treated as 
existentials: the variable is declared as belonging to a certain set of factual 
types (in most cases this will trivially be a single factual type). IMO, this 
would result in a simple and concise system. It would also make type-erased 
wrappers unnecessary, simplifying the language. 

Best, 

 Taras


> On 02 Jun 2016, at 07:42, Austin Zheng via swift-evolution 
>  wrote:
> 
> Excellent.
> 
> I put together a PR with a revised proposal containing the core team's 
> recommended approach. If anyone is curious they can see it here: 
> https://github.com/austinzheng/swift-evolution/blob/ef6adbe0fe09bff6c44c6aa9d73ee407629235ce/proposals/0095-any-as-existential.md
>  
> 
> 
> Since this is the de-facto second round discussion thread, I'll start with my 
> personal opinion (which is *not* reflected in the PR): the '&' separators in 
> lieu of commas are a good idea, but I would still prefer the types to be 
> wrapped in "Any<>", at least when being used as existentials.
> 
> My reasons:
> 
> - Jordan Rose brought up a good point in one of the discussion threads today: 
> a resilience goal is to allow a library to add an associated type to a 
> protocol that had none and not have it break user code. If this is true 
> whatever syntax is used for existentials in Swift 3 should be a valid subset 
> of the generalized existential syntax used to describe protocol compositions 
> with no associated types.
> 
> - I would rather have "Any<>" be used consistently across all existential 
> types eventually than have it only be used for (e.g.) existential types with 
> `where` constraints, or allowing two different representations of the same 
> existential type (one with Any, and one without).
> 
> - I think any generalized existential syntax without delimiting markers (like 
> angle braces) is harder to read than syntax with such markers, so I would 
> prefer a design with those markers.
> 
> Best,
> Austin
> 
>> On Jun 1, 2016, at 10:17 PM, Chris Lattner > > wrote:
>> 
>> 
>>> On Jun 1, 2016, at 9:53 PM, Austin Zheng >> > wrote:
>>> 
>>> This was indeed a very thorough review by the core team. I'll prepare a v2 
>>> proposal with this feedback taken into account so we can continue moving 
>>> things along.
>>> 
>>> One quick question - is making whatever syntax is chosen for Swift 3 
>>> "forward-compatible" with a future generalized existential feature a 
>>> concern?
>> 
>> Yes it is a concern, but we assume that the “X & Y” syntax will always be 
>> accepted going forward, as sugar for the more general feature that is yet to 
>> be designed.
>> 
>> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Enhanced existential types proposal discussion

[Taras Zakharko via swift-evolution]

This looks very nice!

Two questions/comments

1. I would prefer to write simpler existential types without Any, e.g.:

  let a: Sequence where Sequence.Iterator.Element == Int

Is there a reason why we need Any<> at all, aside as a parsing aid?

2. If this proposal gets accepted, does it mean that type-erased wrappers like 
AnySequence become superfluous? They always struck me as a hack, used only to 
overcome the limitations of the type system. 

Best, 

 Taras



> On 26 May 2016, at 07:53, Austin Zheng via swift-evolution 
>  wrote:
> 
> The inimitable Joe Groff provided me with an outline as to how the design 
> could be improved. I've taken the liberty of rewriting parts of the proposal 
> to account for his advice.
> 
> It turns out the runtime type system is considerably more powerful than I 
> expected. The previous concept in which protocols with associated types' APIs 
> were vended out selectively and using existentials has been discarded.
> 
> Instead, all the associated types that belong to an existential are 
> accessible as 'anonymous' types within the scope of the existential. These 
> anonymous types are not existentials - they are an anonymous representation 
> of whatever concrete type is satisfying the existential's value's underlying 
> type's associated type.
> 
> This is an enormous step up in power - for example, an existential can return 
> a value of one of these anonymous associated types from one function and pass 
> it into another function that takes the same type, maintaining perfect type 
> safety but without ever revealing the actual type. There is no need anymore 
> to limit the APIs exposed to the user, although there may still exist APIs 
> that are semantically useless without additional type information.
> 
> A set of conversions has also been defined. At compile-time 'as' can be used 
> to turn values of these anonymous associated types back into existentials 
> based on the constraints defined earlier. 'as?' can also be used for 
> conditional casting of these anonymously-typed values into potential actual 
> types.
> 
> As always, the link is here, and feedback would be greatly appreciated: 
> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md
>  
> 
> 
> Best,
> Austin
> 
> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPad
> 
> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution 
> > wrote:
> 
> >> One initial bit of feedback -  I believe if you have existential types, I 
> >> believe you can define Sequence Element directly, rather than with a type 
> >> alias. e.g.
> >>
> >> protocol Sequence {
> >>  associatedtype Element
> >>  associatedtype Iterator: any >> IteratorProtocol.Element==Element>
> >>  associatedtype SubSequence: any >> Element>
> >>  …
> >> }
> >
> > That's not really the same thing. Any is an existential, 
> > not a protocol. It's basically an automatically-generated version of our 
> > current `AnyIterator` type (though with some additional flexibility). It 
> > can't appear on the right side of a `:`, any more than AnyIterator could.
> 
> After this proposal you should be able to use these existentials anywhere you 
> can place a constraint, so it would work.  You can do this with the protocol 
> composition operator today and the future existential is just an extension of 
> that capability.
> 
> >
> > What *would* work is allowing `where` clauses on associated types:
> >
> >> protocol Sequence {
> >>  associatedtype Element
> >>  associatedtype Iterator: IteratorProtocol where Iterator.Element==Element
> >>  associatedtype SubSequence: Sequence where SubSequence.Element == Element
> >>  …
> >> }
> >
> > I believe this is part of the generics manifesto.
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

[Taras Zakharko via swift-evolution]

When I need a loop with complex control flow that does not fit into the 
classical while {} or repeat {} while structure, I use this:

do_stuff: do {
  …
  continue do_stuff
} 

This pattern explicit and allows very complex control flow patterns without the 
drawbacks of the unrestricted goto construct. 

Therefore I don’t see utility with having a repeat {} without while clause. 

Best, 

 Taras


> On 10 May 2016, at 22:39, Dominik Pich via swift-evolution 
>  wrote:
> 
> 
>>> On May 10, 2016, at 3:30 PM, Tyler Cloutier via swift-evolution 
>>>  wrote:
>>> 
>>> Secondly it’s a very simple way of introducing new programmers to loops. 
>>> It’s IMHO more clear to a new programmer that repeat will just repeat 
>>> indefinitely vs while true.
>> 
>> This point seems strange to me - why teach a new programmer about loops by 
>> first showing them a looping construct they should probably never use in 
>> actual practice until they really know what they’re doing?
> totally agree… it would be a bad first introduction, id say :)
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 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] [Draft] Expanded min/max algorithms

[Taras Zakharko via swift-evolution]

Hi Nate, 

 I think this is a very useful addition! I also had a related proposal few days 
ago: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html
 

 
 I feel like min/max extension and element order belong to the same family of 
enhancements. If you are interested, maybe we can combine them together into a 
single proposal? 

Best, 

 Taras


> On 17 Apr 2016, at 08:44, Nate Cook via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> Attached is a draft of a proposal to expand the min and max sequence APIs to 
> better handle collections and to support future sorted sequences/collections. 
> The proposal is in a gist here 
>  and 
> inlined below—would love to hear any comments or feedback before submitting 
> the proposal.
> 
> Nate
> 
> 
> Proposal: Expanded min/max algorithms
> This proposal would expand on the min() and max() sequence methods to add 
> methods that return the corresponding index for a collection, efficiently 
> find the minimum and maximum elements or indices at the same time, and 
> provide extension points for sorted collections to provide all these results 
> more efficiently.
> 
> Related Bugs: SR-889  and SR-890 
> 
> Motivation
> The Sequence protocol currently offers min() and max() methods that return 
> the minimum and maximum elements of a sequence or collection. Unfortunately, 
> there are applications where these methods do not provide enough flexibility 
> to be useful.
> 
> First, if the user of a collection wants not just to get the minimum value 
> but also to operate on it in some way (e.g., mutation or just accessing it 
> multiple times), she would need the index of the minimum element. The current 
> APIs don't support that, so she would need to write her own.
> 
> Second, the writer of a sorted collection is currently unable to provide 
> efficient responses to the min() and max() methods when used in a generic 
> context, even though these should be O(1) operations. Just like Set can 
> respond quickly to contains(_:) even in a generic context, so too should new 
> sorted collections be able to optimize their responses.
> 
> Finally, getting the minimum and maximum elements (or indices) of a 
> collection or sequence currently requires calling both min() and max(). With 
> two calls, every element is iterated and compared twice. When you need both 
> results, finding both the minimum and the maximum at the same time is more 
> efficient, requiring only a single pass and 25% fewer comparisons.
> 
> Proposed solution
> This proposal has three parts:
> 
> Adding minIndex() and maxIndex() methods to Collection that return the index 
> of the minimum and maximum elements, respectively.
> 
> let numbers = [30, 40, 10, 20, 60, 50]
> 
> if let i = numbers.minIndex() {
> print("\(i): \(numbers[i])")   // 2: 10
> }
> Adding minmax() and minmaxIndices() methods to Sequence and Collection, 
> respectively, to calculate the values (or indices) of the minimum and maximum 
> elements simultaneously.
> 
> if let result = numbers.minmax() {
> // result == (minimum: 10, maximum: 60)
> // ...
> }
> if let i = numbers.minmaxIndices() {
> // i == (minimum: 2, maximum: 4)
> print("\(i.minimum): \(numbers[i.minimum])")
> }
> Adding customization points for sequences and collections that can offer more 
> efficient results: 
> _customMinComparableElement()/_customMaxComparableElement() for Sequence and 
> _customIndexOfMinComparableElement()/_customIndexOfMaxComparableElement()for 
> Collection.
> 
> Detailed design
> The following methods would be added to the visible public APIs of Sequence 
> and Collection as default implementations.
> 
> extension Sequence {
> /// Returns the minimum and maximum values of `self`, using 
> /// `isOrderedBefore` to compare elements, or `nil` if the sequence
> /// has no elements.
> func minmax(@noescape isOrderedBefore isOrderedBefore: 
> (Iterator.Element, Iterator.Element) throws -> Bool
> ) rethrows -> (min: Iterator.Element, max: Iterator.Element)?
> }
> 
> extension Sequence where Iterator.Element: Comparable {
> /// Returns the minimum and maximum values of `self`, or `nil` 
> /// if the sequence has no elements.
> func minmax() -> (min: Iterator.Element, max: Iterator.Element)?
> }
> 
> extension Collection {
> /// Returns the index of the minimum element of `self`, using 
> /// `isOrderedBefore` to compare elements, or `nil` if the
> /// collection has no elements.
> func minIndex(@noescape isOrderedBefore isOrderedBefore: 
> (Iterator.Element, Iterator.Element) throws -> Bool
> ) rethrows -> Index?
> 
> /// Returns the index of the 

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Taras Zakharko via swift-evolution]

+1 Makes language cleaner and more consistent. 

> On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution 
>  wrote:
> 
> We currently accept function type syntax without parentheses, like:
> 
>  Int -> Float
>  String -> ()
> 
> etc.  The original rationale aligned with the fact that we wanted to treat 
> all functions as taking a single parameter (which was often of tuple type) 
> and producing a tuple value (which was sometimes a tuple, in the case of void 
> and multiple return values).  However, we’ve long since moved on from that 
> early design point: there are a number of things that you can only do in a 
> parameter list now (varargs, default args, etc), implicit tuple splat has 
> been removed, and  the compiler has long ago stopped modeling function 
> parameters this way.  Beyond that, it eliminates one potential style war.
> 
> Given all this, I think it makes sense to go for syntactic uniformity between 
> parameter list and function types, and just require parenthesis on the 
> argument list.  The types above can be trivially written as:
> 
>  (Int) -> Float
>  (String) -> ()
> 
> Thoughts?
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

[Taras Zakharko via swift-evolution]

True, that makes sense. I was simply trying to explore different possibilities 
of how these things could be represented in the syntax. What about #type(d) for 
static (declaration) type and type(v) for dynamic (value/instance) type? Or 
would that be potentially confusing as well? 

The reason why I dislike .dynamicType etc. declarations is because they 
introduce another ‘magic’ properties to instances. I think that this 
functionality is very important and that it should be represented by the 
standard library instead. If Swift had a universal base type, one could say 
that the magic properties are just part of that base type (and by extension, 
part of the standard library), however, right now, they are injected by the 
compiler. I’d rather have a standard function like 

type: (Any)->AnyType 

for this purpose. Hell, I would even say that dynamicType(self) is an 
improvement over self.dynamicType :)


— Taras 

> On 15 Apr 2016, at 09:54, Andrey Tarantsov  wrote:
> 
>> I do not think that I was conflating these two aspects. Using #type(self) 
>> would return the particular type of the current instance (dynamic type) 
>> while using #type(A.var) would return the declared (static) type of the 
>> property.
> 
> Taras, to me personally, #something suggests evaluation at compilation time, 
> so I would be *extremely* surprised if #type would return a dynamic type, and 
> #dynamictype is just an abomination, in every way worse than 
> something.dynamicType.
> 
> A.
> 

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

Re: [swift-evolution] What about a VBA style with Statement?

[Taras Zakharko via swift-evolution]

We had this kind of proposal earlier, didn’t seem to be very well received. I 
still think it would be a useful thing, but I’d do it as a statement (extension 
of do) that introduces new lexical  scope (similar to self)

— Taras

> On 13 Apr 2016, at 16:25, Sean Heber via swift-evolution 
>  wrote:
> 
> This pair works pretty well, too, if you don’t mind free functions:
> 
> func with(inout this: T, @noescape using: inout T->Void) { using() }
> func with(this: T, @noescape using: T->Void) { using(this) }
> 
> It works either with classes or mutable structs if you call it correctly and 
> the type doesn’t matter.
> 
> l8r
> Sean
> 
> 
>> On Apr 13, 2016, at 9:17 AM, Radosław Pietruszewski via swift-evolution 
>>  wrote:
>> 
>> It can be (more-or-less) solved in library code today:
>> 
>> extension NSObjectProtocol {
>>public func with(@noescape fn: Self -> Void) -> Self {
>>fn(self)
>>return self
>>}
>> }
>> 
>> This way, you can do, on NSObjects:
>> 
>> textLabel.with {
>>  $0.textAlignment = .Left
>>  $0.textColor = .darkTextColor()
>> }
>> 
>> I love this pattern.
>> 
>> You can also make it a function to make it work with any value of any kind 
>> (it will then take form of `with(foo) { …}`).
>> 
>> Ideally, if you could write a universal extension (something like `extension 
>> Any`), you could just add this behavior, with method syntax, to everything.
>> 
>> — Radek
>> 
>>> On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution 
>>>  wrote:
>>> 
>>> I recently learned some VBA and I found a very conveniently `with` 
>>> statement.
>>> 
>>> `with` statement can be helpful to set property for UIKit instance.
>>> 
>>> for instance a UILabel instance `textLabel` ,with `with` statement we can 
>>> set UILabel property like this
>>> 
>>> 
>>> 
>>> ```swift
>>> 
>>> with textLabel{
>>> 
>>> .textAlignment = .Left
>>> 
>>> .textColor = UIColor.darkTextColor()
>>> 
>>> .font = UIFont.systemFontOfSize(15)
>>> 
>>> }
>>> 
>>> ```
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

[Taras Zakharko via swift-evolution]

Hi, 

I think it depends on how expensive the indexed access is on the collection. I 
use it primarily on arrays, where self[i] essentially boils down to a pointer 
dereference, so I expect the generated code to be very efficient. Your version 
might be faster for collection with expensive element access, but it should be 
slower for arrays and the like, as it involves additional intermediate 
structure allocations and copies. 

— Taras


> Just a side note that you could also:
> 
> extension SequenceType {
>   func order(@noescape isOrderedBefore: (Generator.Element, 
> Generator.Element) -> Bool) -> [Int] {
>   return enumerate().sort{ isOrderedBefore($0.1, $1.1) }.map{ 
> $0.0 }
>   }
> }
> 
> (0...3).reverse().order(<) // [3, 2, 1, 0]
> 
> This way you can `order` all sequences, and it is more efficient as you don’t 
> fetch elements by index inside the `isOrderedBefore`. (You could also *not* 
> `map` at the end and return all the elements along with their original 
> indexes.)
> 
> milos

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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Taras Zakharko via swift-evolution]

>   * What is your evaluation of the proposal?

+1. I think it makes the collection model more simple and more flexible at the 
same time. By coupling index to a specific collection, rather then treating it 
as a separate, independent entity, we can more easily implement alternative 
collections. For instance, I have recently needed a collection that wraps 
around the end of a sequence, e.g. 

[1, 2, 3, 4, 5].[wrappingFrom: 3, end: 2] == [4, 5, 1, 2]

With the current model, implementing indexes that do this kind of wrapping is 
quite messy, because a lot of collection-specific state needs to be stored 
within the index. With the new model, it becomes much simpler. 

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

I think so. The model where index has its own, independent properties is too 
rigid. It might be possible to work around the limitations of that model with 
using more advanced generics(e.g. where type information depends on values such 
as dimensionality etc.), but the proposed new model is much simpler and 
potentially allows better performing code. 

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

Yes

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


Followed the thread, experimented with implementing various non-trivial 
collections myself (in Swift and outside Swift)

> On 10 Apr 2016, at 23:41, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "A New Model for Collections and Indices" begins now and runs 
> through April 18th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

[Taras Zakharko via swift-evolution]

> On 11 Apr 2016, at 10:05, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
> Clarifying questions as comments:
> 
> guard device = MTLCreateSystemDefaultDevice() else {
> fatalError()
> }
> device = nil   // Is this still allowed here?

Device instance variable is not an optional — so, no. The entire point of this 
would be to init potentially failable substate without having to deal with 
forcibly unwrapped optionals or having guards every time when substate needs to 
be accessed etc. 

> device.newDefaultLibrary()  // Is this allowed without optional chaining?

Sure

> 
> Also, I don't see any reason this idea should be restricted to instance 
> variables. It could work for any variable, I think, but in any case it gets 
> tricky if the value is mutated again afterwards.

The problem as I see it is that guard enforces state consistency. If the guard 
fails, any code that access the guarded state becomes invalid. This is why 
guard else clause requires one to leave the enclosing scope — to ensure that 
the guarded variables cannot be accesses in valid code. If one extends the 
binding to other variables, one runs into the problem that these variables can 
be accessed from outside. This is why I am suggesting to restrict guard to 
constructors only and fail the object construction if the guard fails. 

— Taras

> 
> Jacob
> 
> On Mon, Apr 11, 2016 at 12:31 AM, Taras Zakharko via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> One place where I find myself using the guard statement a lot is state 
> initialisation. E.g. in init()
> 
> guard let
>device   = MTLCreateSystemDefaultDevice(),
>library  = device.newDefaultLibrary()
> else {
>fatalError(“Could not initiallize Metal, aborting”)
> }
> 
> Here, the two variables device and library are intended to be instance 
> variables of an engine backbone system. However, because optional binding in 
> guard can only introduce new local statements, one needs to add additional 
> boilerplate in the end, e.g.:
> 
> self.device = device
> self.library  = library
> 
> What I want to propose is a very simple QOL enhancement: allow optional 
> binding to be used with instance variables in the constructors. If the 
> binding fails, the instance construction cannot proceed (the relevant scope 
> is the instance). The syntax would be
> 
> guard  device   = MTLCreateSystemDefaultDevice(),
>library  = device.newDefaultLibrary()
> else {
>fatalError(“Could not initiallize Metal, aborting”) // or return nil
> }
> 
> 
> Few notes:
> 
> - This would only apply to guard statement, because binding in the if 
> statement only applies to the internal if scope by definition
> - One could also ask for instance optional binding in any context where 
> instance assignment is legal. However, this would make guard inconsistent, as 
> it won’t be able to prevent inconsistent state from being invisible to the 
> app. Therefore its best to restrict this to cases where state is being 
> constructed, and fail the construction if the guard fails (hence init() )
> 
> Best,
> 
>  Taras
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

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

[swift-evolution] [Proposal] Add .order() family of methods to Collection

[Taras Zakharko via swift-evolution]

Swift standard library already offers a useful set of sort() functions. 
However, it is also often useful to know how the collection should be 
rearranged in order to become sorted. For example, R defines the order() 
function which returns a permutation of collection indexes which rearrange the 
collection in an order. I suggest to add similar functionality to the Swift 
Collections E.g.:

var out = []
for i in collection.order({$0 < $1}) { out.append(collection[i]) }
// out is now sorted collection

Knowing the sort order is useful in many applications where the data cannot or 
should not be rearranged and yet some information about the ordering is 
helpful, e.g. for traversing the collection in a specific way. It is also 
helpful for maintaining multiple ordering relations associated with the same 
collection. 

The implementation should be fairly straightforward. E.g. here is an extension 
method I use:

extension CollectionType {
func order(@noescape isOrderedBefore: (Self.Generator.Element, 
Self.Generator.Element) -> Bool) -> [Self.Index] {
return indices.sort({ isOrderedBefore(self[$0], self[$1]) })
}
}

Best, 

 Taras

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

[swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

[Taras Zakharko via swift-evolution]

One place where I find myself using the guard statement a lot is state 
initialisation. E.g. in init()

guard let
   device   = MTLCreateSystemDefaultDevice(),
   library  = device.newDefaultLibrary()
else {
   fatalError(“Could not initiallize Metal, aborting”)
}

Here, the two variables device and library are intended to be instance 
variables of an engine backbone system. However, because optional binding in 
guard can only introduce new local statements, one needs to add additional 
boilerplate in the end, e.g.:

self.device = device
self.library  = library

What I want to propose is a very simple QOL enhancement: allow optional binding 
to be used with instance variables in the constructors. If the binding fails, 
the instance construction cannot proceed (the relevant scope is the instance). 
The syntax would be 

guard  device   = MTLCreateSystemDefaultDevice(),
   library  = device.newDefaultLibrary()
else {
   fatalError(“Could not initiallize Metal, aborting”) // or return nil
}


Few notes:

- This would only apply to guard statement, because binding in the if statement 
only applies to the internal if scope by definition
- One could also ask for instance optional binding in any context where 
instance assignment is legal. However, this would make guard inconsistent, as 
it won’t be able to prevent inconsistent state from being invisible to the app. 
Therefore its best to restrict this to cases where state is being constructed, 
and fail the construction if the guard fails (hence init() )

Best, 

 Taras






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

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

[Taras Zakharko via swift-evolution]

At first, I was opposed to this idea but after working with many heterogeneous 
implementations of the same protocol, where instance creation needs to be 
dynamically dispatched to based on the properties of the data, I think that 
factory initialisers might be a nice idea. However, it would IMO make sense to 
restrict them to protocol extensions only.

— Taras


> On 11 Apr 2016, at 08:55, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> I thought this already went in review somehow, sorry a +1 from me as well.
> 
> [[iOS messageWithData:ideas] broadcast]
> 
> On 10 Apr 2016, at 19:14, Radosław Pietruszewski via swift-evolution 
> > wrote:
> 
>> Nice!
>> 
>> I must admit, my first reaction to this proposal was “uhhh, why complicate 
>> initializers even more?”. But then I hit these two roadblocks:
>> 
>> 1. I wanted to add an initializer on `NSTimer` extension that returns the 
>> (toll-free-bridged) value from CFRunLoopTimerCreateWithHandler. Sadly, this 
>> is impossible, and so I have to write NSTimer.new(…) 
>> 
>>  :(
>> 2. I wanted to add a custom initializer to a class inheriting from UIButton. 
>> But I can’t, because the initializer for UIButton is `convenience init(type 
>> buttonType: UIButtonType)` :(
>> 
>> A `factory init` allowing me to use both the initializer syntax and return 
>> an object from some other initializer would solve both problems. The 
>> "Initializing Storyboard-backed View Controller” use case is also compelling 
>> to me.
>> 
>> +1.
>> 
>> — Radek
>> 
>>> On 09 Apr 2016, at 21:17, Riley Testut via swift-evolution 
>>> > wrote:
>>> 
>>> Hello again everyone!
>>> 
>>> Just an update, I did submit the PR about a week ago, and you can check it 
>>> out here:
>>> https://github.com/apple/swift-evolution/pull/247 
>>> 
>>> 
>>> As far as I know, now we wait until a core team member reviews the PR, and 
>>> either suggests changes, or accepts it and initiates a review. Of course, 
>>> if this is incorrect, please let me know so I can do whatever next steps 
>>> there are :-)
>>> 
>>> Thanks again for all the contributions to this proposal, hope we see it get 
>>> approved soon!
>>> Riley
>>> 
 On Apr 4, 2016, at 11:58 AM, Riley Testut > wrote:
 
 Hey all!
 
 Just updated the proposal with all the recent changes, and you can check 
 it here: 
 https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
  
 
 
 Planning on submitting the PR later tonight, so please let me know if you 
 have any last minute feedback!
 Riley
 
> On Mar 30, 2016, at 1:35 PM, Jonathan Hull  > wrote:
> 
> Probably ‘no' in this proposal to keep things simple.
> 
> Long term, I would like overriding of the factory init to be the 
> mechanism for a post-hoc extendable factory.  Disallowing it now probably 
> makes that easier in the future.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 1:20 PM, Riley Testut > > wrote:
>> 
>> Another point to consider: should factory initializers be able to be 
>> overridden by subclasses? I vote no, just as you can't override 
>> convenience initializers.
>> 
>> On Mar 30, 2016, at 3:50 AM, Jonathan Hull > > wrote:
>> 
>>> Yeah.  I was thinking we would want to mirror the convenience 
>>> initializer syntax, but I am completely ok with this as well.  Honestly 
>>> this is the syntax I first tried to use in convenience inits while 
>>> learning swift, and I would love to see that migrate to something like 
>>> this.  My only worry would be that people would be confused on when to 
>>> use ClassName() and when to use self.init().  Best to choose one and 
>>> stick with it.
>>> 
>>> Thanks,
>>> Jon
>>> 
 On Mar 30, 2016, at 3:36 AM, Riley Testut > wrote:
 
 If we are to enforce a different type signature for factory 
 initializers vs required/convenience initializers (which would greatly 
 simplify this issue), if I’m understanding correctly, there shouldn’t 
 be a need to be able to “return” self.init(), right? Because you could 
 do this instead:
 
 public class ConcreteBase {
 
private 

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Taras Zakharko via swift-evolution]

I am agnostic on a .striding() method, but I am strongly agains any suggestions 
of removing/replacing the global stride() function. The stride function does 
not pollute the global namespace as it is a universally useful construct (among 
others, for implementing classical iterating for loops), has its history in 
contemporary programming (comparable functions in languages like Python, R), 
and is IMO more readable and clear than a range with a striding method method. 
Furthermore, a stride is not a range — its a special sequence, while for ranges 
other rules apply. All in all, I don’t see why stride() and .striding() can’t 
coexist. 

— Taras 

P.S. As a side note, I would prefer if the stride() function be renamed 
sequence() or seq(), but thats just cosmetic personal preference. 


> On 08 Apr 2016, at 20:37, Erica Sadun via swift-evolution 
>  wrote:
> 
> Draft here: https://gist.github.com/erica/a51a981ee0352235204692affa959307 
>   Feedback 
> solicited, both positive and negative. 
> We've also got a related proposal about expanding ranges, which you can look 
> at here (https://gist.github.com/erica/af92c541a0fb69fce1b7aaf8374a5aa9 
> )
>  but we want to float this one first.
> 
> Thanks, -- E
> 
> 
> 
> Proposal: SE- 
> 
> Author(s): Xiaodi Wu , Pyry Jahkola 
> , Nate Cook , Erica 
> Sadun 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> We propose to introduce a striding(by:) method on the revised 3.0 Range type.
> 
> This proposal was discussed on the Swift Evolution list in the Feature 
> proposal: Range operator with step 
> 
>  thread. (Direct link 
>  
> to original thread)
> 
>  
> Motivation
> 
> Updating Range for Swift 3 offers a window of opportunity to simultaneously 
> improve strides.
> 
> Under current Swift 3 plans, n.stride(to:/through:, by:) will be replaced 
> with a standalone stride(from:, to:/through:, by:) function. We propose to 
> replace this change with a method on ranges. Using a method reduces overall 
> API surface area compared to free functions.
> 
> In its current incarnation, the standalone stride function uses confusing 
> semantics. The current to implementation returns values in [start, end) and 
> will never reach or get to end. The current through implementation returns 
> values in [start, end]. It may never reach end and certainly never goes 
> through that value. Our proposed method introduces simple, expected semantics 
> that can be extended to both countable and continuous ranges, and to open and 
> closed intervals (both half-open and fully-open).
> 
>  
> Detail
>  Design
> 
> The striding(by:) method is called on ranges. When used with a positive step 
> size, the count starts from the lower bound. With a negative step size, the 
> count starts from the upper bound. These bounds apply regardless of whether 
> they are inclusive or exclusive. 
> 
> The following examples should cover all corner cases and include possible 
> cases should Swift 3 introduce a full complement of open and closed ranges. 
> The syntax for non-canonical range types is not fixed and can be discussed 
> under separate cover.
> 
> (0 ... 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 ..< 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 <.. 9).striding(by: 2) ==[2, 4, 6, 8]
> (0 <.< 9).striding(by: 2) ==[2, 4, 6, 8]
> 
> (0 ... 9).striding(by: 3) == [0, 3, 6, 9]
> (0 ..< 9).striding(by: 3) == [0, 3, 6]
> (0 <.. 9).striding(by: 3) ==[3, 6, 9]
> (0 <.< 9).striding(by: 3) ==[3, 6]
> 
> (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1]
> (0 ..< 9).striding(by: -2) ==[7, 5, 3, 1]
> (0 <.. 9).striding(by: -2) == [9, 7, 5, 3, 1]
> (0 <.< 9).striding(by: -2) ==[7, 5, 3, 1]
> 
> (0 ... 9).striding(by: -3) == [9, 6, 3, 0]
> (0 ..< 9).striding(by: -3) ==[6, 3, 0]
> (0 <.. 9).striding(by: -3) == [9, 6, 3]
> (0 <.< 9).striding(by: -3) ==[6, 3]
> To reverse a stride, call reverse() on the results:
> 
> (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
> We note that striding by 0 should be always be a precondition failure.
> 
>  
> Alternatives
>  Considered
> 
> During the on-list discussion, we considered various scenarios 

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Taras Zakharko via swift-evolution]

replaceWith* is also my favourite here (same for *InPlace). Sure, it might be 
verbose, but the semantics is very clear and seems apply to a wide range of 
relevant situations. In the end, there are hundreds if not more messages in 
this (and related) threads and i am sure that you guys spent even more time in 
meetings talking about this. If I understand correctly, Swifts goal is clarity 
over laconicity. If finding sensible laconic terminology turns out to be 
surprisingly difficult, a more verbose one might be a better choice after all. 

— Taras


> On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Apr 04 2016, Brent Royal-Gordon  wrote:
> 
>>> Indeed, OED points out that modern usage is "chiefly military." Probably an 
>>> argument against its usage here.
>> 
>> It seems to me that what you're sort of saying is "replaceWith", but
>> that's kind of a mouthful. 
> 
> It's at least very explicit.  We did consider that, and chose “form” as
> a more reasonable convention.  However, we weren't thinking of the
> “from” problem.  I prefer “replaceWith” over “become” for some reason I
> can't identify.
> 
>> A quick thesaurus check suggests that the only decent single-world
>> alternative would be "substitute", but that sounds like a regex
>> operation. I think this is a dead end.
> 
> -- 
> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Taras Zakharko via swift-evolution]

How would this work with OptionSetType? It also uses leading dot prefixes for 
initialisers, but implementations are usually structs. If I understand 
correctly, leading dot can be used in any case where the type can be inferred 
by the compiler. Changing the rules for enums seems strange to me. 

Best, 

 Taras


> On 01 Apr 2016, at 05:41, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance 
> Member Implementations" begins now and runs throughApril 5, 2016. The 
> proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

[Taras Zakharko via swift-evolution]

> On 05 Apr 2016, at 08:19, T.J. Usiyan <griotsp...@gmail.com> wrote:
> 
> I missed it the first time around.
> 
> I like this idea but worry that it will invite some difficult to follow 
> implementations. 

True. I think, the question is how flexible one wants enum to be. Right now, 
Swift enums are nice for representing compact state, but they are quite awkward 
when trying to do more (e.g. complex recursive data structures with polymorphic 
behavior). This might be by design,  or this could be simply because enums are 
still incomplete. Extending enum functionality would effectively make then 
another alternative to class hierarchies/protocols, only that in the enum case 
the polymorphic structure is constrained initially. I think it might make sense 
for enum to be used to implement highly specialised polymorphic data 
structures, but its more a question of language design. It would be fine in my 
book if one said ‘no, we really don’t want enums to be that powerful use 
protocols/structs or classes for complex cases like that’.

This is something where I’d like to have more input from the core team, how do 
they envision the enum future?

> 
> I think that there would need to exist some restrictions on how methods could 
> be broken up. One such restriction might be that these implementations could 
> not be broken up between extensions for a given method. I don't know if the 
> added complexity of reading this pays off though. you get something like this 
> if you call a method in each case of the enum. 

A restriction like this would make perfect sense. Tracking of exhaustiveness 
could (should) be done at a declaration scope level, i.e. declarations must be 
exhaustive after every enum definition/extension. 

> 
> Would keeping track of exhaustiveness be more of a technical issue with this 
> feature? On the user side, this feature would be a pain without improving the 
> 'switch must be exhaustive' message to include the cases that the compiler 
> believes are missing.

I imagine a compiler error along the lines of ‘missing implementation for 
func() for case A, B, C'

> 
> TJ
> 
> On Tue, Apr 5, 2016 at 1:57 AM, Taras Zakharko via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Is the lack of comments due to general disinterest in such a thing or did my 
> mail go amiss somehow? ;)
> 
> Best, 
> 
>  Taras
> 
>> On 31 Mar 2016, at 14:39, Taras Zakharko <taras.zakha...@uzh.ch 
>> <mailto:taras.zakha...@uzh.ch>> wrote:
>> 
>> Recently, I have been working on implementing some non-trivial data 
>> structures in Swift (its about storing polygons in a space-partitioning 
>> tree). I am using enums to represent different types of parent nodes and 
>> leafs and I had some ideas to make them more fit for this kind of work. I 
>> expect that I will write multiple enum-related emails, each one 
>> concentrating on one particular feature. A usual disclaimer: these are 
>> random, quite rough ideas that might or not make sense, but I’d like to get 
>> some feedback  from the community. 
>> 
>> Case-based dispatch for enum methods
>> 
>> Often, behaviour of enum method depends on the enum value. For instance, 
>> imagine a tree structure with an insert(value:) method: the way how the 
>> inserting is handled depends on the type of the node. Usually, you’d 
>> implement it as a switch operation:
>> 
>> func insert(value:T) {
>>   switch self {
>> case let Leaf1(a, b, c): …
>> case let Leaf2(a, b): …
>> case let Parent1(x, y): …
>>   }
>> }
>> 
>> If the insert operation is non-trivial, this becomes quite convoluted. You 
>> can of course define private helper methods or functions that perform the 
>> specific functionality, but I don’t find it to be a very satisfying 
>> solution: there is still the switch boilerplate + you need to be careful to 
>> call the correct helper, so there are some safety issues. 
>> 
>> Now, suppose there was a way to add a method implementation that is 
>> case-specific:
>> 
>> enum MyTree {
>>   case Leaf1(Float, Float) {
>> mutating  func insert(value: T) {
>>let (a, b) = self.Leaf1 // or something like that
>>// handle insert for the case that node is of type Parent1
>> 
>>...
>>  }
>>   }
>> 
>>  case Parent1(Int, Float) {
>>  mutating func insert(value: T) {
>>let (x, y) = self.Parent1 // or something like that
>>// handle insert for the case that node is of type Parent1
>>...
>>  }
>>   }
>> 
>> default {
>> 

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

[Taras Zakharko via swift-evolution]

Is the lack of comments due to general disinterest in such a thing or did my 
mail go amiss somehow? ;)

Best, 

 Taras

> On 31 Mar 2016, at 14:39, Taras Zakharko  wrote:
> 
> Recently, I have been working on implementing some non-trivial data 
> structures in Swift (its about storing polygons in a space-partitioning 
> tree). I am using enums to represent different types of parent nodes and 
> leafs and I had some ideas to make them more fit for this kind of work. I 
> expect that I will write multiple enum-related emails, each one concentrating 
> on one particular feature. A usual disclaimer: these are random, quite rough 
> ideas that might or not make sense, but I’d like to get some feedback  from 
> the community. 
> 
> Case-based dispatch for enum methods
> 
> Often, behaviour of enum method depends on the enum value. For instance, 
> imagine a tree structure with an insert(value:) method: the way how the 
> inserting is handled depends on the type of the node. Usually, you’d 
> implement it as a switch operation:
> 
> func insert(value:T) {
>   switch self {
> case let Leaf1(a, b, c): …
> case let Leaf2(a, b): …
> case let Parent1(x, y): …
>   }
> }
> 
> If the insert operation is non-trivial, this becomes quite convoluted. You 
> can of course define private helper methods or functions that perform the 
> specific functionality, but I don’t find it to be a very satisfying solution: 
> there is still the switch boilerplate + you need to be careful to call the 
> correct helper, so there are some safety issues. 
> 
> Now, suppose there was a way to add a method implementation that is 
> case-specific:
> 
> enum MyTree {
>   case Leaf1(Float, Float) {
> mutating  func insert(value: T) {
>let (a, b) = self.Leaf1 // or something like that
>// handle insert for the case that node is of type Parent1
> 
>...
>  }
>   }
> 
>  case Parent1(Int, Float) {
>  mutating func insert(value: T) {
>let (x, y) = self.Parent1 // or something like that
>// handle insert for the case that node is of type Parent1
>...
>  }
>   }
> 
> default {
>mutating func insert(value: T) {
>   // handle insert for all other cases 
>...
>  }
> }
> }
> 
> etc. The case method specification needs to be exhaustive and adhere to the 
> same signature. It is a compile-time error to specify a method or property 
> only in some cases but not in the other ones (that is why we have the default 
> implementation). Outer scope definitions apply to all cases and cannot be 
> overridden by a case-specific implementation. 
> 
> Basically, the compiler would synthesise an outer-scope method that does a 
> switch operator to dispatch to the particular implementation. This is thus 
> mostly syntactic sugar which also promotes safety (as it becomes impossible 
> to call the wrong implementation). These would make the case-specific methods 
> fully compatible with protocols etc. (e.g. a protocol Insertable { mutating 
> func insert(value:) }
> 
> Looking forward to your thoughts on this!
> 
> Best, 
> 
>  Taras
> 
> 

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

Re: [swift-evolution] [Proposal] Custom operators

[Taras Zakharko via swift-evolution]

I think this is a great suggestion! One potential problem I can see (if I 
understood this correctly) is that modules are allowed to set up their own 
precedence rules for operators defined elsewhere. I think this might lead to 
some difficult to debug errors if a developer of one module (who is used to 
certain conventions) then has to work with a different, independent module 
(where the conventions are different). This is one area where numerical 
precedence weights seem to be superior as they at least refer to a common 
subjective coordinate system. 

Maybe one should also have visibility for precedence, for instance having 
precedence module-internal by default?

Best, 

 — Taras  

> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution 
>  wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Introduction
> 
> Replace syntax of operator definition:
> 
> infix operator <> { precedence 100 associativity left }
> With a directive:
> 
> #operator(<>, fixity: infix, associativity: left)
> Also replace numeric definition of precedence with separate comparative 
> precedence definitions:
> 
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
> Swift-evolution thread: link to the discussion thread for that proposal 
> 
>  
> Motivation
> 
>  
> Problems
>  with numeric definition of precedence
> 
> In the beginning, operators had nice precedence values: 90, 100, 110, 120, 
> 130, 140, 150, 160.
> 
> As time went, new and new operators were introduced. Precedence could not be 
> simply changed, as this would be a breaking change. Ranges got precedence 
> 135, as got precedence 132. ?? had precedence greater than <, but less 
> thanas, so it had to be given precedence 131.
> 
> Now it is not possible to insert any custom operator between < and ??. It is 
> an inevitable consequence of current design: it will be impossible to insert 
> an operator between two existing ones at some point.
> 
>  
> Problems
>  with a single precedence hierarchy
> 
> Currently, if an operator wants to define precedence by comparison to one 
> operator, it must do so for all other operators.
> 
> In many cases, this is not wished. Example: a & b < c is a common error 
> pattern. a / b as Double is another one. C++ compilers sometimes emit 
> warnings on these. Swift does not.
> 
> The root of the problem is that precedence is defined between all operators. 
> If & had precedence defined only by comparison to other bitwise operators and 
> / – only to arithmetic operators, we would have to place parentheses in such 
> places, not get subtle bugs, and not ever have to look at the huge operator 
> precedence table.
> 
>  
> Problems
>  with current operator definition syntax
> 
> Some argue that current operator syntax is not consistent with other language 
> constructs. Properties of operators have dictionary semantics and should be 
> defined as such. It is a rather weak argument right now, but after reworking 
> of precedence, the new syntax will be more to place. More reasons are given 
> below.
> 
>  
> Conflicts
>  of operator definitions
> 
> Consider two operator definitions in different modules.
> 
> Module A:
> 
> infix operator |> { precedence 137 associativity left }
> Module B:
> 
> infix operator |> { precedence 138 associativity left }
>  
> Proposed
>  solution
> 
>  
> Change
>  syntax for operator definition
> 
> #operator(<>, fixity: infix, associativity: left)
> #operator(!, fixity: postfix)
> First parameter of #operator directive is name of the operator. Then goes 
> required parameter fixity that can be infix,prefix, or postfix. 

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Taras Zakharko via swift-evolution]

This is what happens if you don’t follow the swift-evolution list for a while… 
I have send a very similar suggestion to the list today (but mine focuses more 
on methods). Didn’t mean to plagiarise your idea, sorry! Maybe we should bring 
the two of them together. 

Best, 

 Taras

> On 23 Mar 2016, at 11:13, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> If you've written enums before, you've no doubt noticed the irritating 
> phenomenon of `switch self` being absolutely everywhere. I first discovered 
> this in some of my very first Swift code, code so old we were still using the 
> `T[]` shorthand syntax:
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
> 
>var description: String {
>switch(self) {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
>}
> 
>var isRed: Bool {
>switch(self) {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
>}
> 
> It would be nice if we could somehow eliminate that. I have two suggestions:
> 
> * Implicitly switch on `self` at the top level of a function or accessor (or 
> at least an enum one with top-level `case` statements).
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
> 
>var description: String {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
> 
>var isRed: Bool {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
> 
> * Allow you to attach member definitions to particular cases. It would be an 
> error if they didn't all define the same members, unless there was a 
> top-level catchall.
> 
>enum Suit: Int {
>var isRed: Bool { return false }
> 
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}
> 
> Any thoughts? This has, to be honest, bothered me since approximately the 
> third day I used the language; I'd love to address it sooner or later.
> 
> -- 
> 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] Thoughts regarding readable INTENT of Loop keywords

[Taras Zakharko via swift-evolution]

I do not see how this is more readable. The current for loop is perfectly 
readable and conveys the intent very well IMO: it executes a code block FOR 
every ELEMENT that is IN a SEQUENCE. In contrast, I find your proposal rather 
confusing: it combines a number of different constructions with different 
semantics and generally is less transparent. 

Best, 

 Taras

> On 30 Mar 2016, at 21:54, Nathanial Burton-Bradford via swift-evolution 
>  wrote:
> 
> Swift Control Flow using Loops 
> 
> One of Swifts strengths is clear, readable INTENT, conveyed by the languages 
> Keyword tokens. For anyone new to programming, clear, readable intent, goes a 
> long way in helping them master the language, by helping reduce 
> logical/semantic errors caused by a misunderstanding of the names used in 
> specifying the languages keyword tokens…
> Swift’s control flow keywords can be ambiguous, in this respect, when 
> conveying the functional intent of loop control logic, within the language.
> 
> I would like to open up discussion, therefore, regarding the possible 
> renaming of Swift’s control flow keywords, with the hope that this leads to 
> clearer INTENT regarding loops. 
> 
> 
> Replace For-In with Loop Using 
> 
> for foo in d…y 
> loop foo using d…y
> 
> For x in 1…5
> loop x using 1…5
> 
> loop i=0 using i<10
> 
> loop i using 0..<10
> 
> 
> 
> For _ in 1 …power
> ———->
> loop using 1…power
> 
> “The underscore character (_) used in place of a loop variable causes the 
> individual values to be ignored and does not provide access to the current 
> value during each iteration of the loop.”
> 
> I feel underscore character (_) is confusing, semantically. 
> 
> 
> let names = ["Anna", "Alex", "Brian", “Jack"]
> for name in names {
> ———-> loop names using name {
> print("Hello, \(name)!")
> }
> 
> Note : loop ARRAY using ELEMENT(S) - which is logically consistent with 
> ‘-using’ as last keyword instance.
> 
> let numberOfLegs = ["spider": 8, "ant": 6, "cat": 4]
> for (animalName, legCount) in numberOfLegs {
> print("\(animalName)s have \(legCount) legs")
> }
> 
> loop numberOfLegs using (animalName, legCount) {
> print(“ \(animalName)s have \(legCount) Legs”)
> }
> 
> Note : Again loop ARRAY using ELEMENT(S) - which is logically consistent with 
> ‘-using’ as last keyword instance.
> 
> 
> for (airportCode, airportName) in airports {
> loop airports using (airportCode, airportName) 
> for airportCode in airports.keys {
> loop airports.keys using airportCode {
>
> for airportName in airports.values {
> loop airports.values using airportName {
> 
> for value in array[1.. loop array[1.. 
> ‘while’ using loop while 
> 
> loop while square < finalSquare {
> // roll the dice
> diceRoll += 1
> if diceRoll == 7 { diceRoll = 1 }
> // move by the rolled amount
> 
> Control transfer statements
> 
> repeat { 
> ——> loop {
> …
> } while 
> 
> 
> “Break
> The break statement ends execution of an entire control flow statement 
> immediately. ”
> 
> I propose replacing Break, in loops, with exit now (intent is explicit)
> Note: Labeled Statements with break - 
> break gameLoop exit now gameLoop
> 
> “Continue
> The continue statement tells a loop to stop what it is doing and start again 
> at the beginning of the next iteration through the loop.”
> 
> “switch character {
> case "a", "e", "i", "o", "u", " ":
> continue // Continue what? to next line? to end? to beginning?
> default:
> puzzleOutput.append(character)
> }”
> 
> I propose replacing continue with next cycle or next loop
> 
> 
> “switch character {
> case "a", "e", "i", "o", "u", " ":
> next cycle // intent is explicit
> default:
> puzzleOutput.append(character)
> }”
> 
> Note: Labeled Statements with Continue - as per Break example, next cycle 
> gameLoop 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 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] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Taras Zakharko via swift-evolution]

> On 21 Mar 2016, at 17:05, ted van gaalen  wrote:
> 
> Hello Taras
> Please take a look here:
> https://en.m.wikipedia.org/wiki/For_loop 
> 
> 
> More than 30  !  programming languages since 1957 until now, have their 
> implementation of the for-loop. If it was or is an inferior construct, it 
> would have disappeared long ago. That alone proves that it is not inferior, 
> but indeed very useful.

And how many of them have the C style for(;;) loop? I don’t even know why the 
article refers to it as the ‘traditional’ for. Its not traditional, its just 
popular (because it was introduced with C). The traditional for is the one 
found in Fotran/Pascal etc. as it actually has that explicit ‘loop variable’ 
semantics. The C for(;;) loop does not have it. 

And by the way, I was never suggesting that Swift should drop for loops 
altogether. I am just saying that the iterator-based for loop is more then 
adequate for any conceivable purpose (see below). The reason why early 
languages do not use iterator-based loops is because the computers were less 
advances back then, as was our understanding of compilers and computer science. 
Iterator-based loops incur a high abstraction cost, which can be completely 
removed by an optimising compiler nowadays. There is of course the issue with 
the debug-build performance, but I am sure that this too can be remedied 
eventually. 

> 
> There is imho no longer any need to compare the for... variants any longer 
> (but of course feel free to do so), because they both serve different 
> purposes very well. Neither one or the other is inferior! I would protest 
> with equal energy also when the for...in... was removed, because this would 
> make iterating with collections cumbersome, e.g. I am now very happy that I 
> can now iterate through an array, without specifying start, length and where 
> we are.. 

I do not think it is appropriate to think about these constructions in terms of 
inferior/superior. The fact is that the traditional for loop (iterating trough 
some numbers) is a strict subset of iterator-based loops. Iterator-based loops 
can do all things that traditional for loops do and then some more. Which make 
the traditional loop unnecessary. Again, I dislike the C-style for(;;) loop 
because it has its own, extended semantics which makes it a hybrid between a 
for-loop and a while loop. 

To reiterate, I don’t see the point in having multiple distinct syntaxes for 
loops when the same thing can be accomplished (and often more compactly so) 
using the iterator loop. This is just shuffling the syntax around, for no win 
or reason I can reasonably see. For instance, what you suggest below can be 
easily done with iterators (and its how Python, R and many other languages do 
it):

for i in seq(f, t, by:b, while: w) { }
for i in c.filter(condition) { }

etc.

Furthermore, with iterator based loops you are free to extend your for loop as 
your demands change, to produce shorter, more efficient and safer code (see my 
example with matrix index iteration in the previous mail). 

— Taras




> 
> Concerning my intended proposal for a good alternative for the classicsl 
> for-loop, I am currently in favor of very much something like this version, 
> as it is implemented in Maple:
>   ---start copy from wkpd page---
> 
>> Maple has two forms of for-loop, one for iterating of a range of values, and 
>> the other for iterating over the contents of a container. The value range 
>> form is as follows:
>> 
>> for i from f by b to t while w do # loop body od;
>> All parts except do and od are optional. The for i part, if present, must 
>> come first. The remaining parts (from f, by b, to t, while w) can appear in 
>> any order.
>> 
>> Iterating over a container is done using this form of loop:
>> 
>> for e in c while w do # loop body od;
>> The in c clause specifies the container, which may be a list, set, sum, 
>> product, unevaluated function, array, or an object implementing an iterator.
>> 
>> A for-loop may be terminated by od, end, or end do.
>> 
> --end 
> copy---
> 
> ( in the above example replace "do" and "od" by { } )
> Maple has two forms of for-loop, one for iterating of a range of values, 
> and the other for iterating over the contents of a container.
> In Maple, which by the way is a very advanced programming language for 
> mathematicians ( i am not), both variants are available and co-exist 
> independently, which is exactly my point!  So again, it is not replacing or 
> even changing the for-in as it is now available in Swift, both versions 
> should be available. (This would still be the case if the for ;; had not been 
> removed in the first place)
> To get back to the Maple for-loop implementation, in Swift I'd drop the 
> "while" extension.
> To summarize:
> 
> I would like to see in 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Taras Zakharko via swift-evolution]

To be honest, I have difficulty understanding the premise of this discussion. I 
have always found the C-style  for(;;) loop an awkward construct, because it is 
essentially just an alternative form of writing a general-purpose while loop.  
It is perfectly reasonable to restrict the for construct to, well, ‘for’ 
contexts: iterating through a sequence of items. If you need something more 
complex, either write your own iterator or use a general-purpose while loop.  

As discussed previously, an optimising compiler generates the same machine code 
whether you are using an iterator abstraction or low-level coding. Besides, the 
for .. in .. construct potentially offers more potential for optimisation, 
because it makes the counter variable as well as the semantics of the entire 
loop more explicit (a for(;;) can contain arbitrary stuff). Talking about 
numerical algorithms: this is something I can’t understand at all. I have been 
working with numerical algorithms in Python and R for years, and I have never 
ever missed the C-style for loop. These languages offer convenient functions 
for generating iterable sequences, which are more readable and also represent 
the loop  semantics much better then the for(;;;). Not to mention that the 
iterator pattern allows you to write simpler and more maintainable code. 
Imagine iterating through a sparse matrix or something. With a proper iterator 
pattern you just do:

for (i,j,k) in matrix.indices {

}

With a for(;;) loop you’l probably end up writing a nested construct of quite 
some complexity. 
 
Swift could certainly use some improvements to its iterators (for example 
something like Python generator expressions might be useful), but that is a 
different topic.  

To sum it up:
- for(;;) is an awkward construct which is closer to a while loop than an 
actual sequence iterator pattern (that it should be)
- a proper iterator pattern is more convenient, more readable and offers the 
same performance
- numerical code does not need a for(;;) construct, in fact, using the proper 
iterator pattern makes writing numeric code easier, not more difficult, because 
you can abstract away some common processing/aggregating steps easily, and 
without any drawback
- we should think about how to improve the iterators offered by Swift standard 
library, not go back to an inferior construction

— Taras



> On 21 Mar 2016, at 12:37, Greg Parker via swift-evolution 
>  wrote:
> 
>> 
>> On Mar 19, 2016, at 12:46 AM, Dmitri Gribenko via swift-evolution 
>>  wrote:
>> 
>> Hi Ted,
>> 
>> Thank you for starting this thread.  I agree that removing the C-style
>> for loop has degraded the readability and clarity of some of numerics
>> code.
>> 
>> In the feedback to SE-0007 many people have said that they can convert
>> their code to for-in loops, but I think this actually means that in
>> code that is typically written in Swift today, loops primarily operate
>> on sequences and collections.  It means that numerics is a domain that
>> not many people work in.  But it is a very important domain
>> nevertheless, and clarity for numerics code matters at least as much
>> as it does everywhere else.
>> 
>> I think one way to approach this discussion would be to present
>> multiple concrete code samples that contain C-style for loops and are
>> awkward to write without them.  We can then try looking for patterns,
>> generalize and simplify, and discuss possible solutions.
> 
> Let me emphasize this more strongly. *Concrete*, *real-world* examples are 
> quite likely the only way that you are going to get `for(;;)` back or get any 
> sort of semantically-similar syntactically-different replacement.
> 
> There have been lots of suggestions. None of them are perfect. If we assume 
> that there is in fact no perfect solution then the only way to proceed is to 
> provide sufficient justification for some imperfect solution.
> 
> I'm still waiting for something like this: "We ported our code to Swift 3. 
> Here are 5 reasonable-looking for(;;) loop shapes from 150 call sites, and 
> here are their ugly-looking rewrites."
> 
> (Personally I think removing for(;;) without direct replacement was too 
> aggressive. That view lost. Now its advocates will need to do more work to 
> upend the status quo.)
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

Ah, thank you for pointing this out! I think I would suggest a change or two to 
your proposal, but I need to flesh them out first. Is it possible to leave 
comments on the bug site? BTW, why was it delegated to the bug report system in 
the first place? 



> On 28 Dec 2015, at 02:28, Erica Sadun via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> The most common use-case for this is with Cocoa classes, which are not set up 
> for fluent implementation.  A preliminary proposal (which I am not updating 
> since the matter was referred to the bug report system) is here: 
> https://gist.github.com/erica/6794d48d917e2084d6ed 
> <https://gist.github.com/erica/6794d48d917e2084d6ed> Hopefully it explains 
> the reason this would add to the Apple development ecosystem. The bug report 
> is here: https://bugs.swift.org/browse/SR-160 
> <https://bugs.swift.org/browse/SR-160>
> 
> -- E
> 
> 
>> On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lov...@gmail.com 
>> <mailto:howard.lov...@gmail.com>> wrote:
>> 
>> -1 doesn't seem worth adding it is not a lot of trouble to type `obj.` at 
>> the start of every line.  Also if an API is intended to be used like that 
>> its methods would return `self` and it would be used in a FLUENT style.
>> 
>> Sent from my iPad
>> 
>> On 28 Dec 2015, at 9:00 AM, Erica Sadun via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I believe this has popped up on-list a few times. Search for method 
>>> cascades:
>>> 
>>> cascading site:https://lists.swift.org/pipermail/swift-evolution/ 
>>> <http://lists.swift.org/pipermail/swift-evolution/>
>>> 
>>> https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F
>>>  
>>> <https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F>
>>> 
>>> Other search terms include dart, initializers, ".." (although that may be 
>>> hard to look for)
>>> 
>>> -- E
>>> 
>>> 
>>>> On Dec 27, 2015, at 2:34 PM, Radosław Smogura via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Please find my comment in body:
>>>> 
>>>> BR,
>>>> Radek Smogura
>>>>> On 27 Dec 2015, at 22:08, Taras Zakharko <taras.zakha...@uzh.ch 
>>>>> <mailto:taras.zakha...@uzh.ch>> wrote:
>>>>> 
>>>>> 
>>>>>> On 27 Dec 2015, at 21:55, Mosab Elagha <mosabela...@gmail.com 
>>>>>> <mailto:mosabela...@gmail.com>> wrote:
>>>>>> 
>>>>>> Agreed, this seems like a great idea. Looks like it would also allow for 
>>>>>> a lot of customization - for example out of one "template" object.
>>>>>> 
>>>>>> Would the object have to already be initialized or could you initialize 
>>>>>> it from this? IMO it would have to already be initialized or else it 
>>>>>> might lead to confusion.
>>>>> 
>>>>> The object could be any kind of valid Swift entity that has members 
>>>>> (where you would usually use . to access them): object instance, type, 
>>>>> struct etc. I can also imagine combining it with assignment, e.g. instead 
>>>>> of 
>>>>> 
>>>>> let obj = MyClass()
>>>>> do with obj {
>>>>>   prop1 = v1
>>>>>   setup2()
>>>>> }
>>>>> 
>>>>> a combined assignment form such as 
>>>>> 
>>>>> do with let obj = MyClass() {
>>>>>   prop1 = v1
>>>>>   setup2()
>>>>> }
>>>> I think in this case it’s important to define scope of obj - it should be 
>>>> only “do with”, not the the outer one?
>>>> 
>>>>> But this clashes with optional binding, so it might be not a good idea. 
>>>>> 
>>>>>> Also, would this be limited to instance methods?
>>>>> 
>>>>> Anything you can access with the dot notation. 
>>>>> 
>>>>>> 
>>>>>> -Mosab Elagha
>>>>>> 
>>>>>> On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura 
>>>>>> &l

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

> On 27 Dec 2015, at 21:55, Mosab Elagha <mosabela...@gmail.com> wrote:
> 
> Agreed, this seems like a great idea. Looks like it would also allow for a 
> lot of customization - for example out of one "template" object.
> 
> Would the object have to already be initialized or could you initialize it 
> from this? IMO it would have to already be initialized or else it might lead 
> to confusion.

The object could be any kind of valid Swift entity that has members (where you 
would usually use . to access them): object instance, type, struct etc. I can 
also imagine combining it with assignment, e.g. instead of 

let obj = MyClass()
do with obj {
  prop1 = v1
  setup2()
}

a combined assignment form such as 

do with let obj = MyClass() {
  prop1 = v1
  setup2()
}

But this clashes with optional binding, so it might be not a good idea. 

> Also, would this be limited to instance methods?

Anything you can access with the dot notation. 

> 
> -Mosab Elagha
> 
> On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>> wrote:
> Hi,
> 
> That’s a great idea!
> 
> Kind regards,
> Radek
> 
> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> > Quite often, one needs to perform a number of operations on a single object 
> > (e.g. call up a bunch of configuration or action methods). This proposal is 
> > to extend the ‘do' statement  with an explicit lexical scope feature. For 
> > instance, this piece of code
> >
> > object.do_something()
> > object.do_somethind_else()
> > object.prop1 = value
> >
> > becomes
> >
> > do with object // or with object do
> > {
> >   do_something()
> >   do_somethind_else()
> >   prop1 = value
> > }
> >
> > Essentially, this construct would introduce a level of lexical scope — 
> > explicitly controlled by the programmer, in addition to the implicit scope 
> > dictated by statement blocks, closures and self.
> >
> > The advantage of this construct is that it allows one to remove boilerplate 
> > code for initialisation/configuration as well as adds clear logical 
> > separation to the code. Disadvantage is potential shadowing of identifiers 
> > in the scope, but this should to be a big issue because the syntax is 
> > explicit rather then implicit, meaning that its the programmers job to make 
> > sure that no shadowing occurs (btw, compiler could warn about shadowing). 
> > The additions to the language syntax is minimal and the implementation 
> > should be straightforward (its essentially the same logic as for self).
> >
> > Note that this proposal is close to the discussion about popular the 
> > implicit self on this mailing list. A body of any method could be 
> > understood as wrapped into an implicit
> >
> >   do with self {}
> >
> > Finally, this construct exists in a very similar form in Pascal (no idea if 
> > Wirth was inspired by some other feature or not here) and is also present 
> > in a bunch of languages that have dynamic scope. Personally, I use it all 
> > the time in R and I am loving it.
> >
> > If the community thinks this could be a nice addition to the language, I am 
> > ready to draft a proposal. Also, apologies if this has been suggested 
> > before — it is impossible to keep up with this list.
> >
> > Best,
> >
> > Taras
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

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

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

Ah, thank you for pointing this out! I think I would suggest a change or two to 
your proposal, but I need to flesh them out first. Is it possible to leave 
comments on the bug site? BTW, why was it delegated to the bug report system in 
the first place? 


> On 28 Dec 2015, at 02:28, Erica Sadun via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> The most common use-case for this is with Cocoa classes, which are not set up 
> for fluent implementation.  A preliminary proposal (which I am not updating 
> since the matter was referred to the bug report system) is here: 
> https://gist.github.com/erica/6794d48d917e2084d6ed 
> <https://gist.github.com/erica/6794d48d917e2084d6ed> Hopefully it explains 
> the reason this would add to the Apple development ecosystem. The bug report 
> is here: https://bugs.swift.org/browse/SR-160 
> <https://bugs.swift.org/browse/SR-160>
> 
> -- E
> 
> 
>> On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lov...@gmail.com 
>> <mailto:howard.lov...@gmail.com>> wrote:
>> 
>> -1 doesn't seem worth adding it is not a lot of trouble to type `obj.` at 
>> the start of every line.  Also if an API is intended to be used like that 
>> its methods would return `self` and it would be used in a FLUENT style.
>> 
>> Sent from my iPad
>> 
>> On 28 Dec 2015, at 9:00 AM, Erica Sadun via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I believe this has popped up on-list a few times. Search for method 
>>> cascades:
>>> 
>>> cascading site:https://lists.swift.org/pipermail/swift-evolution/ 
>>> <http://lists.swift.org/pipermail/swift-evolution/>
>>> 
>>> https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F
>>>  
>>> <https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F>
>>> 
>>> Other search terms include dart, initializers, ".." (although that may be 
>>> hard to look for)
>>> 
>>> -- E
>>> 
>>> 
>>>> On Dec 27, 2015, at 2:34 PM, Radosław Smogura via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Please find my comment in body:
>>>> 
>>>> BR,
>>>> Radek Smogura
>>>>> On 27 Dec 2015, at 22:08, Taras Zakharko <taras.zakha...@uzh.ch 
>>>>> <mailto:taras.zakha...@uzh.ch>> wrote:
>>>>> 
>>>>> 
>>>>>> On 27 Dec 2015, at 21:55, Mosab Elagha <mosabela...@gmail.com 
>>>>>> <mailto:mosabela...@gmail.com>> wrote:
>>>>>> 
>>>>>> Agreed, this seems like a great idea. Looks like it would also allow for 
>>>>>> a lot of customization - for example out of one "template" object.
>>>>>> 
>>>>>> Would the object have to already be initialized or could you initialize 
>>>>>> it from this? IMO it would have to already be initialized or else it 
>>>>>> might lead to confusion.
>>>>> 
>>>>> The object could be any kind of valid Swift entity that has members 
>>>>> (where you would usually use . to access them): object instance, type, 
>>>>> struct etc. I can also imagine combining it with assignment, e.g. instead 
>>>>> of 
>>>>> 
>>>>> let obj = MyClass()
>>>>> do with obj {
>>>>>   prop1 = v1
>>>>>   setup2()
>>>>> }
>>>>> 
>>>>> a combined assignment form such as 
>>>>> 
>>>>> do with let obj = MyClass() {
>>>>>   prop1 = v1
>>>>>   setup2()
>>>>> }
>>>> I think in this case it’s important to define scope of obj - it should be 
>>>> only “do with”, not the the outer one?
>>>> 
>>>>> But this clashes with optional binding, so it might be not a good idea. 
>>>>> 
>>>>>> Also, would this be limited to instance methods?
>>>>> 
>>>>> Anything you can access with the dot notation. 
>>>>> 
>>>>>> 
>>>>>> -Mosab Elagha
>>>>>> 
>>>>>> On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura 
>>>>>> &l

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

Same is true for the implicit self, and yet we’ve seen how people react to 
making self explicit. There are many places in contemporary Apple programming 
where this could be of great utility. For instance, I miss a lexical scope 
construction every time I work with Metal. 


> On 28 Dec 2015, at 02:24, Howard Lovatt via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> -1 doesn't seem worth adding it is not a lot of trouble to type `obj.` at the 
> start of every line.  Also if an API is intended to be used like that its 
> methods would return `self` and it would be used in a FLUENT style.
> 
> Sent from my iPad
> 
> On 28 Dec 2015, at 9:00 AM, Erica Sadun via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> I believe this has popped up on-list a few times. Search for method cascades:
>> 
>> cascading site:https://lists.swift.org/pipermail/swift-evolution/ 
>> <http://lists.swift.org/pipermail/swift-evolution/>
>> 
>> https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F
>>  
>> <https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F>
>> 
>> Other search terms include dart, initializers, ".." (although that may be 
>> hard to look for)
>> 
>> -- E
>> 
>> 
>>> On Dec 27, 2015, at 2:34 PM, Radosław Smogura via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> Please find my comment in body:
>>> 
>>> BR,
>>> Radek Smogura
>>>> On 27 Dec 2015, at 22:08, Taras Zakharko <taras.zakha...@uzh.ch 
>>>> <mailto:taras.zakha...@uzh.ch>> wrote:
>>>> 
>>>> 
>>>>> On 27 Dec 2015, at 21:55, Mosab Elagha <mosabela...@gmail.com 
>>>>> <mailto:mosabela...@gmail.com>> wrote:
>>>>> 
>>>>> Agreed, this seems like a great idea. Looks like it would also allow for 
>>>>> a lot of customization - for example out of one "template" object.
>>>>> 
>>>>> Would the object have to already be initialized or could you initialize 
>>>>> it from this? IMO it would have to already be initialized or else it 
>>>>> might lead to confusion.
>>>> 
>>>> The object could be any kind of valid Swift entity that has members (where 
>>>> you would usually use . to access them): object instance, type, struct 
>>>> etc. I can also imagine combining it with assignment, e.g. instead of 
>>>> 
>>>> let obj = MyClass()
>>>> do with obj {
>>>>   prop1 = v1
>>>>   setup2()
>>>> }
>>>> 
>>>> a combined assignment form such as 
>>>> 
>>>> do with let obj = MyClass() {
>>>>   prop1 = v1
>>>>   setup2()
>>>> }
>>> I think in this case it’s important to define scope of obj - it should be 
>>> only “do with”, not the the outer one?
>>> 
>>>> But this clashes with optional binding, so it might be not a good idea. 
>>>> 
>>>>> Also, would this be limited to instance methods?
>>>> 
>>>> Anything you can access with the dot notation. 
>>>> 
>>>>> 
>>>>> -Mosab Elagha
>>>>> 
>>>>> On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> Hi,
>>>>> 
>>>>> That’s a great idea!
>>>>> 
>>>>> Kind regards,
>>>>> Radek
>>>>> 
>>>>> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
>>>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> >
>>>>> > Quite often, one needs to perform a number of operations on a single 
>>>>> > object (e.g. call up a bunch of configuration or action methods). This 
>>>>> > proposal is to extend the ‘do' statement  with an explicit lexical 
>>>>> > scope feature. For instance, this piece of code
>>>>> >
>>>>> > object.do_something()
>>>>> > object.do_somethind_else()
>>>>> > object.prop1 = value
>>>>> >
>>>>>