Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Chris Lattner via swift-evolution]

> On Jul 30, 2016, at 3:21 PM, Colin Barrett  wrote:
> 
>> - You can choose to use the memory ownership features by adding extra 
>> annotations, giving better performance and control over ARC.  Right now we 
>> have very limited options for avoiding ARC overhead in critical loops, 
>> largely forcing you to drop down to unsafe constructs.  We’d prefer the 
>> model to be “you can add more annotations to your code to get better 
>> performance, allowing the compiler statically verify correctness instead of 
>> dynamically”.
> 
> Has any thought been giving to opting in something analogous in the other 
> direction—i.e. less performant, but less work for the programer? 
> Specifically, I’ve long thought that an annotation opting into a runtime 
> cycle collector (a la 
> http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf
>  
> )
>  would be very helpful for situations where, as you mention, performance is 
> not (currently) critical.

We have certainly discussed cycle collectors in the past, even in the context 
of Objective-C, and have concluded that it would be a bad idea for several 
reasons.  If you’d like to discuss that, please start a new thread, thanks!

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

Re: [swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Chris Lattner via swift-evolution]

> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen  
> wrote:
> 
> Hi Chris,
> 
> thanks for the tip about Hirundo app!
> 
> A positive side-effect of removing the classical for;; loop
>  (yes, it’s me saying this :o)  is that it forces me to find
> a good and generic equivalent for it, 
> making the conversion of my for;;s to 3.0 easier.
> which is *not* based on collections or sequences and
> does not rely on deeper calls to Sequence etc.

Hi Ted,

I know that you’re very passionate about the removal of C style for loops, but 
any direction to add back features to compensate for them will need to wait 
until Stage 2 of Swift 4’s planning cycle.

-Chris

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

Re: [swift-evolution] Swift 3.0 vs 3.x and Timing Clarification

[Douglas Gregor via swift-evolution]

> On Jul 30, 2016, at 9:19 PM, Robert Hedin via swift-evolution 
>  wrote:
> 
> I thought Chris was pretty clear as well; but what was said was:
> 
> "Over the next year, the core team expects to ship two major releases of 
> Swift: Swift 3.x in Spring 2017 and Swift 4 in Fall 2017." 
> 
> I'm know I'm being pedantic, but since 3.0 hasn't been released yet, it 
> sounds like it should be one of the "two major releases". While I'd love to 
> have Swift 3 for this year, I'm fine if it's slipping. Honestly, I'm not a 
> fan of tying what are huge language changes to an arbitrary annual ship 
> schedule anyway.
> 
> All that said, I'm just looking for clarity one way or the other so that I 
> can plan our app migration strategy over the near term.

Swift 3.0 will still ship in “late 2016”. That has not changed.

Chris was referring to a point release in Spring 2017. We don’t know if it will 
be Swift 3.1, or 3.2, or whatever.

- Doug

> 
> rob.
> 
> 
> On Sat, Jul 30, 2016 at 11:13 PM, Brandon Knope  > wrote:
> There is no way Swift 3 doesn't ship with iOS 10 in September. 
> 
> I think he meant point releases after 3.0 (3.*) will be in 2017 (3 vs 3.* vs 
> 4 was trying to convey this I believe). 
> 
> Swift 3 has to ship with iOS 10 because lots of us are building and updating 
> to iOS 10 and using swift 3. Apple would have a lot of angry developers come 
> iOS 10 if they couldn't submit their apps...
> 
> But of course, Chris can clarify :)
> 
> Brandon 
> 
> 
> 
> On Jul 30, 2016, at 9:38 PM, Robert Hedin via swift-evolution 
> > wrote:
> 
>> My team has been closely following things here and has been looking forward 
>> with great anticipation to using Swift 3 in our production systems.
>> 
>> To that end, I'd like to confirm (or not) that "Swift 3.0" is no longer 
>> expected to ship in "late 2016" as currently reflected on the Swift 
>> Evolution GitHub repo but will rather ship in "Spring 2017". 
>> 
>> Over the past 24 hours I've got different members of my team coming up with 
>> different reads of what, exactly, "3.x" means in context.
>> 
>> Thanks!
>> 
>> rob.
>> 
>> -- 
>> Robert Hedin  |Dir Software Engineering
>> w: 770-226-2650   e: robert.he...@weather.com 
>> 
>>    
>>   
>>  
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> 
> -- 
> Robert Hedin  |Dir Software Engineering
> w: 770-226-2650  e: robert.he...@weather.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] Swift 3.0 vs 3.x and Timing Clarification

[Robert Hedin via swift-evolution]

I thought Chris was pretty clear as well; but what was said was:

"Over the next year, the core team expects to ship two major releases of
Swift: *Swift 3.x in Spring 2017* and *Swift 4 in Fall 2017*."

I'm know I'm being pedantic, but since 3.0 hasn't been released yet, it
sounds like it should be one of the "two major releases". While I'd love to
have Swift 3 for this year, I'm fine if it's slipping. Honestly, I'm not a
fan of tying what are huge language changes to an arbitrary annual ship
schedule anyway.

All that said, I'm just looking for clarity one way or the other so that I
can plan our app migration strategy over the near term.

rob.


On Sat, Jul 30, 2016 at 11:13 PM, Brandon Knope  wrote:

> There is no way Swift 3 doesn't ship with iOS 10 in September.
>
> I think he meant point releases after 3.0 (3.*) will be in 2017 (3 vs 3.*
> vs 4 was trying to convey this I believe).
>
> Swift 3 has to ship with iOS 10 because lots of us are building and
> updating to iOS 10 and using swift 3. Apple would have a lot of angry
> developers come iOS 10 if they couldn't submit their apps...
>
> But of course, Chris can clarify :)
>
> Brandon
>
>
>
> On Jul 30, 2016, at 9:38 PM, Robert Hedin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> My team has been closely following things here and has been looking
> forward with great anticipation to using Swift 3 in our production systems.
>
> To that end, I'd like to confirm (or not) that "Swift 3.0" is no longer
> expected to ship in "late 2016" as currently reflected on the Swift
> Evolution GitHub repo but will rather ship in "Spring 2017".
>
> Over the past 24 hours I've got different members of my team coming up
> with different reads of what, exactly, "3.x" means in context.
>
> Thanks!
>
> rob.
>
> --
> *Robert **Hedin  *|Dir Software Engineering
> *w:* 770-226-2650  *e:* robert.he...@weather.com
>  
>  
>  
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
*Robert **Hedin  *|Dir Software Engineering
*w:* 770-226-2650  *e:* robert.he...@weather.com
 
 
 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.0 vs 3.x and Timing Clarification

[Brandon Knope via swift-evolution]

There is no way Swift 3 doesn't ship with iOS 10 in September. 

I think he meant point releases after 3.0 (3.*) will be in 2017 (3 vs 3.* vs 4 
was trying to convey this I believe). 

Swift 3 has to ship with iOS 10 because lots of us are building and updating to 
iOS 10 and using swift 3. Apple would have a lot of angry developers come iOS 
10 if they couldn't submit their apps...

But of course, Chris can clarify :)

Brandon 



> On Jul 30, 2016, at 9:38 PM, Robert Hedin via swift-evolution 
>  wrote:
> 
> My team has been closely following things here and has been looking forward 
> with great anticipation to using Swift 3 in our production systems.
> 
> To that end, I'd like to confirm (or not) that "Swift 3.0" is no longer 
> expected to ship in "late 2016" as currently reflected on the Swift Evolution 
> GitHub repo but will rather ship in "Spring 2017". 
> 
> Over the past 24 hours I've got different members of my team coming up with 
> different reads of what, exactly, "3.x" means in context.
> 
> Thanks!
> 
> rob.
> 
> -- 
> Robert Hedin  |Dir Software Engineering
> w: 770-226-2650  e: robert.he...@weather.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] Multi dimensional - iterator, Iterator2D, Iterator3D

[Jaden Geller via swift-evolution]

What benefit do Iterator2D and Iterator3D provide that nesting does not?

> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> thanks for the tip about Hirundo app!
> 
> A positive side-effect of removing the classical for;; loop
>  (yes, it’s me saying this :o)  is that it forces me to find
> a good and generic equivalent for it, 
> making the conversion of my for;;s to 3.0 easier.
> which is *not* based on collections or sequences and
> does not rely on deeper calls to Sequence etc.
> 
> so, I’ve made the functions [iterator, iterator2D, iterator3D]  (hereunder)
> wich btw clearly demonstrate the power and flexibility of Swift. 
> 
> Very straightforward, and efficient (i assume) just like the classical for;; 
> loop.  
> It works quite well in my sources.
> 
> As a spin-off,  I’ve extended these to iterators for matrices 2D and cubes? 
> 3D...
> 
> Question: 
> Perhaps implementing “multi dimensional iterator functions
> in Swift might  be a good idea. so that is no longer necessary to 
> nest/nest/nest iterators. 
> 
> Met vriendelijke groeten, sorry for my “intensity” in discussing the 
> classical for;; 
> I'll have to rethink this for;; again..  
> Thanks, Ted.
> 
> Any remarks ( all ), suggestions about the code hereunder:  ? 
> 
> protocol NumericType
> {
> func +(lhs: Self, rhs: Self) -> Self
> func -(lhs: Self, rhs: Self) -> Self
> func *(lhs: Self, rhs: Self) -> Self
> func /(lhs: Self, rhs: Self) -> Self
> func %(lhs: Self, rhs: Self) -> Self
> }
> 
> extension Double : NumericType { }
> extension Float  : NumericType { }
> extension CGFloat: NumericType { }
> extension Int: NumericType { }
> extension Int8   : NumericType { }
> extension Int16  : NumericType { }
> extension Int32  : NumericType { }
> extension Int64  : NumericType { }
> extension UInt   : NumericType { }
> extension UInt8  : NumericType { }
> extension UInt16 : NumericType { }
> extension UInt32 : NumericType { }
> extension UInt64 : NumericType { }
> 
> 
> /// Simple iterator with generic parameters, with just a few lines of code.
> /// for most numeric types (see above)
> /// Usage Example:
> ///
> ///   iterate(xmax, { $0 > xmin}, -xstep,
> ///{x in
> ///print("x = \(x)")
> ///return true  // returning false acts like a break
> /// } )
> ///
> ///  -Parameter vstart: Initial value
> ///  -Parameter step:The iteration stepping value.
> ///  -Parameter test:A block with iteration test. e.g. {$0 > 10}
> ///
> ///  -Parameter block:   A block to be executed with each step.
> ///   The block must include a return true (acts like "continue")
> ///   or false (acts like "break")
> ///  -Please Note: 
> ///  There is minor precision loss ca: 1/1000 ... 1/500 
> ///  when iterating with floating point numbers.
> ///  However, in most cases this can be safely ignored.
> ///  made by ted van gaalen.
> 
> 
> func iterate (
> vstart:  T,
>_ vstep:  T,
>_  test: (T) -> Bool,
>_ block: (T) -> Bool )
> {
> var current = vstart
> 
> while test(current) && block(current)
> {
> current = current + vstep
> }
> }
> 
> 
> /// X,Y 2D matrix (table) iterator with generic parameters
> func iterate2D (
>  xstart:  T,  _ xstep: T, _ xtest: (T) -> Bool,
>_ ystart:  T,  _ ystep: T, _ ytest: (T) -> Bool,
>_ block: (T,T) -> Bool )
> {
> var xcurrent = xstart
> var ycurrent = ystart
> 
> var dontStop = true
> 
> while xtest(xcurrent) && dontStop
> {
> ycurrent = ystart
> while ytest(ycurrent) && dontStop
> {
> dontStop = block(xcurrent, ycurrent)
> ycurrent = ycurrent + ystep
> }
> xcurrent = xcurrent + xstep
> }
> }
> 
> 
> /// X,Y,Z 3D (cubic) iterator with generic parameters:
> 
> func iterate3D (
> xstart:  T,  _ xstep: T, _ xtest: (T) -> Bool,
>   _ ystart:  T,  _ ystep: T, _ ytest: (T) -> Bool,
>   _ zstart:  T,  _ zstep: T, _ ztest: (T) -> Bool,
>   _ block: (T,T,T) -> Bool )
> {
> var xcurrent = xstart
> var ycurrent = ystart
> var zcurrent = zstart
> 
> var dontStop = true
> 
> while xtest(xcurrent) && dontStop
> {
> ycurrent = ystart
> while ytest(ycurrent) && dontStop
> {
> zcurrent = zstart
> while ztest(zcurrent) && dontStop
> {
> dontStop = block(xcurrent, ycurrent, zcurrent)
> zcurrent = zcurrent + zstep
> }
> ycurrent = ycurrent + ystep
> }
> xcurrent = xcurrent + xstep
> }
> }
> 
> 
> func testIterator()
> {
> iterate(0.0, 0.5, {$0 < 1000.0} ,
> { value in
> print("Value = \(value) ")
> return true
> } )
> 
> let 

Re: [swift-evolution] Swift 3.0 vs 3.x and Timing Clarification

[Charles Constant via swift-evolution]

The date I can submit my Swift 3 app to the App Store has significant
impact on my life at the moment. I think Chris' meaning was actually fairly
clear, but I'd also appreciate if the team could spell out an ETA again in
black and white. I'd like to be 100% sure I didn't misunderstand.



On Sat, Jul 30, 2016 at 6:38 PM, Robert Hedin via swift-evolution <
swift-evolution@swift.org> wrote:

> My team has been closely following things here and has been looking
> forward with great anticipation to using Swift 3 in our production systems.
>
> To that end, I'd like to confirm (or not) that "Swift 3.0" is no longer
> expected to ship in "late 2016" as currently reflected on the Swift
> Evolution GitHub repo but will rather ship in "Spring 2017".
>
> Over the past 24 hours I've got different members of my team coming up
> with different reads of what, exactly, "3.x" means in context.
>
> Thanks!
>
> rob.
>
> --
> *Robert **Hedin  *|Dir Software Engineering
> *w:* 770-226-2650  *e:* robert.he...@weather.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

[swift-evolution] Swift 3.0 vs 3.x and Timing Clarification

[Robert Hedin via swift-evolution]

My team has been closely following things here and has been looking forward
with great anticipation to using Swift 3 in our production systems.

To that end, I'd like to confirm (or not) that "Swift 3.0" is no longer
expected to ship in "late 2016" as currently reflected on the Swift
Evolution GitHub repo but will rather ship in "Spring 2017".

Over the past 24 hours I've got different members of my team coming up with
different reads of what, exactly, "3.x" means in context.

Thanks!

rob.

-- 
*Robert **Hedin  *|Dir Software Engineering
*w:* 770-226-2650  *e:* robert.he...@weather.com
 
 
 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Colin Barrett via swift-evolution]

> On Jul 30, 2016, at 12:21 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution 
> > wrote:
>> I wrote this a few months ago, but we weren't accepting additive proposals. 
>> Now we're explicitly looking for something like this:
>> 
>> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory 
>> ownership model to Swift is highly desired by systems programmers and folks 
>> who want predictable and deterministic performance (for example, in real 
>> time audio processing code).  More pertinent to the goals of Swift 4, this 
>> feature is important because it fundamentally shapes the ABI.  It informs 
>> code generation for “inout", how low-level “addressors” work in the ABI, 
>> impacts the Swift runtime, and will have a significant impact on the type 
>> system and name mangling. 
> 
> Memory ownership is about something slightly different than this.  In the 
> context of Swift, the model we’re looking for is:
> 
> - You can completely ignore memory ownership features of the language, and 
> get very far into development with Swift.  This is in stark contrast with 
> Rust and Cyclone, which require you to grapple with it up front.  This means 
> that in the Swift context, this will be more of a “power user” feature, 
> instead of essential part of the model.
> 
> - You can choose to use the memory ownership features by adding extra 
> annotations, giving better performance and control over ARC.  Right now we 
> have very limited options for avoiding ARC overhead in critical loops, 
> largely forcing you to drop down to unsafe constructs.  We’d prefer the model 
> to be “you can add more annotations to your code to get better performance, 
> allowing the compiler statically verify correctness instead of dynamically”.

Has any thought been giving to opting in something analogous in the other 
direction—i.e. less performant, but less work for the programer? Specifically, 
I’ve long thought that an annotation opting into a runtime cycle collector (a 
la 
http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf
 
)
 would be very helpful for situations where, as you mention, performance is not 
(currently) critical.

-Colin

> - Memory ownership control is an extremely non-trivial feature, which will 
> probably drive us to add first class move semantics and region types to the 
> language.  This will also call for significant standard library extensions.  
> It will pay for this complexity by making it easy to ignore the complexity if 
> you don’t want it, and by the fact that the standard library and other stuff 
> can go much faster.
> 
> - As a Stage 2 feature, I can imagine an opt-in mode that “forces” the use of 
> these features, for code that wants to guarantee deterministic performance.  
> This is what enables the use of swift in realtime audio applications, for 
> example.
> 
> While some initial brainstorming and scoping has been done in this area, 
> we’re far from having a concrete design.  We have a few folks who are experts 
> at Rust that are helping contribute ideas and experience to this though.  
> 
> If you have more specific questions, feel free to ask about it.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

Hi Chris,

thanks for the tip about Hirundo app!

A positive side-effect of removing the classical for;; loop
 (yes, it’s me saying this :o)  is that it forces me to find
a good and generic equivalent for it, 
making the conversion of my for;;s to 3.0 easier.
which is *not* based on collections or sequences and
does not rely on deeper calls to Sequence etc.

so, I’ve made the functions [iterator, iterator2D, iterator3D]  (hereunder)
wich btw clearly demonstrate the power and flexibility of Swift. 

Very straightforward, and efficient (i assume) just like the classical for;; 
loop.  
It works quite well in my sources.

As a spin-off,  I’ve extended these to iterators for matrices 2D and cubes? 
3D...

Question: 
Perhaps implementing “multi dimensional iterator functions
in Swift might  be a good idea. so that is no longer necessary to 
nest/nest/nest iterators. 

Met vriendelijke groeten, sorry for my “intensity” in discussing the classical 
for;; 
I'll have to rethink this for;; again..  
Thanks, Ted.

Any remarks ( all ), suggestions about the code hereunder:  ? 

protocol NumericType
{
func +(lhs: Self, rhs: Self) -> Self
func -(lhs: Self, rhs: Self) -> Self
func *(lhs: Self, rhs: Self) -> Self
func /(lhs: Self, rhs: Self) -> Self
func %(lhs: Self, rhs: Self) -> Self
}

extension Double : NumericType { }
extension Float  : NumericType { }
extension CGFloat: NumericType { }
extension Int: NumericType { }
extension Int8   : NumericType { }
extension Int16  : NumericType { }
extension Int32  : NumericType { }
extension Int64  : NumericType { }
extension UInt   : NumericType { }
extension UInt8  : NumericType { }
extension UInt16 : NumericType { }
extension UInt32 : NumericType { }
extension UInt64 : NumericType { }


/// Simple iterator with generic parameters, with just a few lines of code.
/// for most numeric types (see above)
/// Usage Example:
///
///   iterate(xmax, { $0 > xmin}, -xstep,
///{x in
///print("x = \(x)")
///return true  // returning false acts like a break
/// } )
///
///  -Parameter vstart: Initial value
///  -Parameter step:The iteration stepping value.
///  -Parameter test:A block with iteration test. e.g. {$0 > 10}
///
///  -Parameter block:   A block to be executed with each step.
///   The block must include a return true (acts like "continue")
///   or false (acts like "break")
///  -Please Note: 
///  There is minor precision loss ca: 1/1000 ... 1/500 
///  when iterating with floating point numbers.
///  However, in most cases this can be safely ignored.
///  made by ted van gaalen.


func iterate (
vstart:  T,
   _ vstep:  T,
   _  test: (T) -> Bool,
   _ block: (T) -> Bool )
{
var current = vstart

while test(current) && block(current)
{
current = current + vstep
}
}


/// X,Y 2D matrix (table) iterator with generic parameters
func iterate2D (
 xstart:  T,  _ xstep: T, _ xtest: (T) -> Bool,
   _ ystart:  T,  _ ystep: T, _ ytest: (T) -> Bool,
   _ block: (T,T) -> Bool )
{
var xcurrent = xstart
var ycurrent = ystart

var dontStop = true

while xtest(xcurrent) && dontStop
{
ycurrent = ystart
while ytest(ycurrent) && dontStop
{
dontStop = block(xcurrent, ycurrent)
ycurrent = ycurrent + ystep
}
xcurrent = xcurrent + xstep
}
}


/// X,Y,Z 3D (cubic) iterator with generic parameters:

func iterate3D (
xstart:  T,  _ xstep: T, _ xtest: (T) -> Bool,
  _ ystart:  T,  _ ystep: T, _ ytest: (T) -> Bool,
  _ zstart:  T,  _ zstep: T, _ ztest: (T) -> Bool,
  _ block: (T,T,T) -> Bool )
{
var xcurrent = xstart
var ycurrent = ystart
var zcurrent = zstart

var dontStop = true

while xtest(xcurrent) && dontStop
{
ycurrent = ystart
while ytest(ycurrent) && dontStop
{
zcurrent = zstart
while ztest(zcurrent) && dontStop
{
dontStop = block(xcurrent, ycurrent, zcurrent)
zcurrent = zcurrent + zstep
}
ycurrent = ycurrent + ystep
}
xcurrent = xcurrent + xstep
}
}


func testIterator()
{
iterate(0.0, 0.5, {$0 < 1000.0} ,
{ value in
print("Value = \(value) ")
return true
} )

let startv: CGFloat = -20.0
let stepv: CGFloat =   0.5

iterate(startv, stepv, {$0 < 1000.0} ,
{ val in
print("R = \(val)")
return true
} )

let tolerance = 0.01 // boundary tolerance for floating point type

iterate2D( 0.0, 10.0, { $0 < 100.0 + tolerance } ,
   0.0,  5.0, { $0 <  50.0 + tolerance } ,
   {x,y in
print("x = \(x) y = \(y)")
return true  // false from block stops 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Tim Vermeulen via swift-evolution]

Does ZenHub have something that even remotely looks like a forum? I can’t find 
anything like that on their website. Or is your suggestion that we move all of 
swift-evo directly to GitHub?

> I'm open to ZenHub that can be integrate as part of GitHub for discussion, 
> pull changes and it makes it easier to reference to the patches within ZenHub 
> than from Discourse or other forums. Swiftly right?
> 
> https://www.zenhub.com
> 
> On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via 
> swift-evolutionwrote:
> > +1. Hirundo makes this format bearable, but it is still far from ideal. I 
> > see many advantages for using Discourse:
> > 
> > - It has actual syntax highlighting.
> > - It’s easier to moderate.
> > - It supports real-time updates.
> > - It’s easier to follow the flow of a conversation.
> > - It has better search.
> > 
> > I don’t doubt more people will take part in the Swift evolution process if 
> > we switch to Discourse.
> > 
> > >Branching...
> > >
> > >On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
> > >swift-evolutionwrote:
> > >>On Jul 29, 2016, at 5:14 PM, Brandon 
> > >>Knopewrote:
> > >>>
> > >>>Chris, has the core team discussed opening up a forum for discussing 
> > >>>proposal implementations.
> > >>>
> > >>>Some of us aren't as skilled as the core team or other contributors but 
> > >>>would like to learn. A forum is a much easier place for us to post for 
> > >>>code help and to help others with their questions. I think this could 
> > >>>help get more involved as it would be a more comfortable format for 
> > >>>them. Think of how there are Apple Developer forums and not mailing 
> > >>>lists for iOS betas etc.
> > >>>
> > >>>I am not saying moving swift-evo to forums *yet* but I believe a lot of 
> > >>>the newer programmers are more comfortable with a forum format, 
> > >>>especially when it comes to help and discussing code.
> > >>>
> > >>>Forums for contributors would:
> > >>>- be more familiar for a lot of the newer and not as experienced 
> > >>>developers
> > >>>- be easier to search
> > >>>- be easier to moderate (not really a problem yet)
> > >>
> > >>Hi Brandon,
> > >>
> > >>Moving from email to a forum system has come up before, but they have 
> > >>some disadvantages.One of major wins of email is that it is pervasive and 
> > >>can be adapted into other forms.For example, if you haven’t seen it yet, 
> > >>check out:
> > >>https://stylemac.com/hirundo/
> > >>
> > >>-Chris
> > >>
> > >We've discussed forums on swift-evolution before. Maybe it's time for 
> > >another go, with Swift 3 winding down.
> > >
> > >For context, prior discussions are on this 
> > >thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
> > >
> > >(-1 for mailman: it's hard for me to even properly find to all the 
> > >prior discussion about mailing lists, because of how mailman's archive 
> > >works...)
> > >
> > >
> > >News in the last few days is that Gmane is at least temporarily 
> > >disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
> > >
> > >
> > >I'd just like to vote once again 
> > >forDiscourse(http://www.discourse.org/faq/#what):-Excellentweb 
> > >interface(https://meta.discourse.org/), from the people who brought you 
> > >Stack Overflow(built-in search, etc.)
> > >- Read via email if that's your thing: it has "mailing list mode" which 
> > >includes 1-email-per-post, if that's your cup of tea
> > >-Reply via 
> > >email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)ifthat's
> > > your thing
> > >- It'sopen source(https://github.com/discourse/discourse)itself
> > >- I believe it has ways of getting content as JSON and/or RSS, so I'd 
> > >hardly say "can be adapted into other forms" is an exclusive feature of 
> > >email.
> > >
> > >And, Discourse providesfree hosting for community-friendly open-source 
> > >projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
> > > Istrongly 
> > >suspect(https://twitter.com/jtbandes/status/705886542309363712)Swiftwould 
> > >qualify for this.
> > >
> > >
> > >There have been several people on this list arguing in favor of mailing 
> > >lists — I encourage folks to go read the old thread for themselves.
> > >
> > >It's worth noting there are also plenty of voices that don't get heard on 
> > >this list, because people just don't like using mailing lists. One 
> > >example:https://twitter.com/pilky/status/755105431555608580___
> > >swift-evolution mailing list
> > >swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > >https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > >
> > >
> > 

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Chris Lattner via swift-evolution]

> On Jul 30, 2016, at 1:42 AM, Ian Partridge  wrote:
> 
> On 30 July 2016 at 02:33, Chris Lattner via swift-evolution
>  wrote:
>> I’m personally convinced that we don’t get to great string processing 
>> without regular expressions (as one
>> example), but they are clearly out of scope for Stage 1.
> 
> Foundation already has NSRegularExpression. Do you mean that the
> stdlib could potentially duplicate Foundation functionality? If so,
> what are the implications for Foundation (and
> swift-corelibs-foundation)? Does this also mean that other "stringy"
> functionality could arrive in the stdlib, for example a Swifty JSON
> serializer/deserializer?

As others have mentioned, the interesting thing in this space is language 
support for regex literals.  They should tie into the pattern matching 
constructs in the language (e.g. switch, if case, etc).

Better support for JSON is also interesting and possible over the next year, 
but it would be the domain of the corelibs folks.  I believe they have some 
ideas in this space, but probably aren’t ready to dive into it given that Swift 
3 isn’t done, and I’m not sure if there are any “plans”.

-Chris

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

Re: [swift-evolution] [Swift 3.x] What to expect?

[Chris Lattner via swift-evolution]

> On Jul 30, 2016, at 2:42 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> Given most discussion here is now about Swift 4, I wanted to ask the core 
> team what is the proposed course for the 3.x releases - should they contain 
> only non-additive changes (potentially breaking) or should minor additive 
> features be allowed as well? Given the strict focus of Swift 4, I think Swift 
> 3.x is the last place for the next two-three years for some minor 
> refinements/additions…

Hi Charlie,

I expect the spring release to simply be time based: whatever is ready to go 
out then will go out, but we won’t claim (e.g.) ABI stability.  For example, 
I’d hope for conditional conformances to be available in that release.

As for scheduling and planning, we’re planning the 3.x and 4 releases together, 
which means that the policies apply to 3.x as well: we need to get through 
Stage 1 before embarking on Stage 2.

-Chris

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

Re: [swift-evolution] [Idea] Specialising based on function parameter values

[Tino Heth via swift-evolution]

Hi Karl,

I started a discussion about such a concept (afair under the label 
"compile-time parameters"), and "completing generics" talks about it as well.
Although I think it is quite fundamental (Swift has no arrays of fixed 
size(!)), and shouldn't be that hard to implement, I'm not sure if it will fit 
into Swift 4.

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

[swift-evolution] [Idea] Specialising based on function parameter values

[Karl via swift-evolution]

I’ve had this idea floating around my head for a little while, and I’m not sure 
if it’s either really interesting or totally absurd.
Sorry if it’s not time for ideas like this yet. It’s not really a “proposal”, 
but it would be ABI-related I think.

So, the idea: The compiler can generate variations of functions where it 
statically substitutes a type for a placeholder name. Would it also be possible 
to statically generate a variation of a function if a parameter is a certain 
value?

I have some code which scans a sequence of bytes. The bytes may be in UTF-8, 
UTF-16 or UTF-32, and any endianness flavour thereof. Fortunately, the scanner 
is looking for a ASCII-compatible characters which have the same value (albeit 
a different size) in each encoding, so this can be implemented as a generic 
function based on the type of the CodeUnit (UInt8/16/32 respectively). 
Something roughly like this:

> @_specialize(UInt8)
> @_specialize(UInt16)
> @_specialize(UInt32)
> func scanCharacters(from bytes: [UInt8], 
> hasMismatchedEndianness: Bool) -> ... {
> 
>   var byteIterator = bytes.makeIterator()
>   while let nextByte = byteIterator.next() {
> 
>   var codeUnit : U
>   // The compiler will statically optimise this branching away 
> because generics.
>   if size(of: U.self) == 1 { 
>   codeUnit = numericCast(nextByte)
>   }
>   else {
>   codeUnit = consumeCodeUnit(withInitialByte: nextByte, 
> source: byteIterator)
>   // Even when marking this _slowPath(), there is a 
> significant overhead.
>   if hasMismatchedEndianness {
>   codeUnit = codeUnit.byteSwapped
>   }
>   }
> 
>   // Process the code-unit
>   }
> }


However, we still have a problem with this endianness flag. All it requires is 
that after we consume an entire CodeUnit from the buffer, that we byte-swap it 
before checking its value. I don’t want to duplicate the entire function code 
to deal with this one variation in parameter value, but this is a very hot 
code-path and the branching overhead is significant.

So I would like to tell the compiler that we branch a lot on 
`hasMismatchedEndianness`, so it can generate and optimise variations of the 
function while keeping the abstraction level high and the maintenance burden 
low. There are lots of contexts where this could be useful - not just your 
typical Boolean switches, but Optionals, too. Even general value-types with 
specific values that are heavily branched against could benefit from these 
kinds of optimisations.


Thoughts? Would something like this be possible/valuable?


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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Brandon Knope via swift-evolution]

Even if we just moved swift-user to a forum as a test, I think it would be 
greatly revealing and helpful. It would benefit the most overnight. 

It may be difficult to convince people who have used mailing lists for many 
years to suddenly move away to something "new". A slow migration on the other 
hand may end up being more persuasive. 

Brandon 

Sent from my iPad

> On Jul 30, 2016, at 10:57 AM, Honza Dvorsky via swift-evolution 
>  wrote:
> 
> +1 for a forum or other editable medium. 
>> On Sat, Jul 30, 2016 at 4:55 PM Charles Srstka via swift-evolution 
>>  wrote:
>> +1 from me as well to anything that allows editing typos after posting.
>> 
>> Charles
>> 
>>> On Jul 30, 2016, at 8:22 AM, Haravikk via swift-evolution 
>>>  wrote:
>>> 
>>> But I like sending out my messages then regretting the many typos and 
>>> mistakes I only seem able to notice immediately after it's too late to do 
>>> anything about it!
>>> 
>>> (so yeah, +1)
>>> 
 On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution 
  wrote:
 
 +1 to move away from mail ;).
 
 Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack 
 extensively.
 
 [0]: https://slack.com/
 [1]: http://www.teamwire.eu/
 
 Von meinem iPhone gesendet
 
> Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution 
> :
> 
> I'm open to ZenHub that can be integrate as part of GitHub for 
> discussion, pull changes and it makes it easier to reference to the 
> patches within ZenHub than from Discourse or other forums. Swiftly right?
> 
> https://www.zenhub.com
> 
>> On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution 
>>  wrote:
>> +1. Hirundo makes this format bearable, but it is still far from ideal. 
>> I see many advantages for using Discourse:
>> 
>> - It has actual syntax highlighting.
>> - It’s easier to moderate.
>> - It supports real-time updates.
>> - It’s easier to follow the flow of a conversation.
>> - It has better search.
>> 
>> I don’t doubt more people will take part in the Swift evolution process 
>> if we switch to Discourse.
>> 
>> > Branching...
>> >
>> > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
>> > swift-evolutionwrote:
>> > > On Jul 29, 2016, at 5:14 PM, Brandon 
>> > > Knopewrote:
>> > > >
>> > > >Chris, has the core team discussed opening up a forum for 
>> > > >discussing proposal implementations.
>> > > >
>> > > >Some of us aren't as skilled as the core team or other contributors 
>> > > >but would like to learn. A forum is a much easier place for us to 
>> > > >post for code help and to help others with their questions. I think 
>> > > >this could help get more involved as it would be a more comfortable 
>> > > >format for them. Think of how there are Apple Developer forums and 
>> > > >not mailing lists for iOS betas etc.
>> > > >
>> > > >I am not saying moving swift-evo to forums *yet* but I believe a 
>> > > >lot of the newer programmers are more comfortable with a forum 
>> > > >format, especially when it comes to help and discussing code.
>> > > >
>> > > >Forums for contributors would:
>> > > >- be more familiar for a lot of the newer and not as experienced 
>> > > >developers
>> > > >- be easier to search
>> > > >- be easier to moderate (not really a problem yet)
>> > >
>> > > Hi Brandon,
>> > >
>> > > Moving from email to a forum system has come up before, but they 
>> > > have some disadvantages.One of major wins of email is that it is 
>> > > pervasive and can be adapted into other forms.For example, if you 
>> > > haven’t seen it yet, check out:
>> > > https://stylemac.com/hirundo/
>> > >
>> > > -Chris
>> > >
>> > We've discussed forums on swift-evolution before. Maybe it's time for 
>> > another go, with Swift 3 winding down.
>> >
>> > For context, prior discussions are on this 
>> > thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>> >
>> > (-1 for mailman: it's hard for me to even properly find to all 
>> > the prior discussion about mailing lists, because of how mailman's 
>> > archive works...)
>> >
>> >
>> > News in the last few days is that Gmane is at least temporarily 
>> > disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>> >
>> >
>> > I'd just like to vote once again 
>> > forDiscourse(http://www.discourse.org/faq/#what):-Excellent web 
>> > 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Honza Dvorsky via swift-evolution]

+1 for a forum or other editable medium.
On Sat, Jul 30, 2016 at 4:55 PM Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 from me as well to anything that allows editing typos after posting.
>
> Charles
>
> On Jul 30, 2016, at 8:22 AM, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> But I like sending out my messages then regretting the many typos and
> mistakes I only seem able to notice immediately after it's too late to do
> anything about it!
>
> (so yeah, +1)
>
> On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1 to move away from mail ;).
>
> Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack
> extensively.
>
> [0]: https://slack.com/
> [1]: http://www.teamwire.eu/
>
> Von meinem iPhone gesendet
>
> Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution <
> swift-evolution@swift.org>:
>
> I'm open to ZenHub that can be integrate as part of GitHub for discussion,
> pull changes and it makes it easier to reference to the patches within
> ZenHub than from Discourse or other forums. Swiftly right?
>
> https://www.zenhub.com
>
> On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> +1. Hirundo makes this format bearable, but it is still far from ideal. I
>> see many advantages for using Discourse:
>>
>> - It has actual syntax highlighting.
>> - It’s easier to moderate.
>> - It supports real-time updates.
>> - It’s easier to follow the flow of a conversation.
>> - It has better search.
>>
>> I don’t doubt more people will take part in the Swift evolution process
>> if we switch to Discourse.
>>
>> > Branching...
>> >
>> > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution<
>> swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
>> > > On Jul 29, 2016, at 5:14 PM, Brandon Knope> bkn...@me.com)>wrote:
>> > > >
>> > > >Chris, has the core team discussed opening up a forum for discussing
>> proposal implementations.
>> > > >
>> > > >Some of us aren't as skilled as the core team or other contributors
>> but would like to learn. A forum is a much easier place for us to post for
>> code help and to help others with their questions. I think this could help
>> get more involved as it would be a more comfortable format for them. Think
>> of how there are Apple Developer forums and not mailing lists for iOS betas
>> etc.
>> > > >
>> > > >I am not saying moving swift-evo to forums *yet* but I believe a lot
>> of the newer programmers are more comfortable with a forum format,
>> especially when it comes to help and discussing code.
>> > > >
>> > > >Forums for contributors would:
>> > > >- be more familiar for a lot of the newer and not as experienced
>> developers
>> > > >- be easier to search
>> > > >- be easier to moderate (not really a problem yet)
>> > >
>> > > Hi Brandon,
>> > >
>> > > Moving from email to a forum system has come up before, but they have
>> some disadvantages.One of major wins of email is that it is pervasive and
>> can be adapted into other forms.For example, if you haven’t seen it yet,
>> check out:
>> > > https://stylemac.com/hirundo/
>> > >
>> > > -Chris
>> > >
>> > We've discussed forums on swift-evolution before. Maybe it's time for
>> another go, with Swift 3 winding down.
>> >
>> > For context, prior discussions are on this thread:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>> >
>> > (-1 for mailman: it's hard for me to even properly find to all the
>> prior discussion about mailing lists, because of how mailman's archive
>> works...)
>> >
>> >
>> > News in the last few days is that Gmane is at least temporarily
>> disappearing:
>> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>> >
>> >
>> > I'd just like to vote once again forDiscourse(
>> http://www.discourse.org/faq/#what):-Excellent web interface(
>> https://meta.discourse.org/), from the people who brought you Stack
>> Overflow(built-in search, etc.)
>> > - Read via email if that's your thing: it has "mailing list mode" which
>> includes 1-email-per-post, if that's your cup of tea
>> > -Reply via email(
>> https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if
>> that's your thing
>> > - It'sopen source(https://github.com/discourse/discourse)itself
>> > - I believe it has ways of getting content as JSON and/or RSS, so I'd
>> hardly say "can be adapted into other forms" is an exclusive feature of
>> email.
>> >
>> > And, Discourse providesfree hosting for community-friendly open-source
>> projects(
>> http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
>> Istrongly suspect(
>> https://twitter.com/jtbandes/status/705886542309363712)Swift would
>> qualify for this.
>> >
>> >
>> > There have been several people on this list arguing in favor of 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Charles Srstka via swift-evolution]

+1 from me as well to anything that allows editing typos after posting.

Charles

> On Jul 30, 2016, at 8:22 AM, Haravikk via swift-evolution 
>  wrote:
> 
> But I like sending out my messages then regretting the many typos and 
> mistakes I only seem able to notice immediately after it's too late to do 
> anything about it!
> 
> (so yeah, +1)
> 
>> On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution 
>> > wrote:
>> 
>> +1 to move away from mail ;).
>> 
>> Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack 
>> extensively.
>> 
>> [0]: https://slack.com/ 
>> [1]: http://www.teamwire.eu/ 
>> 
>> Von meinem iPhone gesendet
>> 
>> Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution 
>> >:
>> 
>>> I'm open to ZenHub that can be integrate as part of GitHub for discussion, 
>>> pull changes and it makes it easier to reference to the patches within 
>>> ZenHub than from Discourse or other forums. Swiftly right?
>>> 
>>> https://www.zenhub.com 
>>> 
>>> On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution 
>>> > wrote:
>>> +1. Hirundo makes this format bearable, but it is still far from ideal. I 
>>> see many advantages for using Discourse:
>>> 
>>> - It has actual syntax highlighting.
>>> - It’s easier to moderate.
>>> - It supports real-time updates.
>>> - It’s easier to follow the flow of a conversation.
>>> - It has better search.
>>> 
>>> I don’t doubt more people will take part in the Swift evolution process if 
>>> we switch to Discourse.
>>> 
>>> > Branching...
>>> >
>>> > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
>>> > swift-evolution>> > (mailto:swift-evolution@swift.org 
>>> > )>wrote:
>>> > > On Jul 29, 2016, at 5:14 PM, Brandon Knope>> > > (mailto:bkn...@me.com 
>>> > > )>wrote:
>>> > > >
>>> > > >Chris, has the core team discussed opening up a forum for discussing 
>>> > > >proposal implementations.
>>> > > >
>>> > > >Some of us aren't as skilled as the core team or other contributors 
>>> > > >but would like to learn. A forum is a much easier place for us to post 
>>> > > >for code help and to help others with their questions. I think this 
>>> > > >could help get more involved as it would be a more comfortable format 
>>> > > >for them. Think of how there are Apple Developer forums and not 
>>> > > >mailing lists for iOS betas etc.
>>> > > >
>>> > > >I am not saying moving swift-evo to forums *yet* but I believe a lot 
>>> > > >of the newer programmers are more comfortable with a forum format, 
>>> > > >especially when it comes to help and discussing code.
>>> > > >
>>> > > >Forums for contributors would:
>>> > > >- be more familiar for a lot of the newer and not as experienced 
>>> > > >developers
>>> > > >- be easier to search
>>> > > >- be easier to moderate (not really a problem yet)
>>> > >
>>> > > Hi Brandon,
>>> > >
>>> > > Moving from email to a forum system has come up before, but they have 
>>> > > some disadvantages.One of major wins of email is that it is pervasive 
>>> > > and can be adapted into other forms.For example, if you haven’t seen it 
>>> > > yet, check out:
>>> > > https://stylemac.com/hirundo/ 
>>> > >
>>> > > -Chris
>>> > >
>>> > We've discussed forums on swift-evolution before. Maybe it's time for 
>>> > another go, with Swift 3 winding down.
>>> >
>>> > For context, prior discussions are on this 
>>> > thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>>> >  
>>> > 
>>> >
>>> > (-1 for mailman: it's hard for me to even properly find to all the 
>>> > prior discussion about mailing lists, because of how mailman's archive 
>>> > works...)
>>> >
>>> >
>>> > News in the last few days is that Gmane is at least temporarily 
>>> > disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>>> >  
>>> > 
>>> >
>>> >
>>> > I'd just like to vote once again 
>>> > forDiscourse(http://www.discourse.org/faq/#what):-Excellent 
>>> >  web 
>>> > interface(https://meta.discourse.org/ ), 
>>> > from the people who brought you Stack Overflow(built-in search, etc.)
>>> > - Read via email if that's your thing: it has "mailing list mode" which 
>>> > includes 1-email-per-post, if that's your cup of tea
>>> > -Reply via 
>>> > 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Haravikk via swift-evolution]

But I like sending out my messages then regretting the many typos and mistakes 
I only seem able to notice immediately after it's too late to do anything about 
it!

(so yeah, +1)

> On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution 
>  wrote:
> 
> +1 to move away from mail ;).
> 
> Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack 
> extensively.
> 
> [0]: https://slack.com/ 
> [1]: http://www.teamwire.eu/ 
> 
> Von meinem iPhone gesendet
> 
> Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution 
> >:
> 
>> I'm open to ZenHub that can be integrate as part of GitHub for discussion, 
>> pull changes and it makes it easier to reference to the patches within 
>> ZenHub than from Discourse or other forums. Swiftly right?
>> 
>> https://www.zenhub.com 
>> 
>> On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution 
>> > wrote:
>> +1. Hirundo makes this format bearable, but it is still far from ideal. I 
>> see many advantages for using Discourse:
>> 
>> - It has actual syntax highlighting.
>> - It’s easier to moderate.
>> - It supports real-time updates.
>> - It’s easier to follow the flow of a conversation.
>> - It has better search.
>> 
>> I don’t doubt more people will take part in the Swift evolution process if 
>> we switch to Discourse.
>> 
>> > Branching...
>> >
>> > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
>> > swift-evolution> > (mailto:swift-evolution@swift.org 
>> > )>wrote:
>> > > On Jul 29, 2016, at 5:14 PM, Brandon Knope> > > (mailto:bkn...@me.com 
>> > > )>wrote:
>> > > >
>> > > >Chris, has the core team discussed opening up a forum for discussing 
>> > > >proposal implementations.
>> > > >
>> > > >Some of us aren't as skilled as the core team or other contributors but 
>> > > >would like to learn. A forum is a much easier place for us to post for 
>> > > >code help and to help others with their questions. I think this could 
>> > > >help get more involved as it would be a more comfortable format for 
>> > > >them. Think of how there are Apple Developer forums and not mailing 
>> > > >lists for iOS betas etc.
>> > > >
>> > > >I am not saying moving swift-evo to forums *yet* but I believe a lot of 
>> > > >the newer programmers are more comfortable with a forum format, 
>> > > >especially when it comes to help and discussing code.
>> > > >
>> > > >Forums for contributors would:
>> > > >- be more familiar for a lot of the newer and not as experienced 
>> > > >developers
>> > > >- be easier to search
>> > > >- be easier to moderate (not really a problem yet)
>> > >
>> > > Hi Brandon,
>> > >
>> > > Moving from email to a forum system has come up before, but they have 
>> > > some disadvantages.One of major wins of email is that it is pervasive 
>> > > and can be adapted into other forms.For example, if you haven’t seen it 
>> > > yet, check out:
>> > > https://stylemac.com/hirundo/ 
>> > >
>> > > -Chris
>> > >
>> > We've discussed forums on swift-evolution before. Maybe it's time for 
>> > another go, with Swift 3 winding down.
>> >
>> > For context, prior discussions are on this 
>> > thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>> >  
>> > 
>> >
>> > (-1 for mailman: it's hard for me to even properly find to all the 
>> > prior discussion about mailing lists, because of how mailman's archive 
>> > works...)
>> >
>> >
>> > News in the last few days is that Gmane is at least temporarily 
>> > disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>> >  
>> > 
>> >
>> >
>> > I'd just like to vote once again 
>> > forDiscourse(http://www.discourse.org/faq/#what):-Excellent 
>> >  web 
>> > interface(https://meta.discourse.org/ ), from 
>> > the people who brought you Stack Overflow(built-in search, etc.)
>> > - Read via email if that's your thing: it has "mailing list mode" which 
>> > includes 1-email-per-post, if that's your cup of tea
>> > -Reply via 
>> > email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if
>> >   
>> > that's your thing
>> > - It'sopen source(https://github.com/discourse/discourse)itself 
>> > 
>> > - I believe it has ways of getting content as 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Johannes Neubauer via swift-evolution]

+1 to move away from mail ;).

Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack 
extensively.

[0]: https://slack.com/
[1]: http://www.teamwire.eu/

Von meinem iPhone gesendet

> Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution 
> :
> 
> I'm open to ZenHub that can be integrate as part of GitHub for discussion, 
> pull changes and it makes it easier to reference to the patches within ZenHub 
> than from Discourse or other forums. Swiftly right?
> 
> https://www.zenhub.com
> 
>> On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution 
>>  wrote:
>> +1. Hirundo makes this format bearable, but it is still far from ideal. I 
>> see many advantages for using Discourse:
>> 
>> - It has actual syntax highlighting.
>> - It’s easier to moderate.
>> - It supports real-time updates.
>> - It’s easier to follow the flow of a conversation.
>> - It has better search.
>> 
>> I don’t doubt more people will take part in the Swift evolution process if 
>> we switch to Discourse.
>> 
>> > Branching...
>> >
>> > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
>> > swift-evolutionwrote:
>> > > On Jul 29, 2016, at 5:14 PM, Brandon 
>> > > Knopewrote:
>> > > >
>> > > >Chris, has the core team discussed opening up a forum for discussing 
>> > > >proposal implementations.
>> > > >
>> > > >Some of us aren't as skilled as the core team or other contributors but 
>> > > >would like to learn. A forum is a much easier place for us to post for 
>> > > >code help and to help others with their questions. I think this could 
>> > > >help get more involved as it would be a more comfortable format for 
>> > > >them. Think of how there are Apple Developer forums and not mailing 
>> > > >lists for iOS betas etc.
>> > > >
>> > > >I am not saying moving swift-evo to forums *yet* but I believe a lot of 
>> > > >the newer programmers are more comfortable with a forum format, 
>> > > >especially when it comes to help and discussing code.
>> > > >
>> > > >Forums for contributors would:
>> > > >- be more familiar for a lot of the newer and not as experienced 
>> > > >developers
>> > > >- be easier to search
>> > > >- be easier to moderate (not really a problem yet)
>> > >
>> > > Hi Brandon,
>> > >
>> > > Moving from email to a forum system has come up before, but they have 
>> > > some disadvantages.One of major wins of email is that it is pervasive 
>> > > and can be adapted into other forms.For example, if you haven’t seen it 
>> > > yet, check out:
>> > > https://stylemac.com/hirundo/
>> > >
>> > > -Chris
>> > >
>> > We've discussed forums on swift-evolution before. Maybe it's time for 
>> > another go, with Swift 3 winding down.
>> >
>> > For context, prior discussions are on this 
>> > thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>> >
>> > (-1 for mailman: it's hard for me to even properly find to all the 
>> > prior discussion about mailing lists, because of how mailman's archive 
>> > works...)
>> >
>> >
>> > News in the last few days is that Gmane is at least temporarily 
>> > disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>> >
>> >
>> > I'd just like to vote once again 
>> > forDiscourse(http://www.discourse.org/faq/#what):-Excellent web 
>> > interface(https://meta.discourse.org/), from the people who brought you 
>> > Stack Overflow(built-in search, etc.)
>> > - Read via email if that's your thing: it has "mailing list mode" which 
>> > includes 1-email-per-post, if that's your cup of tea
>> > -Reply via 
>> > email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if
>> >  that's your thing
>> > - It'sopen source(https://github.com/discourse/discourse)itself
>> > - I believe it has ways of getting content as JSON and/or RSS, so I'd 
>> > hardly say "can be adapted into other forms" is an exclusive feature of 
>> > email.
>> >
>> > And, Discourse providesfree hosting for community-friendly open-source 
>> > projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
>> >  Istrongly 
>> > suspect(https://twitter.com/jtbandes/status/705886542309363712)Swift would 
>> > qualify for this.
>> >
>> >
>> > There have been several people on this list arguing in favor of mailing 
>> > lists — I encourage folks to go read the old thread for themselves.
>> >
>> > It's worth noting there are also plenty of voices that don't get heard on 
>> > this list, because people just don't like using mailing lists. One 
>> > example:https://twitter.com/pilky/status/755105431555608580___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> >
>> >
>> 

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Daniel Leping via swift-evolution]

Hey guys,

TL;DR; proposed solution in the second half.

actually, we are already doing something like this without modifying the
language itself here:
https://github.com/crossroadlabs/Regex/blob/swift2.x/Regex/String%2BRegex.swift

It's Scala style (.r notion). Works perfectly with switch keyword:

*switch letter {*

*//note .r after the string literal of the pattern*

*case "\\d".r: print("digit")*

*case "[a-z]".r: print("letter")*

*default: print("bizarre symbol")*

*}*

You can try it in release 0.8 (for Swift 2.x, Swift 3.0 release with this
feature is not issued yet).

What we really lack though is matching objects to tuples with *switch*.
Here is the explanation:

Let's say we have a match:

let match = "(\d*)(.*)".r.findFirst("123abc")

what I would love to do with it is the following:

*switch match {*

*case (_, "xyz"): print("end of alphabet")*

*case ("123", _): print("beginning of numerics")*

*default: print("I don't care")*

*}*

It would be possible if ~= operator was a bit more powerful and allow to
match against tuples (currently, it can't even without underscores). What I
would like to propose (will create an evolution proposal later if it's
something the core-team is willing to consider) is to:

1. Either extend ~= to allow to match tuples. Currently, I see it the
following way (an example):

*// you have to create an operator for each tuple size, any ideas on a
better solution?*

*func ~=(match:Match, tuple:(A?, B?)) -> Bool*

Why optionals? Well, this way we could process _ substitutions.

2. Implement Scala-like apply/unapply. Good too, but option one sounds more
"Swiftish" to me personally.


Why is this cool? Well, this is not just about Regular Expressions, it's
rather overall language power and Regex is a nice example. I think there
will be a lot of examples, especially with the web apps. Some additional
ones I can think of right away is processing of URL or query params or
"parsing" of message object (i.e. in Actors or Queues).

Why making the match object to be an enum would not work? Well, first of
all there is some more additional info in it which I would like to keep
hidden for the user (i.e. full match, etc.) and not to push to match to.
This is not just one use case and in others it might become even more
important.

Hope it's clear and understandable (let me know if not and I'll bring it in
more details). Would this fit to Swift 3.x (no existing code impact) or to
Swift 4.x?

Best,

Daniel

On Sat, Jul 30, 2016 at 12:37 PM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> > Foundation already has NSRegularExpression. Do you mean that the
> > stdlib could potentially duplicate Foundation functionality?
>
> NSRegularExpression is not really easy to use for most common usecases
> (first match in string, etc.) + it lacks a lot of features e.g. Python has
> (named groups, etc.). I've personally never used NSRegularExpression and
> rather wrote an ObjC wrapper around re2 (https://github.com/google/re2/).
>
> I'd really like Swift's regex to be much more powerful and be able to
> match against it in a switch:
>
> switch someString {
> case /\d+:
> ...
> case /w+:
> ...
> ...
>
> Also, you can have compile-time check whether the expression is valid if
> regex is part of the language. But that's kind of getting too specific and
> away from the original discussion.
>
>
> > If so,
> > what are the implications for Foundation (and
> > swift-corelibs-foundation)? Does this also mean that other "stringy"
> > functionality could arrive in the stdlib, for example a Swifty JSON
> > serializer/deserializer?
> >
> > Best wishes,
> >
> > --
> > Ian Partridge
> > ___
> > 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] Improved value and move semantics

[Haravikk via swift-evolution]

> On 29 Jul 2016, at 17:42, Bram Beernink via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Would it be possible to improve value and move semantics (performance) in 
> Swift? Consider this possible Swift code in a future release of Swift:
> 
> let array1 : [String] = ["Val1", "Val2"]
> let array2 = array1.appended(“Val3”) // Copy of array1 with “Val3” appended. 
> array1 is left untouched. Nothing special yet.
> var array3 : [String] = [“Var1”]
> array3 = array3.appended(“Var2”) // array3 can just be mutated to add “Var2”, 
> while maintaining value semantics. Swift can recognize that array3’s old 
> state is not referenced anywhere in the future.
> let array4 = array2.appended("Val4").appended("Val5") // Copy of array2 with 
> both "Val4" and "Val5" appended. In this case, “Val5” can also be appended by 
> mutation.

Well, for the array3 = array3.appended("Var2") example this could possibly be 
addressed by an attribute to indicate to the compiler that .appended() has a 
mutating variant, as this will allow it to issue a warning when the assignment 
is to the same variable, which would address that simple case (and provide more 
awareness of the mutating options and encourage developers to use them).

> This example illustrates improved value semantics with a string array. But it 
> would be good if this can work with any struct. Maybe via something similar 
> to isUniquelyReferenced? Or maybe you can even have a “smart” self in a 
> non-mutating func in a struct:
> struct Array {
> func appended(e : T) -> Array { // No mutating keyword!
> self.append(e) // self would either be mutated here if the current 
> ref count of self is 1, and self is either a “rvalue” or self’s old state 
> cannot possibly referenced anymore after this call. Otherwise, "self” would 
> actually be a copy of self.
> return self
> }
> }

I don't know about allowing mutation of self in non-mutating methods, that 
seems confusing; however, I'd be surprised if the compiler doesn't already 
detect variables that only exist to create a copy that is discarded.

The compiler should already be trying to inline very simple methods like the 
common copy -> mutate -> return style of non-mutating implementations, in which 
case it should be able to identify that a copy is being created only to 
overwrite the original anyway, so can be eliminated. Do you believe that this 
isn't currently being done?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Haravikk via swift-evolution]

This is very interesting, but it'll probably be a little while before I can 
fully get my head around it.

One query though; an example mentioned is adding @owns(Element) to the 
Generator protocol, but associated types feel a little different to me; you 
mention using the strong keyword as an alternative, but I wonder if that might 
actually be a better fit for the associated type case, while @owns works 
elsewhere, or perhaps strong could even be made a shorthand for simpler cases? 
Just thinking out loud I guess, it would be nice to hear the thought process 
around associated types; most (possibly all I don't remember) cases in which 
I've used associated types it has been for strong references, so it seems like 
that should be as easy as possible to do under the new opt-in approach.

But yeah, I generally agree that this ought to be opt-in, as it's an area I do 
stumble upon quite a bit myself (in many languages).

> On 30 Jul 2016, at 02:42, Andrew Bennett via swift-evolution 
>  wrote:
> 
> I'd like an opt-in way to verify and prevent unintentional strong references 
> in Swift.
> 
> This can be used to verify ownership structures, and ultimately avoid retain 
> cycles.
> 
> Read a draft proposal here:
> https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/-explicit-ownership-type-attribute.md
>  
> 
> 
> TL;DR:
> 
> If you have any questions please read the proposal before asking here.
> 
> It's an opt-in attribute that defines a whitelist of types something can own. 
> For example:
> 
> @owns(TypeA, TypeB) struct TypeC { ... }
> 
> I wrote this a few months ago, but we weren't accepting additive proposals. 
> Now we're explicitly looking for something like this:
> 
> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory 
> ownership model to Swift is highly desired by systems programmers and folks 
> who want predictable and deterministic performance (for example, in real time 
> audio processing code).  More pertinent to the goals of Swift 4, this feature 
> is important because it fundamentally shapes the ABI.  It informs code 
> generation for “inout", how low-level “addressors” work in the ABI, impacts 
> the Swift runtime, and will have a significant impact on the type system and 
> name mangling. 
> 
>  - Chris 
> 
> 
> 
> 
> Here's a link to the version of the proposal 
> 
>  when I sent this email.
> ___
> 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] [Swift 3.x] What to expect?

[Charlie Monroe via swift-evolution]

Given most discussion here is now about Swift 4, I wanted to ask the core team 
what is the proposed course for the 3.x releases - should they contain only 
non-additive changes (potentially breaking) or should minor additive features 
be allowed as well? Given the strict focus of Swift 4, I think Swift 3.x is the 
last place for the next two-three years for some minor refinements/additions...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Muse M via swift-evolution]

We will need a platform that live near the code (repo). Contextual
switching is expensive for every developers especially lengthy discussions
could have save us man-hours.

On Sat, Jul 30, 2016 at 3:42 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> I have not enough experience with all the possible alternatives to give a
> vote for a specific system, but the mail-approach can be very tedious, and
> there are several things that a just not possible or very clumsy:
> - You can't edit a message that has been send
> - Tagging capabilities are very limited (no public tags…)
> - Searching & linking… (quite sure this has been mentioned extensively ;-)
> - Mail.app splits topics in strange ways, so it is very hard to follow
> discussions
>
> Sending a message is the only way of interaction, but imho it would be
> beneficial to have a lightweight alternative to just signal agreement (or
> something else) to posts.
> Receiving little or no feedback can be frustrating, and I expect there are
> many messages that didn't receive the attention they deserved, just because
> it is somewhat stupid to write an response that just says "absolutely
> right, I have nothing to add here" (feel free to prove me wrong ;-)
>
> Mailing lists have some benefits as well, but afaics, Discourse can
> basically run a list on top of all the discussions, so we wouldn't loose
> anything.
>
> Tino
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Ian Partridge via swift-evolution]

On 30 July 2016 at 02:33, Chris Lattner via swift-evolution
 wrote:
> I’m personally convinced that we don’t get to great string processing without 
> regular expressions (as one
> example), but they are clearly out of scope for Stage 1.

Foundation already has NSRegularExpression. Do you mean that the
stdlib could potentially duplicate Foundation functionality? If so,
what are the implications for Foundation (and
swift-corelibs-foundation)? Does this also mean that other "stringy"
functionality could arrive in the stdlib, for example a Swifty JSON
serializer/deserializer?

Best wishes,

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

[swift-evolution] [Swift 4] Cross-cutting concerns and patterns

[Jonathan Hull via swift-evolution]

I am curious if we could find a way/place to talk about larger cross-cutting 
syntax issues that may inform the design of several proposals.  In other words, 
this might be a good time to explicitly look at the forest (vs. the trees) and 
brainstorm about the wider picture (which can later be referenced for more 
specific issues).

Here are a few examples of those types of concerns:

• How to order structures which aren’t defined together, without tightly 
coupling them.  This most obvious example of this are operators and order of 
operation, but there are other potential features which could draw on similar 
solutions.  For example, I proposed a feature a while back where we could have 
factory-style methods which were fully extensible, but it required a defined 
ordering of subclasses factory methods being called.  This may also affect the 
design of mix-ins and other advanced features.

• How to disambiguate which implementation is called when it is ambiguous.  
Again, this will affect the design of mix-ins, but it may also allow things 
like calling a specific ancestor class’s implementation or calling the default 
implementation of a protocol from an implementor.  I believe 
'structure.P::method’ and 'structure.method using P’ were two potential syntax 
ideas put forward.

• Renaming of an occurrence of something in a specific context.  This was 
talked about with regards to importing (and renaming certain methods within a 
file/module to avoid conflicts).  It also came up when talking about 
conflicting protocols.  For example, you might be able to say ‘var x:Int 
implements P.y’ to say that this declaration implements the protocol P’s 
requirement ‘var x:Int' even though it has a different name.  

(and many more)


It makes sense to me to consider these very different use-cases together for at 
least a moment to see if any obvious general syntax shakes loose that wasn’t 
apparent when considering each separate use-case/proposal in isolation.  I also 
think there are probably issues where we might say “this syntax is 
unprecedented in Swift… but we have 10 very different use-cases that it makes 
sense for, so let’s bring it in”.

In general, I think it would provide better guide posts for proposals (as 
things like the generics manifesto have).

Thoughts?  What is the best approach to figure out what these cross-cutting 
concerns might be?

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