Re: [swift-evolution] [Pitch] Guard/Catch

[Tyler Cloutier via swift-evolution]

Also the Scala approach already works quite nicely in Swift 4 in case anyone 
was curious:

enum Try {
case success(T)
case failure(Error)

init(_ f: @autoclosure () throws -> T) {
do {
self = .success(try f())
} catch {
self = .failure(error)
}
}
}


let handlerDisposableTry = Try(try startHandler(observer))

switch handlerDisposableTry {
case .success(let x):
x?.dispose()
case .failure(let error):
print(error)
}

It’s just a touch awkward with the double try.

Tyler


> On Oct 7, 2017, at 10:42 PM, Tyler Cloutier  wrote:
> 
>> try startHandler(observer) catch {
>> observer.sendFailed(error)
>> }
> 
> 
> Technically the above doesn’t make sense. Please disregard.
> 
>> On Oct 7, 2017, at 10:35 PM, Tyler Cloutier > > wrote:
>> 
>> Has there been any progress on this? I came here to propose this but came 
>> upon this thread first.
>> 
>> This proposal goes way beyond sugar. I find myself constantly in the 
>> following situation:
>> 
>> let observer = Observer(with: CircuitBreaker(holding: self))
>> do {
>> let handlerDisposable = try startHandler(observer)
>> } catch {
>> observer.sendFailed(error)
>> }
>> 
>> cancelDisposable = ActionDisposable {
>> observer.sendInterrupted()
>> handlerDisposable?.dispose() // Error handlerDisposable is 
>> not defined here
>> }
>> 
>> It’s not as simple as putting it all in the do block because then I’ll be 
>> catching errors I might not want to catch! (In this case if the initializer 
>> of ActionDisposable was capable of throwing.)
>> 
>> This is my frustration with every language that has this style of error 
>> handling. FWIW, Scala is the only language that I have seen with this style 
>> of error handling that solves this problem. The built-in type `Try` combined 
>> with pattern matching fixes this issue of over extending the catch area. 
>> Which is kinda nifty and also bridges the functional gap as well.
>> 
>> object Try {
>>  /** Constructs a `Try` using the by-name parameter.  This
>>  * method will ensure any non-fatal exception is caught and a
>> * `Failure` object is returned.
>> def apply[T](r: => T): Try[T] =
>>   try Success(r) catch {
>> case NonFatal(e) => Failure(e)
>>   }
>> }
>> }
>> 
>> It also would make
>> 
>> try startHandler(observer) catch {
>> observer.sendFailed(error)
>> }
>> 
>> an obvious extension which to me makes sense since it’s just treating the 
>> one function call expression as it’s own implicit do block.
>> 
>> Tyler
>> 
>> 
>> 
>>> On Jul 11, 2017, at 10:31 AM, Christopher Kornher via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> Begin forwarded message:
>>> 
>>> From: Christopher Kornher >
>>> Subject: Re: [swift-evolution] [Pitch] Guard/Catch
>>> Date: July 10, 2017 at 5:10:15 PM MDT
>>> To: Elviro Rocca >> >
>>> 
>>> This messages was modified from the original accidentally sent out 
>>> privately, earlier.
>>> 
>>> FYI this works today in Xcode 9.0 beta 2 playgrounds:
>>> 
>>> ```
>>> class X {
>>> init() throws {}
>>> 
>>> func foo() {
>>> print( "Things succeeded" )
>>> }
>>> }
>>> 
>>> func bar() throws -> X  { return try X() }
>>> 
>>> 
>>> func f()
>>> {
>>> guard let x1:X = try? X(), let x2:X = try? bar() else {
>>> print( "Things failed ")
>>> return
>>> }
>>> 
>>> x1.foo()
>>> x2.foo()
>>> }
>>> 
>>> f()// works
>>> ```
>>> 
>>> 
>>> Most of the examples of this proposed feature don’t handle the exceptions 
>>> other than to perform an early return. 
>>> So, without handing exceptions,  the only unhandled case is a non-returning 
>>> throwing function or init:
>>>  
>>> ```
>>> class X {
>>> init() throws {}
>>> 
>>> func foo() {
>>> print( "Things succeeded" )
>>> }
>>> }
>>> 
>>> func bar() throws{ let _ =  try X() }
>>> 
>>> 
>>> func f()
>>> {
>>> do {
>>> try bar()
>>> } catch {
>>> return
>>> }
>>> 
>>> guard let x:X = try? X() else {
>>> print( "Things failed ")
>>> return
>>> }
>>> 
>>> x.foo()
>>> }
>>> 
>>> f()// works
>>> ```
>>> 
>>> Having to call a throwing, Void method before performing the rest of a 
>>> non-throwing function (or closure ) seems like an edge case to me. Perhaps 
>>> I am just biased by my experience. I have not created or used many throwing 
>>> initializers and certainly none in guard statements, and if they were in 
>>> guard statements, the need to handle exceptions differently from any other 
>>> guard failure seems ever more unlikely.
>>> 
>>> I don’t think that the small 

Re: [swift-evolution] [Pitch] Guard/Catch

[Tyler Cloutier via swift-evolution]

> try startHandler(observer) catch {
> observer.sendFailed(error)
> }


Technically the above doesn’t make sense. Please disregard.

> On Oct 7, 2017, at 10:35 PM, Tyler Cloutier  wrote:
> 
> Has there been any progress on this? I came here to propose this but came 
> upon this thread first.
> 
> This proposal goes way beyond sugar. I find myself constantly in the 
> following situation:
> 
> let observer = Observer(with: CircuitBreaker(holding: self))
> do {
> let handlerDisposable = try startHandler(observer)
> } catch {
> observer.sendFailed(error)
> }
> 
> cancelDisposable = ActionDisposable {
> observer.sendInterrupted()
> handlerDisposable?.dispose() // Error handlerDisposable is 
> not defined here
> }
> 
> It’s not as simple as putting it all in the do block because then I’ll be 
> catching errors I might not want to catch! (In this case if the initializer 
> of ActionDisposable was capable of throwing.)
> 
> This is my frustration with every language that has this style of error 
> handling. FWIW, Scala is the only language that I have seen with this style 
> of error handling that solves this problem. The built-in type `Try` combined 
> with pattern matching fixes this issue of over extending the catch area. 
> Which is kinda nifty and also bridges the functional gap as well.
> 
> object Try {
>   /** Constructs a `Try` using the by-name parameter.  This
>   * method will ensure any non-fatal exception is caught and a
> * `Failure` object is returned.
> def apply[T](r: => T): Try[T] =
>   try Success(r) catch {
> case NonFatal(e) => Failure(e)
>   }
> }
> }
> 
> It also would make
> 
> try startHandler(observer) catch {
> observer.sendFailed(error)
> }
> 
> an obvious extension which to me makes sense since it’s just treating the one 
> function call expression as it’s own implicit do block.
> 
> Tyler
> 
> 
> 
>> On Jul 11, 2017, at 10:31 AM, Christopher Kornher via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>> From: Christopher Kornher >
>> Subject: Re: [swift-evolution] [Pitch] Guard/Catch
>> Date: July 10, 2017 at 5:10:15 PM MDT
>> To: Elviro Rocca > >
>> 
>> This messages was modified from the original accidentally sent out 
>> privately, earlier.
>> 
>> FYI this works today in Xcode 9.0 beta 2 playgrounds:
>> 
>> ```
>> class X {
>> init() throws {}
>> 
>> func foo() {
>> print( "Things succeeded" )
>> }
>> }
>> 
>> func bar() throws -> X  { return try X() }
>> 
>> 
>> func f()
>> {
>> guard let x1:X = try? X(), let x2:X = try? bar() else {
>> print( "Things failed ")
>> return
>> }
>> 
>> x1.foo()
>> x2.foo()
>> }
>> 
>> f()// works
>> ```
>> 
>> 
>> Most of the examples of this proposed feature don’t handle the exceptions 
>> other than to perform an early return. 
>> So, without handing exceptions,  the only unhandled case is a non-returning 
>> throwing function or init:
>>  
>> ```
>> class X {
>> init() throws {}
>> 
>> func foo() {
>> print( "Things succeeded" )
>> }
>> }
>> 
>> func bar() throws{ let _ =  try X() }
>> 
>> 
>> func f()
>> {
>> do {
>> try bar()
>> } catch {
>> return
>> }
>> 
>> guard let x:X = try? X() else {
>> print( "Things failed ")
>> return
>> }
>> 
>> x.foo()
>> }
>> 
>> f()// works
>> ```
>> 
>> Having to call a throwing, Void method before performing the rest of a 
>> non-throwing function (or closure ) seems like an edge case to me. Perhaps I 
>> am just biased by my experience. I have not created or used many throwing 
>> initializers and certainly none in guard statements, and if they were in 
>> guard statements, the need to handle exceptions differently from any other 
>> guard failure seems ever more unlikely.
>> 
>> I don’t think that the small rightward drift of exception handling is 
>> onerous. It is hardly like the “pyramid of doom” that ```guard``` was 
>> created to fix.
>> 
>> ```
>> func f( y:Int? = nil )
>> {
>> do {
>> try bar()
>> let x:X = try X()
>> 
>> guard let y = y else {
>> print( "No y")
>> return
>> }
>> 
>> x.foo()
>> print( "y=\(y)")
>> } catch {
>> // Handle some exceptions.
>> return
>> }
>> }
>> ```
>> 
>> On Jul 10, 2017, at 1:45 AM, Elviro Rocca via swift-evolution 
>> > wrote:
>> 
>> This is not a sugar proposal, in the same way as "guard" is not syntactic 
>> sugar, because it requires exiting the scope on the else branch, adding 
>> 

Re: [swift-evolution] [Pitch] Guard/Catch

[Tyler Cloutier via swift-evolution]

Has there been any progress on this? I came here to propose this but came upon 
this thread first.

This proposal goes way beyond sugar. I find myself constantly in the following 
situation:

let observer = Observer(with: CircuitBreaker(holding: self))
do {
let handlerDisposable = try startHandler(observer)
} catch {
observer.sendFailed(error)
}

cancelDisposable = ActionDisposable {
observer.sendInterrupted()
handlerDisposable?.dispose() // Error handlerDisposable is not 
defined here
}

It’s not as simple as putting it all in the do block because then I’ll be 
catching errors I might not want to catch! (In this case if the initializer of 
ActionDisposable was capable of throwing.)

This is my frustration with every language that has this style of error 
handling. FWIW, Scala is the only language that I have seen with this style of 
error handling that solves this problem. The built-in type `Try` combined with 
pattern matching fixes this issue of over extending the catch area. Which is 
kinda nifty and also bridges the functional gap as well.

object Try {
/** Constructs a `Try` using the by-name parameter.  This
* method will ensure any non-fatal exception is caught and a
* `Failure` object is returned.
def apply[T](r: => T): Try[T] =
  try Success(r) catch {
case NonFatal(e) => Failure(e)
  }
}
}

It also would make

try startHandler(observer) catch {
observer.sendFailed(error)
}

an obvious extension which to me makes sense since it’s just treating the one 
function call expression as it’s own implicit do block.

Tyler



> On Jul 11, 2017, at 10:31 AM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> 
> 
> Begin forwarded message:
> 
> From: Christopher Kornher >
> Subject: Re: [swift-evolution] [Pitch] Guard/Catch
> Date: July 10, 2017 at 5:10:15 PM MDT
> To: Elviro Rocca  >
> 
> This messages was modified from the original accidentally sent out privately, 
> earlier.
> 
> FYI this works today in Xcode 9.0 beta 2 playgrounds:
> 
> ```
> class X {
> init() throws {}
> 
> func foo() {
> print( "Things succeeded" )
> }
> }
> 
> func bar() throws -> X  { return try X() }
> 
> 
> func f()
> {
> guard let x1:X = try? X(), let x2:X = try? bar() else {
> print( "Things failed ")
> return
> }
> 
> x1.foo()
> x2.foo()
> }
> 
> f()// works
> ```
> 
> 
> Most of the examples of this proposed feature don’t handle the exceptions 
> other than to perform an early return. 
> So, without handing exceptions,  the only unhandled case is a non-returning 
> throwing function or init:
>  
> ```
> class X {
> init() throws {}
> 
> func foo() {
> print( "Things succeeded" )
> }
> }
> 
> func bar() throws{ let _ =  try X() }
> 
> 
> func f()
> {
> do {
> try bar()
> } catch {
> return
> }
> 
> guard let x:X = try? X() else {
> print( "Things failed ")
> return
> }
> 
> x.foo()
> }
> 
> f()// works
> ```
> 
> Having to call a throwing, Void method before performing the rest of a 
> non-throwing function (or closure ) seems like an edge case to me. Perhaps I 
> am just biased by my experience. I have not created or used many throwing 
> initializers and certainly none in guard statements, and if they were in 
> guard statements, the need to handle exceptions differently from any other 
> guard failure seems ever more unlikely.
> 
> I don’t think that the small rightward drift of exception handling is 
> onerous. It is hardly like the “pyramid of doom” that ```guard``` was created 
> to fix.
> 
> ```
> func f( y:Int? = nil )
> {
> do {
> try bar()
> let x:X = try X()
> 
> guard let y = y else {
> print( "No y")
> return
> }
> 
> x.foo()
> print( "y=\(y)")
> } catch {
> // Handle some exceptions.
> return
> }
> }
> ```
> 
> On Jul 10, 2017, at 1:45 AM, Elviro Rocca via swift-evolution 
> > wrote:
> 
> This is not a sugar proposal, in the same way as "guard" is not syntactic 
> sugar, because it requires exiting the scope on the else branch, adding 
> expressive power and safety to the call: also, the sugary part is pretty 
> important because it avoids nested parentheses and very clearly states that 
> if the guard condition is not fulfilled, the execution will not reach the 
> next lines of code. Guard is useful to push the programmer to at least 
> consider an early return instead of branching code paths, to achieve better 
> clarity, readability and lower complexity, and I suspect is one of the best 
> Swift features 

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

I am very much a fan of this type of thing.

It's very clear that new line are included in the string. Leading white space 
is explicit. It is easy to align. It's easy to copy and paste. And there isn't 
excessive escaping.

> On Apr 3, 2017, at 7:00 AM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> What is the purpose of that backslash?  It does not feel like an improvement. 
> 
> I think we should focus on:
> 
> 1. Looking pretty
> 2. Allow unescaped quote, double quote as well single/double apostrophe 
> characters 
> 3. Allow interpolation 
> 4. No need to add the \n character for each line
> 5. It should have a continuation character
> 6. Keep it simple
> 
> Something like this:
> 
> let xml = M"
>"
>" 
>" \(author)
>" 
>"
> Or maybe this:
> 
> let xml = """
> "
> " 
> " \(author)
> " 
> "
> In the first example the multiline literal is started with M".  In the second 
> example it starts with three double quotes """.  I really have no preference. 
>  In both examples there is no need to have a \ or \n at the end of the line.
> 
> You can have quote characters in the string, including double quotes as shown 
> by empty="".  You can have interpolation, i.e. \(author). 
> 
> You have a continuation character which helps as a visual guide and as a 
> marker for the beginning of each line.
> 
> The multi string literal ends when there are no more continuation characters.
> 
> 
> 
>> On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> on Github there is a PR for this proposal, but I couldn’t find any up to 
>> date thread, so I’m going to start by replying to the last message I found, 
>> without the last content.
>> 
>> I really like where this proposal is going, and my personal preference are 
>> *continuation quotes*. However the proposed solution is still not perfect 
>> enough for me, because it still lacks of precise control about the trailing 
>> space characters in each line of a multi-line string.
>> 
>> Proposed version looks like this:
>> 
>> let xml = "
>> "
>> "
>> "\(author)
>> "XML Developer's Guide
>> "Computer
>> "44.95
>> "2000-10-01
>> "An in-depth look at creating applications with 
>> XML.
>> "
>> "
>> ""
>> I would like to pitch an enhancement to fix the last tiny part by adding the 
>> escaping character ‘' to the end of each line from 1 to (n - 1) of the 
>> n-lined string. This is similar to what Javascript allows us to do, except 
>> that we also have precise control about the leading space character through 
>> ’"’.
>> 
>> The proposed version will become this:
>> 
>> let xml = "\  
>> "\ // If you need you can comment here
>> "\
>> "\(author)\
>> "XML Developer's Guide\
>> "Computer\
>> "44.95\
>> "2000-10-01\
>> "An in-depth look at creating applications with 
>> XML.\
>> "\
>> "\
>> ""
>> Here is another example:
>> 
>> let multilineString: String = "123__456__\ // indicates there is another 
>> part of the string on the next line
>>   "__789_\ // aways starts with `"` and ends 
>> with either `\` or `"`
>>   "_0_" // precise control about pre- and 
>> post-space-characters
>> 
>> let otherString = "\(someInstance)\ /* only comments are allowed in between 
>> */ "text \(someOtherInstance) text"
>> This is simply continuation quotes combined with backslash concatenation.
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

This is probably too late, and I still have to read over the rest of the 
thread, but one possibility would be to just concatenate adjacent string 
literals (where a one sided string literal extends until the end of the line.

E.g. In your example:

let string = "Hello   " // Three trailing space characters
 "Swift
"   4.0" // Three leading space characters print(string)
 // prints:
Hello___Swift
___4.0
 where _ is a space character
My iPad is really fighting me here, but you see what I mean. And unclosed quote 
on a line could simply include the new line character as part of the string. A 
closed quote on a line does not include the new line.



> On Apr 3, 2017, at 2:35 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Simply because it’s always a zero to n space characters at the start of the 
> line and at its end. You cannot predict the need of every multi-line string.
> 
> I don’t disagree that typing out some extra " and \ is tedious, but what I 
> really like about it is, it’s precise.
> 
> let string =  
> "Hello   \ // Three trailing space characters
> "Swift\
> "   4.0"   // Three leading space characters
>  
> print(string) // prints: "Hello___Swift___4.0" where _ ist a space character
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 11:27:58, Charlie Monroe (char...@charliemonroe.net) 
> schrieb:
> 
>> Yes, but with ", you need to escape " occurrences - which is a fairly common 
>> character - I'd say more common than |.
>> 
>> The trailing whitespace - why can't it just be included in the string 
>> automatically? Just for supporting comments?
>> 
>>> On Apr 3, 2017, at 11:19 AM, Adrian Zubarev 
>>>  wrote:
>>> 
>>> This is almost the same as proposed, but we use " instead of |, however you 
>>> still don’t have trailing space characters covered like this.
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net) 
>>> schrieb:
>>> 
 You can. I wish I remembered the language this was in (not sure if it's in 
 Scala), but you can do something like:
 
 let xml = '''
 | 
 | 
 | <...>
 | 
 '''
 
 This way, if you care about the leading whitespace, you define the line 
 beginning using "|".
 
 Two characters aren't harmful, but in my experience when working with HTML 
 strings, etc. the quote-escaping is extremely tedious.
 
> On Apr 3, 2017, at 11:06 AM, Adrian Zubarev 
>  wrote:
> 
> My main concern with this approach is that you don’t have any control 
> about indent and you loose pre- and post spacing characters.
> 
> A concatenating approach is a little tedious but it’s precise. In any 
> situation a multi-lined string is not softly wrapped string, which 
> implies that you will have to press enter for each new line you wish to 
> have. IMHO adding two more characters for each line isn’t that harmful. 
> ;-)
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 10:49:02, Charlie Monroe (char...@charliemonroe.net) 
> schrieb:
> 
>> While I long for multiline string literals, I'd also very like to see a 
>> different syntax as in many cases, these can be XML/HTML snippets and 
>> the use of quotes is ubiqituous. I'd very much like to see a variant 
>> where you can simply paste almost any string without escaping it.
>> 
>> For example, Scala uses a tripple-quote syntax... As we've gotten rid of 
>> ' for character literals, we could use it for multiline strings?
>> 
>> Or possibly tripple-apostrophe for multiline strings?
>> 
>> let xml = '''
>>  
>>  
>> '''
>> 
>> 
>>> On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> on Github there is a PR for this proposal, but I couldn’t find any up 
>>> to date thread, so I’m going to start by replying to the last message I 
>>> found, without the last content.
>>> 
>>> I really like where this proposal is going, and my personal preference 
>>> are *continuation quotes*. However the proposed solution is still not 
>>> perfect enough for me, because it still lacks of precise control about 
>>> the trailing space characters in each line of a multi-line string.
>>> 
>>> Proposed version looks like this:
>>> 
>>> let xml = "
>>> "
>>> "
>>> "\(author)
>>> "XML Developer's Guide
>>> "Computer
>>> "44.95
>>> "2000-10-01
>>> "An in-depth look at creating applications 
>>> with XML.
>>> "
>>> "

Re: [swift-evolution] Move placement of 'throws' statement

[Tyler Cloutier via swift-evolution]

> On Jan 9, 2017, at 1:11 PM, Anton Zhilin  wrote:
> 
> I also thought about sum types as implementation of errors, but selecting 
> between Tyler’s and John’s syntaxes, I would pick the latter. Compare:
> 
> let x: (_ a: Int) -> (Error | (_ b: Float) -> (Error | Double))
> 
> let x: (_ a: Int) throws(Error) -> (_ b: Float) throws(Error) -> Double
> 
> let x: (_ a: Int) -> (Error | Double)
> 
> let x: (_ a: Int) throws(Error) -> Double
> Granted, the version with sum types contains less characters and leads to 
> more minimalistic type system. But | on itself does not mean error handling. 
> It’s used for creation of sum types, without error handling semantics. So 
> it’s easier to grasp the meaning of type containing throws than anything 
> else. If Swift had a special symbol as related to errors, as ? relates to 
> optionals, then we could use it there. Unfortunately, there isn’t anything 
> like that.
> 
> What would it look like if the function returns nothing but can throw an 
> error?
> 
> let x: (_ a: Int) -> (Error | ())


Or even possibly just
let x: (_ a: Int) -> Error
depending on your tastes.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Move placement of 'throws' statement

[Tyler Cloutier via swift-evolution]

> On Jan 9, 2017, at 1:10 AM, Tyler Cloutier  wrote:
> 
>> 
>> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Mon Dec 26 2016, thislooksfun > > wrote:
>> 
>>> Hello Swifters,
>>> 
>>> I've been writing a lot more Swift code recently, and I have found
>>> that the default placement of the 'throws' declaration is often
>>> confusing, especially to those of us switching from languages where
>>> the type of errors thrown is explicitly defined (like Java)
>>> 
>>> For example,
>>> // This is pretty clear, this can throw an error
>>> func foo() throws
>>> { ... }
>>> 
>>> // Also pretty clear, this returns a String
>>> func bar() -> String
>>> { ... }
>>> 
>>> // Confusing. Does this throw a String? Does it return a String? Does it do 
>>> both?
>>> // I personally keep reading this as 'this can throw a String'
>>> func baz() throws -> String
>>> 
>>> // Equivalent code in Java (not a model, just for clarification of why the 
>>> above is confusing)
>>> String baz() throws StringFormatException
>>> I therefore suggest either tweaking the syntax around, or moving, the
>>> `throws` keyword to avoid this confusion.
>>> 
>>> Some ideas I've had:
>>> // Add a comma to separate them
>>> func baz() throws, -> String
>>> 
>>> // Move `throws` to the end
>>> func baz() -> String throws
>> 
>> I agree that reads much better.
> 
> func baz() -> (String | throws)
> func baz() -> (String | throws: BazError)
> let x: (_ a: Int) ->  (throws | (_ b: Float) -> (throws | Double))
> 
> Now where getting somewhere. Somewhere weird, to be sure… but somewhere.


Better yet, just add coproduct or union types, analogous to tuples, and it all 
seems to simplify.

let x: (_ a: Int) -> (Error | (_ b: Float) -> (Error | Double))
let x: (_ a: Int) -> (Error | Double)

No need to toss the try syntax either. It could be complementary.

let y = try! x(5)

let z = try? x(6)

let w = try x(8) catch { case(error: MyError) in

} catch { case(error: Error) in

}

switch x(7) {
case(let e: Error): ...
case(let x: Double): ...
}

if case(let x: Double) = x(9) {

}

Obviously I’m going off on a tangent and I suppose my Scala is showing with 
those case pattern matches. Certainly a lot of directions to go here. One very 
sad thing here is it makes a seemingly ordinary type (Error) have magical 
(catch, try) syntax. This not meant to be taken too seriously, since I’m just 
avoiding going to sleep.


> 
> 
>> 
>>> // Change it to a prefix modifier (like `mutating`)
>>> throwing func baz() -> String
>>> I'm still not sold on any of the above syntaxes, but I would love to hear 
>>> your feedback.
>>> 
>>> This would affect existing code, but it would be a fairly small change
>>> that would result in very large readability improvements, especially
>>> for newcomers, and especially for those coming for a language such as
>>> Java.
>>> 
>>> -thislooksfun (tlf)
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> -- 
>> -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] Move placement of 'throws' statement

[Tyler Cloutier via swift-evolution]

> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Dec 26 2016, thislooksfun  > wrote:
> 
>> Hello Swifters,
>> 
>> I've been writing a lot more Swift code recently, and I have found
>> that the default placement of the 'throws' declaration is often
>> confusing, especially to those of us switching from languages where
>> the type of errors thrown is explicitly defined (like Java)
>> 
>> For example,
>> // This is pretty clear, this can throw an error
>> func foo() throws
>> { ... }
>> 
>> // Also pretty clear, this returns a String
>> func bar() -> String
>> { ... }
>> 
>> // Confusing. Does this throw a String? Does it return a String? Does it do 
>> both?
>> // I personally keep reading this as 'this can throw a String'
>> func baz() throws -> String
>> 
>> // Equivalent code in Java (not a model, just for clarification of why the 
>> above is confusing)
>> String baz() throws StringFormatException
>> I therefore suggest either tweaking the syntax around, or moving, the
>> `throws` keyword to avoid this confusion.
>> 
>> Some ideas I've had:
>> // Add a comma to separate them
>> func baz() throws, -> String
>> 
>> // Move `throws` to the end
>> func baz() -> String throws
> 
> I agree that reads much better.

func baz() -> (String | throws)
func baz() -> (String | throws: BazError)
let x: (_ a: Int) ->  (throws | (_ b: Float) -> (throws | Double))

Now where getting somewhere. Somewhere weird, to be sure… but somewhere.


> 
>> // Change it to a prefix modifier (like `mutating`)
>> throwing func baz() -> String
>> I'm still not sold on any of the above syntaxes, but I would love to hear 
>> your feedback.
>> 
>> This would affect existing code, but it would be a fairly small change
>> that would result in very large readability improvements, especially
>> for newcomers, and especially for those coming for a language such as
>> Java.
>> 
>> -thislooksfun (tlf)
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> -- 
> -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] [Pitch] Eliminate tuples - unify member access syntax

[Tyler Cloutier via swift-evolution]

I’ll tell you it, though, it would be really nice to be able to add functions 
to tuples, just as they are done with structs. 

Perhaps there is a way to formalize tuples as unnamed or anonymous Structs? It 
would make them going away strictly by making them more powerful.



> On Jan 8, 2017, at 12:35 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> The point of this comparison is to point out that the anonymous type 
>> generating tuple is a) superfluous and b) a source of confusion and 
>> gratuitous complexity.  It assumes the role at times of immutable arrays, 
>> anonymous structs, and immutable dictionaries depending on context and we 
>> already have all of those things.  
> 
> There is another anonymous type — and it's very popular right now:
> Closures*.
> They are also a potential source of confusion (and even more complexity ;-), 
> so should they be removed as well?
> 
> I guess we'll keep both, but you are definitely right that there is much 
> complexity… but I'd rather improve that not by removing features, but by 
> adding more regularity:
> There has been a discussion about anonymous enums as well, and if we could 
> come up with a syntax for anonymous reference types, imho everything would 
> feel simpler.
> 
> Most likely someone already mentioned this, but tuples can be used in 
> assignments in a way that isn't possible with any of the alternatives:
> 
> func tupleTest() -> (String, Int) {
>   return ("Foo", 10)
> }
> 
> let (name, count) = tupleTest()
> 
> print("There are \(count) \(name)")
> 
> - Tino
> 
> * so there is yet another (odd) variant:
> 
> var cxy = { (c: Character) -> Int in
>   switch (c) {
>   case "x": return 1
>   case "y": return 2
>   default: fatalError()
>   }
> }
> 
> ___
> 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] Unify "import Darwin/Glibc" to simply "Libc"

[Tyler Cloutier via swift-evolution]

> On Oct 5, 2016, at 10:29 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon  wrote:
>>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution 
>>>  wrote:
>>> I hadn't thought about a unified overlay for POSIX. I think the simplified 
>>> import alone has benefit to warrant its own evolution proposal. Would it be 
>>> possible to have a separate discussion for the POSIX overlay idea? Or is 
>>> there a reason that I'm missing that prevents the import from being viable 
>>> on its own? (Apologies in advance if there's an obvious answer to this 
>>> question!)
>> 
>> I've heard the argument before that we should do a full overlay, but I think 
>> this is becoming a case of the perfect being the enemy of the good. Having 
>> some sort of "just import whatever the system libc is called" module would 
>> be a significant improvement in practice over the state of the art, even if 
>> we don't do any other adaptation.
> 
> I’ve come around to agree with this position.  I think it makes sense to have 
> a cross platform “libc” which is an alias for darwin, glibc, or whatever, and 
> just leave it at that.
> 
> Other proposals for a “POSIX” module have gotten bogged down because 
> inevitably the idea comes up to make the resultant API nicer in various ways: 
> rename creat, handle errno more nicely, make use of multiple return values, … 
> etc.  The problem with this approach is that we don’t *want* people using 
> these layer of APIs, we want higher level Foundation-like APIs to be used.
> 
> That’s why I think the best way to split the difference is to do as you 
> suggest.  This allows the implementation of Foundation (and similar level of 
> APIs) to be nicer, but not get bogged down trying to figure out how to clean 
> up POSIX.
> 
>> Here's what I would suggest. We have a convention for exposing "raw" imports 
>> of C libraries: you call them `C\(libraryName)`. So I would suggest we 
>> introduce a `CLibc` module which provides a raw import of the system's libc. 
>> If we later decide to do a full-featured overlay, that's great—we can call 
>> it `Libc`. But `CLibc` by itself would be an improvement over the status quo 
>> and a step in the right direction.
> 
> I think we should formally decide that a “nice” wrapper for libc is a 
> non-goal.  There is too much that doesn’t make sense to wrap at this level - 
> the only Swift code that should be using this is the implementation of higher 
> level API, and such extremely narrow cases that we can live with them having 
> to handle the problems of dealing with the raw APIs directly.
> 

I don’t know, I kind of take issue with the last point there. I don’t think 
it’s a foregone conclusion that applications and frameworks aren’t going to 
need to be using these APIs. As I understand it’s not the goal of Foundation to 
provide all of the functionality of POSIX. And I know of at least 5 serverside 
and/or networking libraries which each provide their own abstractions over the 
POSIX interface. Unfortunately I think that breed incompatibility that bubbles 
up from underneath. 

For example, each library is going to have to redefine their own concepts of a 
“SystemError” for example (a la this 
 and 
this 

 and this 
,
 etc). If I want to use two of these libraries now I’ve got conflicting 
versions of “SystemError”s. What I’m saying is that realistically as system 
error is a system error and having six different ways to wrap it is not only 
unfortunate for the library developers, but confusing for the users of the 
library.

I certainly hear the argument that these should be wrapped in higher level 
concepts (even perhaps system errors, although there’s only so much wrapping to 
be done here), but I think we should do some more investigation into whether 
the cases are actually that narrow. I just want to avoid 10 slightly different 
thin wrappers around POSIX which are confusing to users of libraries. And each 
of these wrappers have the same potential for subtle POSIX errors.

Perhaps the way to do it is to make more targeted which are auxiliary to 
Foundation, like “Networking” or “IO” or “Files” (even though there is overlap 
here, e.g. system errors as above). The intention here would be not to 
rearchitect POSIX, but to define base levels of functionality reduce or 
eliminate the need to make POSIX calls. Or perhaps just widen the reach of 
Foundation to provide that base functionality.

For example, would a TCPSocket class belong in Foundation? It’s already got 
HTTPCookies.

Tyler


> -Chris
> 
> 
> ___
> swift-evolution 

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Tyler Cloutier via swift-evolution]

There is also a similar intent for Zewo’s POSIX:

https://github.com/Zewo/POSIX/blob/master/Sources/POSIX

It would be great to have something included with Swift.


> On Sep 14, 2016, at 5:59 AM, Alex Blewitt via swift-evolution 
>  wrote:
> 
> Vapor's Core package expresses a target called simply 'libc':
> 
> https://github.com/vapor/core/blob/master/Sources/libc/libc.swift 
> 
> 
> As a result, their Swift files simply say "import libc"
> 
> https://github.com/vapor/core/blob/master/Sources/Core/Lock.swift 
> 
> 
> Alex
> 
>> On 13 Sep 2016, at 20:29, Brian Gesiak via swift-evolution 
>> > wrote:
>> 
>> Resurrecting this discussion since the question of "why does Android import 
>> Glibc?" came up on this swift-corelibs-foundation pull request: 
>> https://github.com/apple/swift-corelibs-foundation/pull/622#discussion_r77848100
>>  
>> 
>> 
>> I think that it is also important to ask what the real goal here is.  
>> Foundation is our cross platform compatibility layer, are there specific 
>> deficiencies in the Foundation API that cause a problem here, or is it just 
>> that not all of corelibs Foundation is “done” yet?
>> 
>> When I first proposed the idea, I simply wanted to turn these five lines:
>> 
>> #if os(Linux) || os(FreeBSD) || os(Android) || os(PS4)
>> import Glibc
>> #else
>> import Darwin
>> #endif
>> 
>> Into this one line:
>> 
>> import WhateverNameWeDecideUpon
>> 
>> After all, writing five lines of code for the import is painful, and the 
>> list of `#if os(...) || os(...) || ...` is always expanding.
>> 
>> I hadn't thought about a unified overlay for POSIX. I think the simplified 
>> import alone has benefit to warrant its own evolution proposal. Would it be 
>> possible to have a separate discussion for the POSIX overlay idea? Or is 
>> there a reason that I'm missing that prevents the import from being viable 
>> on its own? (Apologies in advance if there's an obvious answer to this 
>> question!)
>> 
>> - Brian Gesiak
>> 
>> ___
>> 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 SE-0009 Reconsideration

[Tyler Cloutier via swift-evolution]

As another colorblind developer, I have trouble paying attention to the syntax 
highlighting. I didn’t even notice that member variables were colored until 
someone mentioned it on this list.


> On May 23, 2016, at 9:43 AM, Jeff Kelley via swift-evolution 
>  wrote:
> 
> As a colorblind developer, this isn’t really an issue. The vast majority of 
> colorblind people can discern colors. As long as the IDE allows you to 
> customize which colors it displays, you can find a palette that will work 
> with your eyes (for my type of colorblindness, for instance, I have 
> difficulty differentiating blue and purple, so I wouldn’t use both in my 
> syntax highlighting color scheme). As long as color isn’t the only thing 
> differentiating on-screen elements, adding colors to syntax highlighting is 
> beneficial even to us colorblind developers. :)
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com  | @SlaunchaMan 
>  | jeffkelley.org 
> 
> Check out Developing for Apple Watch, Second Edition 
> ,
>  now in print!
> 
>> On May 23, 2016, at 12:24 PM, Krystof Vasa via swift-evolution 
>> > wrote:
>> 
>>> The problem can also be easily mitigated by having the IDE use a different 
>>> color to display a variable based on where it was defined (eclipse come to 
>>> mind as an example). This is something the brain naturally notices without 
>>> paying any conscious attention.
>> 
>> Tell that to the colorblind :)
>> 
>>> 
 -- E
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 5:56 PM, Chris Lattner  wrote:
> 
> 
>> On May 10, 2016, at 4:13 PM, Cole Campbell via swift-evolution 
>>  wrote:
>> 
>> I agree that repeat { } is ambiguous because you have to look to the end for 
>> a while clause to determine if it's infinite or not.
> 
> Right, this is the downside that I see with “repeat {}”.


Not to beat a dead horse, but isn’t this also true of 

repeat {

} while true

and 

while true {
   ...
   ...
   if condition {
break
   }
}

> 
>> while true { } is preferable in that regard, but a compromise that I saw 
>> mentioned is:
>> 
>> repeat forever { }
> 
> This would require taking “forever” as a keyword if we supported “repeat N 
> {", something we wouldn’t want to do.
> 
> Another option is to make it a statement modifier, which wouldn’t require 
> taking it as a keyword (but also doesn’t read as well):
> 
> forever repeat { }
> 
> 
> Personally, I don’t see this as a big enough improvement over “while true” to 
> be worth introducing complexity for. 
> 

If you are referring to “forever", I also don’t think that adding a new keyword 
is an improvement over “while true”.

> -Chris

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

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

[Tyler Cloutier via swift-evolution]

What would repeat 1 { } mean then? Repeat N? Would it run N or N + 1 times? 

That sounds a massive source of bugs.


> On May 10, 2016, at 5:25 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> FWIW, repeat once means do twice.
> On Tue, May 10, 2016 at 19:16 Tyler Cloutier <cloutierty...@aol.com 
> <mailto:cloutierty...@aol.com>> wrote:
>> On May 10, 2016, at 4:07 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Tue, May 10, 2016 at 6:02 PM, Tyler Cloutier <cloutierty...@aol.com 
>> <mailto:cloutierty...@aol.com>> wrote:
>> 
>>> On May 10, 2016, at 3:59 PM, Xiaodi Wu <xiaodi...@gmail.com 
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> On Tue, May 10, 2016 at 5:56 PM, Tyler Cloutier <cloutierty...@aol.com 
>>> <mailto:cloutierty...@aol.com>> wrote:
>>> 
>>>> On May 10, 2016, at 3:13 PM, Xiaodi Wu <xiaodi...@gmail.com 
>>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>> 
>>>> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> I’d actually say that I’m strongly in favor of allowing just a repeat 
>>>> keyword, although I wouldn’t support making 'while true’.
>>>> 
>>>> Firstly it reduces clutter
>>>> 
>>>> Can you explain what clutter you see? Unless I misunderstand what you're 
>>>> referring to, reducing the 10 letters in `while true` to the six letters 
>>>> in `repeat` is hardly "reducing clutter."
>>>>  
>>>> and makes it very clear that the the code is just supposed to repeat.
>>>> 
>>>> I disagree here also. It is not very clear at all that the code is 
>>>> supposed to repeat indefinitely, not to any audience.
>>>> 
>>>> First, it would not be clear to users who are experienced in Swift and 
>>>> aware of this proposal. Code is meant to be read, and allowing the 
>>>> omission of a trailing clause to produce two very different behaviors 
>>>> means that it is not clear what `repeat {` means until you encounter the 
>>>> closing brace and check for what follows. Moreover, what follows could be 
>>>> the keyword `while` on the following line, and in that case you cannot 
>>>> know whether the expression that follows `while` is the beginning of a new 
>>>> while loop until you encounter or don't encounter a new opening brace. By 
>>>> contrast, `while true {` cannot be anything other than the beginning of an 
>>>> infinite loop. You already know that fact after reading 12 letters.
>>>> 
>>>> Second, it would not be clear to users migrating from another C-family 
>>>> language. `while true { }` is immediately understood by users of any other 
>>>> related language.
>>>> 
>>>> Third, it would not be clear based on a knowledge of English. In common 
>>>> use, "repeat" does not mean repeat forever; it means to repeat once (i.e. 
>>>> do something twice). If I ask you to repeat something you just said, I 
>>>> should hope that you do not keep reciting it over and over until I tell 
>>>> you to stop.
>>>>  
>>>> 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.
>>>> 
>>>> I can speak to this a little bit, having introduced a new programmer to 
>>>> loops very recently and having done so in the past as well. I have not 
>>>> encountered anyone who has trouble with the *concept* of looping--i.e. the 
>>>> idea that the same code can be run over and over.
>>>> 
>>>> Where things get tricky is the difficulty of mastering the syntax of the 
>>>> while loop and, more problematic, the syntax of the classic for;; loop. 
>>>> Introducing a simple way to make something repeat forever does not solve 
>>>> this learning hurdle, because students will continue to have to contend 
>>>> with these other types of loops in order to be productive in the language. 
>>>> A special syntax for repeating forever is especially unhelpful because it 
>>>> is just functional enough that a discouraged student may choose to avoid 
>>>> learning other 

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 4:07 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> 
> 
> On Tue, May 10, 2016 at 6:02 PM, Tyler Cloutier <cloutierty...@aol.com 
> <mailto:cloutierty...@aol.com>> wrote:
> 
>> On May 10, 2016, at 3:59 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Tue, May 10, 2016 at 5:56 PM, Tyler Cloutier <cloutierty...@aol.com 
>> <mailto:cloutierty...@aol.com>> wrote:
>> 
>>> On May 10, 2016, at 3:13 PM, Xiaodi Wu <xiaodi...@gmail.com 
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> I’d actually say that I’m strongly in favor of allowing just a repeat 
>>> keyword, although I wouldn’t support making 'while true’.
>>> 
>>> Firstly it reduces clutter
>>> 
>>> Can you explain what clutter you see? Unless I misunderstand what you're 
>>> referring to, reducing the 10 letters in `while true` to the six letters in 
>>> `repeat` is hardly "reducing clutter."
>>>  
>>> and makes it very clear that the the code is just supposed to repeat.
>>> 
>>> I disagree here also. It is not very clear at all that the code is supposed 
>>> to repeat indefinitely, not to any audience.
>>> 
>>> First, it would not be clear to users who are experienced in Swift and 
>>> aware of this proposal. Code is meant to be read, and allowing the omission 
>>> of a trailing clause to produce two very different behaviors means that it 
>>> is not clear what `repeat {` means until you encounter the closing brace 
>>> and check for what follows. Moreover, what follows could be the keyword 
>>> `while` on the following line, and in that case you cannot know whether the 
>>> expression that follows `while` is the beginning of a new while loop until 
>>> you encounter or don't encounter a new opening brace. By contrast, `while 
>>> true {` cannot be anything other than the beginning of an infinite loop. 
>>> You already know that fact after reading 12 letters.
>>> 
>>> Second, it would not be clear to users migrating from another C-family 
>>> language. `while true { }` is immediately understood by users of any other 
>>> related language.
>>> 
>>> Third, it would not be clear based on a knowledge of English. In common 
>>> use, "repeat" does not mean repeat forever; it means to repeat once (i.e. 
>>> do something twice). If I ask you to repeat something you just said, I 
>>> should hope that you do not keep reciting it over and over until I tell you 
>>> to stop.
>>>  
>>> 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.
>>> 
>>> I can speak to this a little bit, having introduced a new programmer to 
>>> loops very recently and having done so in the past as well. I have not 
>>> encountered anyone who has trouble with the *concept* of looping--i.e. the 
>>> idea that the same code can be run over and over.
>>> 
>>> Where things get tricky is the difficulty of mastering the syntax of the 
>>> while loop and, more problematic, the syntax of the classic for;; loop. 
>>> Introducing a simple way to make something repeat forever does not solve 
>>> this learning hurdle, because students will continue to have to contend 
>>> with these other types of loops in order to be productive in the language. 
>>> A special syntax for repeating forever is especially unhelpful because it 
>>> is just functional enough that a discouraged student may choose to avoid 
>>> learning other types of loops and instead combine the infinite loop with 
>>> if, continue, and break.
>> 
>> I’d also like to point out Chris’ comments on the 
>> 
>> repeat X {
>> 
>> }
>> 
>> discussion.
>> 
>> “
>> This is a very valid use case.
>> 
>> FWIW, “repeat N {}” was originally designed and scoped into the Swift 2 
>> implementation of the feature, but was cut due to schedule limitations.  
>> There is precedent for this sort of feature in many teaching oriented 
>> languages (e.g. Logo).
>> 
>> I’d say that the pro’s and con’s of this are:
>> 
>> + Makes a simple case

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 3:59 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Tue, May 10, 2016 at 5:56 PM, Tyler Cloutier <cloutierty...@aol.com 
> <mailto:cloutierty...@aol.com>> wrote:
> 
>> On May 10, 2016, at 3:13 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> I’d actually say that I’m strongly in favor of allowing just a repeat 
>> keyword, although I wouldn’t support making 'while true’.
>> 
>> Firstly it reduces clutter
>> 
>> Can you explain what clutter you see? Unless I misunderstand what you're 
>> referring to, reducing the 10 letters in `while true` to the six letters in 
>> `repeat` is hardly "reducing clutter."
>>  
>> and makes it very clear that the the code is just supposed to repeat.
>> 
>> I disagree here also. It is not very clear at all that the code is supposed 
>> to repeat indefinitely, not to any audience.
>> 
>> First, it would not be clear to users who are experienced in Swift and aware 
>> of this proposal. Code is meant to be read, and allowing the omission of a 
>> trailing clause to produce two very different behaviors means that it is not 
>> clear what `repeat {` means until you encounter the closing brace and check 
>> for what follows. Moreover, what follows could be the keyword `while` on the 
>> following line, and in that case you cannot know whether the expression that 
>> follows `while` is the beginning of a new while loop until you encounter or 
>> don't encounter a new opening brace. By contrast, `while true {` cannot be 
>> anything other than the beginning of an infinite loop. You already know that 
>> fact after reading 12 letters.
>> 
>> Second, it would not be clear to users migrating from another C-family 
>> language. `while true { }` is immediately understood by users of any other 
>> related language.
>> 
>> Third, it would not be clear based on a knowledge of English. In common use, 
>> "repeat" does not mean repeat forever; it means to repeat once (i.e. do 
>> something twice). If I ask you to repeat something you just said, I should 
>> hope that you do not keep reciting it over and over until I tell you to stop.
>>  
>> 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.
>> 
>> I can speak to this a little bit, having introduced a new programmer to 
>> loops very recently and having done so in the past as well. I have not 
>> encountered anyone who has trouble with the *concept* of looping--i.e. the 
>> idea that the same code can be run over and over.
>> 
>> Where things get tricky is the difficulty of mastering the syntax of the 
>> while loop and, more problematic, the syntax of the classic for;; loop. 
>> Introducing a simple way to make something repeat forever does not solve 
>> this learning hurdle, because students will continue to have to contend with 
>> these other types of loops in order to be productive in the language. A 
>> special syntax for repeating forever is especially unhelpful because it is 
>> just functional enough that a discouraged student may choose to avoid 
>> learning other types of loops and instead combine the infinite loop with if, 
>> continue, and break.
> 
> I’d also like to point out Chris’ comments on the 
> 
> repeat X {
> 
> }
> 
> discussion.
> 
> “
> This is a very valid use case.
> 
> FWIW, “repeat N {}” was originally designed and scoped into the Swift 2 
> implementation of the feature, but was cut due to schedule limitations.  
> There is precedent for this sort of feature in many teaching oriented 
> languages (e.g. Logo).
> 
> I’d say that the pro’s and con’s of this are:
> 
> + Makes a simple case very simple, particularly important in teaching.
> + Even if you aren’t familiar with it, you can tell at first glance what the 
> behavior is.
> - It is “just syntactic sugar”, which makes the language more complex.
> - It is a very narrow feature that is useful in few practical situations.
> 
> -Chris
> “
> 
> In this case, I would say it’s not making the language any more complex given 
> that repeat-while is a current construct. Admittedly it is a very narrow 
> feature, but it’s also a small one.
> 
> For the reasons I outlined above, I'd be +1 for `repeat N` and -1 for this 
> c

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 3:56 PM, Tyler Cloutier via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> 
>> On May 10, 2016, at 3:13 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> I’d actually say that I’m strongly in favor of allowing just a repeat 
>> keyword, although I wouldn’t support making 'while true’.
>> 
>> Firstly it reduces clutter
>> 
>> Can you explain what clutter you see? Unless I misunderstand what you're 
>> referring to, reducing the 10 letters in `while true` to the six letters in 
>> `repeat` is hardly "reducing clutter."
>>  
>> and makes it very clear that the the code is just supposed to repeat.
>> 
>> I disagree here also. It is not very clear at all that the code is supposed 
>> to repeat indefinitely, not to any audience.
>> 
>> First, it would not be clear to users who are experienced in Swift and aware 
>> of this proposal. Code is meant to be read, and allowing the omission of a 
>> trailing clause to produce two very different behaviors means that it is not 
>> clear what `repeat {` means until you encounter the closing brace and check 
>> for what follows. Moreover, what follows could be the keyword `while` on the 
>> following line, and in that case you cannot know whether the expression that 
>> follows `while` is the beginning of a new while loop until you encounter or 
>> don't encounter a new opening brace. By contrast, `while true {` cannot be 
>> anything other than the beginning of an infinite loop. You already know that 
>> fact after reading 12 letters.
>> 
>> Second, it would not be clear to users migrating from another C-family 
>> language. `while true { }` is immediately understood by users of any other 
>> related language.
>> 
>> Third, it would not be clear based on a knowledge of English. In common use, 
>> "repeat" does not mean repeat forever; it means to repeat once (i.e. do 
>> something twice). If I ask you to repeat something you just said, I should 
>> hope that you do not keep reciting it over and over until I tell you to stop.
>>  
>> 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.
>> 
>> I can speak to this a little bit, having introduced a new programmer to 
>> loops very recently and having done so in the past as well. I have not 
>> encountered anyone who has trouble with the *concept* of looping--i.e. the 
>> idea that the same code can be run over and over.
>> 
>> Where things get tricky is the difficulty of mastering the syntax of the 
>> while loop and, more problematic, the syntax of the classic for;; loop. 
>> Introducing a simple way to make something repeat forever does not solve 
>> this learning hurdle, because students will continue to have to contend with 
>> these other types of loops in order to be productive in the language. A 
>> special syntax for repeating forever is especially unhelpful because it is 
>> just functional enough that a discouraged student may choose to avoid 
>> learning other types of loops and instead combine the infinite loop with if, 
>> continue, and break.
> 
> I’d also like to point out Chris’ comments on the 
> 
> repeat X {
> 
> }
> 
> discussion.
> 
> “
> This is a very valid use case.
> 
> FWIW, “repeat N {}” was originally designed and scoped into the Swift 2 
> implementation of the feature, but was cut due to schedule limitations.  
> There is precedent for this sort of feature in many teaching oriented 
> languages (e.g. Logo).
> 
> I’d say that the pro’s and con’s of this are:
> 
> + Makes a simple case very simple, particularly important in teaching.
> + Even if you aren’t familiar with it, you can tell at first glance what the 
> behavior is.
> - It is “just syntactic sugar”, which makes the language more complex.
> - It is a very narrow feature that is useful in few practical situations.
> 
> -Chris
> “
> 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001234.html

> In this case, I would say it’s not making the language any more complex given 
> that repeat-while is a current construct. Admittedly it is a very narrow 
> feature, but it’s also a small one.
> 
>>  
>> Lastly, this isn’t the first time this has been brought up on this list an

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 3:13 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> I’d actually say that I’m strongly in favor of allowing just a repeat 
> keyword, although I wouldn’t support making 'while true’.
> 
> Firstly it reduces clutter
> 
> Can you explain what clutter you see? Unless I misunderstand what you're 
> referring to, reducing the 10 letters in `while true` to the six letters in 
> `repeat` is hardly "reducing clutter."
>  
> and makes it very clear that the the code is just supposed to repeat.
> 
> I disagree here also. It is not very clear at all that the code is supposed 
> to repeat indefinitely, not to any audience.
> 
> First, it would not be clear to users who are experienced in Swift and aware 
> of this proposal. Code is meant to be read, and allowing the omission of a 
> trailing clause to produce two very different behaviors means that it is not 
> clear what `repeat {` means until you encounter the closing brace and check 
> for what follows. Moreover, what follows could be the keyword `while` on the 
> following line, and in that case you cannot know whether the expression that 
> follows `while` is the beginning of a new while loop until you encounter or 
> don't encounter a new opening brace. By contrast, `while true {` cannot be 
> anything other than the beginning of an infinite loop. You already know that 
> fact after reading 12 letters.
> 
> Second, it would not be clear to users migrating from another C-family 
> language. `while true { }` is immediately understood by users of any other 
> related language.
> 
> Third, it would not be clear based on a knowledge of English. In common use, 
> "repeat" does not mean repeat forever; it means to repeat once (i.e. do 
> something twice). If I ask you to repeat something you just said, I should 
> hope that you do not keep reciting it over and over until I tell you to stop.
>  
> 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.
> 
> I can speak to this a little bit, having introduced a new programmer to loops 
> very recently and having done so in the past as well. I have not encountered 
> anyone who has trouble with the *concept* of looping--i.e. the idea that the 
> same code can be run over and over.
> 
> Where things get tricky is the difficulty of mastering the syntax of the 
> while loop and, more problematic, the syntax of the classic for;; loop. 
> Introducing a simple way to make something repeat forever does not solve this 
> learning hurdle, because students will continue to have to contend with these 
> other types of loops in order to be productive in the language. A special 
> syntax for repeating forever is especially unhelpful because it is just 
> functional enough that a discouraged student may choose to avoid learning 
> other types of loops and instead combine the infinite loop with if, continue, 
> and break.

I’d also like to point out Chris’ comments on the 

repeat X {

}

discussion.

“
This is a very valid use case.

FWIW, “repeat N {}” was originally designed and scoped into the Swift 2 
implementation of the feature, but was cut due to schedule limitations.  There 
is precedent for this sort of feature in many teaching oriented languages (e.g. 
Logo).

I’d say that the pro’s and con’s of this are:

+ Makes a simple case very simple, particularly important in teaching.
+ Even if you aren’t familiar with it, you can tell at first glance what the 
behavior is.
- It is “just syntactic sugar”, which makes the language more complex.
- It is a very narrow feature that is useful in few practical situations.

-Chris
“

In this case, I would say it’s not making the language any more complex given 
that repeat-while is a current construct. Admittedly it is a very narrow 
feature, but it’s also a small one.

>  
> Lastly, this isn’t the first time this has been brought up on this list and 
> there was previously discussion about the fact that when people see the 
> repeat keyword that it should naturally repeat indefinitely unless a where 
> clause is specified.
> 
> I do believe that this is the first time this suggestion has been introduced 
> to the list. I do not recall any previous discussion focused on infinite 
> loops; they have been about repeating a finite number of times, using 
> proposed syntax such as `repeat 3 times { }` or variations on that theme.
>  
> I also think the concern that an accidental infinite loop is any greater than 
> it is currently.
> 
> Code gets refactored and e

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 3:13 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> I’d actually say that I’m strongly in favor of allowing just a repeat 
> keyword, although I wouldn’t support making 'while true’.
> 
> Firstly it reduces clutter
> 
> Can you explain what clutter you see? Unless I misunderstand what you're 
> referring to, reducing the 10 letters in `while true` to the six letters in 
> `repeat` is hardly "reducing clutter.”

I’m just referring to 'repeat {} while true’ -> 'repeat {}' 

>  
> and makes it very clear that the the code is just supposed to repeat.
> 
> I disagree here also. It is not very clear at all that the code is supposed 
> to repeat indefinitely, not to any audience.
> 
> First, it would not be clear to users who are experienced in Swift and aware 
> of this proposal. Code is meant to be read, and allowing the omission of a 
> trailing clause to produce two very different behaviors means that it is not 
> clear what `repeat {` means until you encounter the closing brace and check 
> for what follows.

This is just as true of all types of loops. If I have 

repeat {
...
} while ...

I still have to scroll down to check the condition.

If I have 

while true {
...
}

I still have to scan the entire body for different ways of exiting the loop. 

> Moreover, what follows could be the keyword `while` on the following line, 
> and in that case you cannot know whether the expression that follows `while` 
> is the beginning of a new while loop until you encounter or don't encounter a 
> new opening brace.

This is true, but it’s not ambiguous and any reasonable style would make it 
clear what the intension is. However, this does sound difficult for the 
compiler to parse, I will admit. This whole thing might be a moot point if 
can’t be integrated into the grammar. I don’t think I’m qualified to comment on 
the implications there.

> By contrast, `while true {` cannot be anything other than the beginning of an 
> infinite loop. You already know that fact after reading 12 letters.
> 

As I’ve said above, this is not true. I can break out of the loop at any time.

> Second, it would not be clear to users migrating from another C-family 
> language. `while true { }` is immediately understood by users of any other 
> related language.

repeat as a keyword is already unfamiliar to users from other C-family 
languages. If they can grok the repeat-while loop, they can definitely 
understand repeat immediately.

> 
> Third, it would not be clear based on a knowledge of English. In common use, 
> "repeat" does not mean repeat forever; it means to repeat once (i.e. do 
> something twice). If I ask you to repeat something you just said, I should 
> hope that you do not keep reciting it over and over until I tell you to stop.
>  
> 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.
> 
> I can speak to this a little bit, having introduced a new programmer to loops 
> very recently and having done so in the past as well. I have not encountered 
> anyone who has trouble with the *concept* of looping--i.e. the idea that the 
> same code can be run over and over.
> 
> Where things get tricky is the difficulty of mastering the syntax of the 
> while loop and, more problematic, the syntax of the classic for;; loop. 
> Introducing a simple way to make something repeat forever does not solve this 
> learning hurdle, because students will continue to have to contend with these 
> other types of loops in order to be productive in the language.

You’re saying that we should not have a simple syntax because they will 
eventually have to understand more complex syntax? Or am I misunderstanding?

> A special syntax for repeating forever is especially unhelpful because it is 
> just functional enough that a discouraged student may choose to avoid 
> learning other types of loops and instead combine the infinite loop with if, 
> continue, and break.
>  
> Lastly, this isn’t the first time this has been brought up on this list and 
> there was previously discussion about the fact that when people see the 
> repeat keyword that it should naturally repeat indefinitely unless a where 
> clause is specified.
> 
> I do believe that this is the first time this suggestion has been introduced 
> to the list. I do not recall any previous discussion focused on infinite 
> loops; they have been about repeating a finite number of times, using 
> proposed syntax such as `repeat 3 times { }` or variations on that theme.

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 2:50 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> 
> 
> On Tue, May 10, 2016 at 4:46 PM, Tyler Cloutier <cloutierty...@aol.com 
> <mailto:cloutierty...@aol.com>> wrote:
> 
>> On May 10, 2016, at 2:34 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> I think, on the contrary, it's missing the point utterly. It's up to those 
>> proposing a new feature to justify its addition in light of what's already 
>> here, and it's up to those proposing the removal of a feature to justify why 
>> it should be removed.
>> 
>> Certainly no one is proposing the removal of the while loop. Currently, the 
>> One Obvious Way of making an infinite loop is `while true`, and it is up to 
>> the proponents to advance a reason why a replacement would be superior. I 
>> cannot think of a greater non-sequitur than supplying a demonstration of why 
>> while loops are useful.
> 
> That’s what I am saying. No one is supplying a demonstration of why while 
> loops are useful and that suggestion is a straw man.
> 
> That was not meant to be a straw man, not on my part. It is my understanding 
> of Harlan's example. It shows that, without while loops, it is unwieldy to 
> express the same thing using goto statements. That is fine, but it is not at 
> all on point for this discussion.
>  
> My point below that simple and clear syntax is an improvement on syntax with 
> more noise.
> 
> repeat {
>   // code
> }
> 
> vs
> 
> repeat {
>   // code
> } while true
> 
> What's wrong with `while true { }` ? 

This is a good question. In my opinion, nothing in and of itself, however since 
repeat is part of the language and it has a stand alone meaning in english, it 
stands to reason that users will expect that it can stand alone just as do { } 
does. I would love to hear if this is a sentiment I alone have, or if others 
feel the same.

> 
> The reason that the former is superior to the latter is that, given repeat is 
> already part of the language, the former it is simpler, with less noise. It 
> reads like simple english. It also aligns well with current do {} syntax. 
> This is the only argument I’m offering, and I think it’s the only one that 
> could be offered for such a small syntax change given that it *only* serves 
> to clarify and reduce noise of current syntax which has the same 
> functionality.
> 
> 
>> On Tue, May 10, 2016 at 16:27 Tyler Cloutier via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On May 10, 2016, at 2:13 PM, Harlan Haskins via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> You could always do your control flow with goto’s anyway…
>>> 
>>> func foo() {
>>>   var i = 0
>>>   func goto(_ label: String = "entry") {
>>> switch label {
>>> case "entry":
>>>   print("beginning loop…")
>>>   goto("cond")
>>> case "cond":
>>>   goto(i < 10 ? "body" : "end")
>>> case "body":
>>>   i += 1
>>>   print("\(i)")
>>>   goto("cond")
>>> case "end":
>>>   break
>>> default: break
>>> }
>>>   }
>>>   goto()
>>> }
>>> 
>>> Apologies,
>>> Harlan
>> 
>> 
>> And isn’t this the point really. Yes there are many different ways of doing 
>> something, but there should be one obvious way. IMHO, there is nothing more 
>> obvious than just 
>> 
>> repeat {
>> 
>> }
>> 
>> It’s very clear. It’s not about adding complex control flow, it’s about 
>> simplifying current syntax. I don’t think anyone is arguing that it’s more 
>> powerful than what while loops currently offer.
>> 
>> 
>>> 
>>>> On May 10, 2016, at 2:05 PM, Taras Zakharko via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> 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 drawb

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 2:34 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> I think, on the contrary, it's missing the point utterly. It's up to those 
> proposing a new feature to justify its addition in light of what's already 
> here, and it's up to those proposing the removal of a feature to justify why 
> it should be removed.
> 
> Certainly no one is proposing the removal of the while loop. Currently, the 
> One Obvious Way of making an infinite loop is `while true`, and it is up to 
> the proponents to advance a reason why a replacement would be superior. I 
> cannot think of a greater non-sequitur than supplying a demonstration of why 
> while loops are useful.

That’s what I am saying. No one is supplying a demonstration of why while loops 
are useful and that suggestion is a straw man. My point below that simple and 
clear syntax is an improvement on syntax with more noise.

repeat {
// code
}

vs

repeat {
// code
} while true

The reason that the former is superior to the latter is that, given repeat is 
already part of the language, the former it is simpler, with less noise. It 
reads like simple english. It also aligns well with current do {} syntax. This 
is the only argument I’m offering, and I think it’s the only one that could be 
offered for such a small syntax change given that it *only* serves to clarify 
and reduce noise of current syntax which has the same functionality.


> On Tue, May 10, 2016 at 16:27 Tyler Cloutier via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On May 10, 2016, at 2:13 PM, Harlan Haskins via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> You could always do your control flow with goto’s anyway…
>> 
>> func foo() {
>>   var i = 0
>>   func goto(_ label: String = "entry") {
>> switch label {
>> case "entry":
>>   print("beginning loop…")
>>   goto("cond")
>> case "cond":
>>   goto(i < 10 ? "body" : "end")
>> case "body":
>>   i += 1
>>   print("\(i)")
>>   goto("cond")
>> case "end":
>>   break
>> default: break
>> }
>>   }
>>   goto()
>> }
>> 
>> Apologies,
>> Harlan
> 
> 
> And isn’t this the point really. Yes there are many different ways of doing 
> something, but there should be one obvious way. IMHO, there is nothing more 
> obvious than just 
> 
> repeat {
> 
> }
> 
> It’s very clear. It’s not about adding complex control flow, it’s about 
> simplifying current syntax. I don’t think anyone is arguing that it’s more 
> powerful than what while loops currently offer.
> 
> 
>> 
>>> On May 10, 2016, at 2:05 PM, Taras Zakharko via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 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 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> 
>>>>>> On May 10, 2016, at 3:30 PM, Tyler Cloutier via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 :)
>>>> 
>>>> 

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

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 1:34 PM, Sean Heber <s...@fifthace.com> wrote:
> 
>> On May 10, 2016, at 3:30 PM, Tyler Cloutier via swift-evolution 
>> <swift-evolution@swift.org> 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?

That is a fair point, but it’s probably a good way of illustrating other ways 
of exiting a loop, without having the complication of a while condition.

> 
> l8r
> Sean
> 

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

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

[Tyler Cloutier via swift-evolution]

I’d actually say that I’m strongly in favor of allowing just a repeat keyword, 
although I wouldn’t support making 'while true’.

Firstly it reduces clutter and makes it very clear that the the code is just 
supposed to repeat. 
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.
Lastly, this isn’t the first time this has been brought up on this list and 
there was previously discussion about the fact that when people see the repeat 
keyword that it should naturally repeat indefinitely unless a where clause is 
specified.

I also think the concern that an accidental infinite loop is any greater than 
it is currently.

Tyler



> On May 10, 2016, at 1:09 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> I do not see sufficiently measurable benefits to this proposal to add it to 
> the language. 
> It's easy enough to roll your own `repeatForever` function with trailing 
> closure.
> 
> I also want to thank you for bring it up on-list. Not every idea is right for 
> Swift but it's
> always refreshing to see innovative thoughts added to the discussion. Please 
> do not be 
> discouraged by the generally negative feedback on this particular idea.
> 
> -- Erica
> 
>> On May 10, 2016, at 1:27 AM, Nicholas Maccharoli via swift-evolution 
>> > wrote:
>> 
>> ​Swift Evolution ​Community,
>> 
>> Currently writing an infinite loop in swift looks either something like this:
>> 
>> while true {
>> if ... { break }
>> //...
>> }
>> 
>> Or this:
>> 
>> repeat {
>> if ... { break }
>> //...
>> } while true
>> 
>> But I think it might be best to change the syntax / behaviour of `repeat` to 
>> loop 
>> indefinitely if no trailing while clause is present:
>> 
>> repeat {
>> if ... { break }
>> //...
>> }
>> 
>> while still allowing a trailing `while` clause as in:
>> 
>> repeat { 
>> foo += bar
>> } while foo.count < limit 
>> 
>> I also want to propose that it should be a compile time error to use single 
>> `Bool` constants as while loop conditions, so no more `while true { ... }` 
>> it would become `repeat { ... }`
>> 
>> I was thinking of drafting a short proposal if there was enough positive 
>> feedback. 
>> 
>> How does it sound?
>> 
>> - Nick 
>> ___
>> 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] Change `repeat` to loop indefinitely if no while clause is present

[Tyler Cloutier via swift-evolution]

Furthermore, I also think it is a nice generalization of the 

do {

} 

syntax for scopes. I think it is quite intuitive that do executes a block once, 
and repeat executes it repeatedly.


> On May 10, 2016, at 1:09 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> I do not see sufficiently measurable benefits to this proposal to add it to 
> the language. 
> It's easy enough to roll your own `repeatForever` function with trailing 
> closure.
> 
> I also want to thank you for bring it up on-list. Not every idea is right for 
> Swift but it's
> always refreshing to see innovative thoughts added to the discussion. Please 
> do not be 
> discouraged by the generally negative feedback on this particular idea.
> 
> -- Erica
> 
>> On May 10, 2016, at 1:27 AM, Nicholas Maccharoli via swift-evolution 
>> > wrote:
>> 
>> ​Swift Evolution ​Community,
>> 
>> Currently writing an infinite loop in swift looks either something like this:
>> 
>> while true {
>> if ... { break }
>> //...
>> }
>> 
>> Or this:
>> 
>> repeat {
>> if ... { break }
>> //...
>> } while true
>> 
>> But I think it might be best to change the syntax / behaviour of `repeat` to 
>> loop 
>> indefinitely if no trailing while clause is present:
>> 
>> repeat {
>> if ... { break }
>> //...
>> }
>> 
>> while still allowing a trailing `while` clause as in:
>> 
>> repeat { 
>> foo += bar
>> } while foo.count < limit 
>> 
>> I also want to propose that it should be a compile time error to use single 
>> `Bool` constants as while loop conditions, so no more `while true { ... }` 
>> it would become `repeat { ... }`
>> 
>> I was thinking of drafting a short proposal if there was enough positive 
>> feedback. 
>> 
>> How does it sound?
>> 
>> - Nick 
>> ___
>> 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] Change `repeat` to loop indefinitely if no while clause is present

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 1:10 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Agreed. I'm not convinced that this actually prevents any more errors than it 
> might cause (forgot to finish writing my "repeat" block, and now my app is 
> unresponsive), and I don't think there's enough of an expressivity win to add 
> another keyword.

Certainly it’s not adding a new keyword, however it is changing the meaning of 
a keyword.

> 
> Austin
> 
> On Tue, May 10, 2016 at 1:04 PM, Haravikk via swift-evolution 
> > wrote:
> 
>> On 10 May 2016, at 08:27, Nicholas Maccharoli via swift-evolution 
>> > wrote:
>> 
>> But I think it might be best to change the syntax / behaviour of `repeat` to 
>> loop 
>> indefinitely if no trailing while clause is present:
>> 
>> repeat {
>> if ... { break }
>> //...
>> }
> 
> -1 from me on both counts; the thing I like about while true is that it’s 
> explicit about what I meant, whereas a repeat block with no while clause is 
> indistinguishable from me forgetting to include one, or me wanting an 
> infinite loop.
> 
> An alternative could be to add a new “forever” keyword or something similar, 
> replacing while true wherever applicable, but personally I don’t think it’s 
> that important.
> 
> ___
> 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] Change `repeat` to loop indefinitely if no while clause is present

[Tyler Cloutier via swift-evolution]

Oh you are right, I totally missed that, thanks.

> On May 10, 2016, at 12:10 PM, Xiaodi Wu  wrote:
> 
> Nicholas wrote that he would like `while true` to be a compile-time error. 
> I'm curious as to why.
> 
> On Tue, May 10, 2016 at 13:47 Tyler Cloutier  wrote:
>>> On May 10, 2016, at 12:39 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Tue, May 10, 2016 at 2:27 AM, Nicholas Maccharoli via swift-evolution 
  wrote:
 Swift Evolution Community,
 
 Currently writing an infinite loop in swift looks either something like 
 this:
 
 while true {
 if ... { break }
 //...
 }
 
 Or this:
 
 repeat {
 if ... { break }
 //...
 } while true
 
 But I think it might be best to change the syntax / behaviour of `repeat` 
 to loop 
 indefinitely if no trailing while clause is present:
 
 repeat {
 if ... { break }
 //...
 }
 
 while still allowing a trailing `while` clause as in:
 
 repeat { 
 foo += bar
 } while foo.count < limit 
>>>  
>>> What is your motivation for this change?
>>>  
 I also want to propose that it should be a compile time error to use 
 single `Bool` constants as while loop conditions, so no more `while true { 
 ... }` it would become `repeat { ... }`
>>> 
>>> What problems are solved by forbidding `while true`?
>> 
>> I don’t think the proposal is forbidding it, but rather making it optional. 
>> So that 
>> 
>> repeat {
>> 
>> } 
>> 
>> is equivalent to 
>> 
>> repeat {
>> 
>> } while true
>> 
>>>  
 I was thinking of drafting a short proposal if there was enough positive 
 feedback. 
 
 How does it sound?
 
 - Nick 
 
 ___
 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] Change `repeat` to loop indefinitely if no while clause is present

[Tyler Cloutier via swift-evolution]

> On May 10, 2016, at 12:39 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Tue, May 10, 2016 at 2:27 AM, Nicholas Maccharoli via swift-evolution 
> > wrote:
> ​Swift Evolution ​Community,
> 
> Currently writing an infinite loop in swift looks either something like this:
> 
> while true {
> if ... { break }
> //...
> }
> 
> Or this:
> 
> repeat {
> if ... { break }
> //...
> } while true
> 
> But I think it might be best to change the syntax / behaviour of `repeat` to 
> loop 
> indefinitely if no trailing while clause is present:
> 
> repeat {
> if ... { break }
> //...
> }
> 
> while still allowing a trailing `while` clause as in:
> 
> repeat { 
> foo += bar
> } while foo.count < limit 
>  
> What is your motivation for this change?
>  
> I also want to propose that it should be a compile time error to use single 
> `Bool` constants as while loop conditions, so no more `while true { ... }` it 
> would become `repeat { ... }`
> 
> What problems are solved by forbidding `while true`?

I don’t think the proposal is forbidding it, but rather making it optional. So 
that 

repeat {

} 

is equivalent to 

repeat {

} while true

>  
> I was thinking of drafting a short proposal if there was enough positive 
> feedback. 
> 
> How does it sound?
> 
> - Nick 
> 
> ___
> 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] multi-line string literals.

[Tyler Cloutier via swift-evolution]

> On May 5, 2016, at 10:52 PM, Brent Royal-Gordon  
> wrote:
> 
>> As far as mixed whitespace, I think the only sane thing to do would be to 
>> only allow leading tabs *or* spaces.  Mixing tabs and spaces in the leading 
>> whitespace would be a syntax error.  All lines in the string would need to 
>> use tabs or all lines use spaces, you could not have one line with tabs and 
>> another with spaces.  This would keep the compiler out of the business of 
>> making any assumptions or guesses, would not be a problem often, and would 
>> be very easy to fix if it ever happens accidentally.
> 
> The sane thing to do would be to require every line be prefixed with 
> *exactly* the same sequence of characters as the closing delimiter line. 
> Anything else (except perhaps a completely blank line, to permit whitespace 
> trimming) would be a syntax error.
> 

Yes, this I think would be the way to do it.

> But take a moment to consider the downsides before you leap to adopt this 
> solution.
> 
> 1. You have introduced tab-space confusion into the equation.

Agreed, and that’s never fun since they are invisible. Confusing for people new 
to programming, I imagine.

> 
> 2. You have introduced trailing-newline confusion into the equation.

Yes, you are absolutely right and I missed this one in my response. I assume 
you are referring to whether or not there is a new line after , and 
if so how do you get rid of it without messing up the whitespace trimming.

Is this not also a problem for heredocs (if you want to use the closing 
delimiter to mark how much whitespace to trim)?

> 
> 3. The #escaped and #marginStripped keywords are now specific to multiline 
> strings; #escaped in particular will be attractive there for tasks like 
> regexes. You will have to invent a different syntax for it there.

These were just straw man proposals, I don’t think that is what they 
should/would be. Just throwing the general idea out there.

> 
> 4. This form of `"""` is not useful for not having to escape `"` in a 
> single-line string; you now have to invent a separate mechanism for that.

True, unless you don’t mind taking up 3 lines to do it.

> 
> 5. You can't necessarily look at a line and tell whether it's code or string. 
> And—especially with the #escaped-style constructs—the delimiters don't 
> necessarily "pop" visually; they're too small and easy to miss compared to 
> the text they contain. In extremis, you actually have to look at the entire 
> file from top to bottom, counting the `"""`s to figure out whether you're in 
> a string or not. Granted, you *usually* can tell from context, but it's a far 
> cry from what continuation quotes offer.

To be fair, syntax highlighting also helps with this, but it’s quite possible 
you are looking at the code in a context where it is not available.

I don’t see how the #compilerDirective modifiers make the delimiters any less 
visible, though 

And, the same could be said for heredoc delimiters, I think. Although, that 
really depends on what the delimiters are.

> 
> 6. You are now forcing *any* string literal of more than one line to include 
> two extra lines devoted wholly to the quoting syntax. In my Swift-generating 
> example, that would change shorter snippets like this:
> 
> code +=  "
>  "static var messages: [HTTPStatus: String] = [
>  ""
> 
> Into things like this:
> 
> code +=  """
>  
>  static var messages: [HTTPStatus: String] = [
> 
>  """
> 
> To my mind, the second syntax is actually *heavier*, despite not requiring 
> every line be marked, because it takes two extra lines and additional 
> punctuation.

> 
> 7. You are also introducing visual ambiguity into the equation—in the above 
> example, the left margin is now ambiguous to the eye (even if it's not 
> ambiguous to the compiler). You could recover it by permitting non-whitespace 
> prefix characters:
> 
> code +=  """
> |
> |static var messages: [HTTPStatus: String] = [
> |
> |"""
> 
> ...but then we're back to annotating every line, *plus* we have the leading 
> and trailing `"""` lines. Worst of both worlds.
> 

This is a good point. It takes up 5 lines, and you quite possibly will still 
have to go about counting spaces. It would be worse for the more whitespace you 
have.


> 8. In longer examples, you are dividing the expression in half in a way that 
> makes it difficult to read. For instance, consider this code:
> 
> socket.send( 
> """ #escaped #marginStripped 
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
>

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

> On May 5, 2016, at 6:27 PM, Tyler Cloutier via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On 5 May 2016, at 14:17, David Hart <da...@hartbit.com 
>>> <mailto:da...@hartbit.com>> wrote:
>>> 
>>> 
>>>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>>>> doesn't change this and it's unlikely that any future draft will, because 
>>>> for me, the problem are the continuation quotes, and for Brent it seems 
>>>> like they are a must-have-feature (correct me if I'm wrong.)
>>> 
>>> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
>>> proposal simply because of the existence of continuation quotes, no matter 
>>> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
>>> and unfriendly to modification.
>>> 
>>> I could see either your proposal, or your proposal without the HERE_DOCs 
>>> but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
>>> formal proposal?
>> 
>> 
>> Adapting the original proposal if you’re not a fan of continuation quotes..
>> 
>> It’s possible to have a multiline “””python””” multi-line string but tidily 
>> indented.
>> As suggested earlier in this thread the lexer can strip the margin on the 
>> basis of
>> the whitespace before the closing quote as per Perl6 (This could be a 
>> modifier “I”
>> but might as well be the default TBH.) Would this be the best of both worlds?
>> 
>> assert( xml == i"""
>> 
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
>> 
>> Other modifiers can also be applied such as “no-escapes"
>> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> """ )
>> 
>> I’d hope this would satisfy any need for <> 
>> Or you could support both continuation and indented python style:
>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz 
>> <http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz>
>> 
>> John
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I’m of the opinion that either of these are reasonable solutions, and both 
> offer different tradeoffs. I’m probably partial to the continuation quotes, 
> because I don’t want to be guessing about what is going to end up being in my 
> string and what won’t.  
> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
> 
> For example, is there a new line after ?
> How would the indenting work if it were immediately followed by triple 
> quotes: ”””
> I would really like the first line to be lined up with the rest of the xml. 
> Is that going to introduce a newline into the top of the string?
> 
> Could we just enforce that no characters on the lines of the triple quotes 
> would be included in the string, very much like the heredoc syntax?
> 
> assert( xml != ei"”” The text I’m

Re: [swift-evolution] [Idea] Remove optional pattern binding

[Tyler Cloutier via swift-evolution]

> On May 2, 2016, at 1:08 PM, David Waite via swift-evolution 
>  wrote:
> 
>> The reason is simple: most developers don’t grok pattern matching.  
>> Particularly for people new to swift, “if let” is taught as a magic for 
>> dealing with optionals (which it is). This is a very useful mechanic when 
>> working in Swift, and this way of thinking is fine.  Optionals are very 
>> prominent, and having special sugar for dealing with them is important, even 
>> as people grow to become swift experts in time.
>> 
>> Going with the proposal would definitely simplify the language ('if case’ 
>> could probably go away), but would force everyone, all the time, to think 
>> about pattern matching.  This would be a barrier to entry that many 
>> programmers should never have to face.  The fact that many people don’t 
>> think about things in terms of pattern matching is the root cause for the 
>> comments about “it seems weird that the question mark is on the LHS of the 
>> assignment”.
>> 
>> Finally, some may argue that making pattern matching more prominent would 
>> help teach pattern matching and get more people to use it.  That may be 
>> true, but our goal here is to build a pragmatic language that helps people 
>> get things done, not push to one specific language feature.  I personally 
>> love pattern matching (and was the one who drove and implemented the Swift 2 
>> pattern matching enhancements), but it is an esoteric and special case 
>> feature.  It makes sense for it to be “buried” under “if case”: those who 
>> are unfamiliar with the syntax have something they can google for.
>> 
> My issue is that while one needs to have a special behavior in this case to 
> combine conditional logic and variable assignment, the current shorthand is 
> nonintuitive/inconsistent. The current syntax makes it look like you are 
> saying “let y=x”, and that now assignment has different behaviors if you are 
> inside or outside a conditional. Why does assignment sometime cast off 
> optionality?
> 
> let x:Optional = 1 // x: Int? = 1
> 
> if let y = x { 
>  print(y.dynamicType) // Int
> } 
> let y = x
> print(y.dynamicType) // Optional
> 
> If there were a syntax like “if let y = some x”, then it would be clear that 
> there is more to this statement than an assignment, it would make it clearer 
> why you can’t cast off optionality on other assignments, as well as possibly 
> being a segue to learning about full pattern matching.
> 
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


This to me is the most bizarre thing about the if-let construct. Elsewhere in 
the language ? indicates conditional unwrapping.

This would make more sense to me:

if let y = x? { 
 print(y.dynamicType) // Int
} 

My issue with the proposed pattern matching syntax is that it looks like 
assignment, which I think confuses people. This is one thing that the current 
case syntax helps to mitigate.

if let y? = x { 
 print(y.dynamicType) // Int
}

Not that I’m suggesting this exactly, but the for-loop syntax works well. Maybe 
there is a more clear pattern matching syntax?

if let y? in x { 
 print(y.dynamicType) // Int
}___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

[Tyler Cloutier via swift-evolution]

> On Apr 23, 2016, at 1:27 AM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> I'd like to second James Campbell's suggestion of a `mutate` keyword. 
> Clarifying comments inline below:
> 
>> On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> This is not a new idea.  Something almost identical to this has been
>> explored and discussed quite thoroughly already:
>> > >.
>> In fact, it was implmented and later reverted because it raised
>> language-design questions for which we had no good answers.
> 
> I don't know if the following are particularly good answers, but I'll try 
> anyway:
> 
>> I don't believe the choice of glyph (& vs =) affects any of the
>> fundamental issues:
>> 
>> * Should the x.=f() syntax be required for *every* mutating method
>>  invocation?
> 
> Allow me to ask it differently: Should some specific syntax be required for 
> every mutating method? — Yes.
> 
> Should the syntax be `x.=f()`? — Not necessarily. I kinda like James 
> Campbell's idea of a `mutate` keyword. Consider the following:
> 
> var numbers = [5, 12, 6, 2]
> mutate numbers.append(10)
> mutate numbers.sort()
> if let biggest = mutate numbers.popLast() {
> print("The biggest number was:", biggest)
> }
> 
> So `mutate` would work much like `try` but—unlike `try` which can move 
> further to the left—`mutate` would have to always prefix the mutating 
> receiver. Here's a contrived example of a corner case:
> 
> enum Error : ErrorType { case BadNumber }
> 
> func demo() throws -> Int {
> 
> }
> 
>> * Are assignment methods a redundant way to spell mutating methods?
>>  Should we really have both mechanisms?
> 
> (I had to look up the definition of an assignment method. For the 
> uninitiated, Dave is talking about what's written here: 
> https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst#use-one-simple-name
>  
> .)
> 
> — Yes they are redundant, and no, we should not have both.
> 
> With `mutate` required at the call site, we could simply allow both overloads 
> `func sort()` and `mutating func sort()` to coexist, because the call sites 
> become unambiguous:
> 
> let originals = [2, 1, 3, 0, 4, 2]
> var copies = originals
> 
> originals.sort()   // warning: result of call to 'sort()' is 
> unused
> mutate originals.sort()// compiler error
> let xs = originals.sort()  // ok
> 
> copies.sort() // warning: result of call to 'sort()' is 
> unused
> mutate copies.sort()  // ok
> let ys = copies.sort()// ok
> let zs = mutate copies.sort() // warning: constant 'x' inferred to have 
> type '()', which may be unexpected
> 
> The language could also allow the use of
> 
> mutate x.next()
> 
> as shorthand for
> 
> x = x.next()
> 
> when only the non-mutating variant `func next() -> Self` exists with 
> compatible return type.
> 
>> * Can we really introduce this feature without having a way to apply it
>>  to class types?
> 
> Yes we can. Why complicate the naming of value type members with the 
> complexities of reference semantics? The current API naming conventions are 
> good for reference types which sometimes come with unobvious to obscure 
> behaviour (i.e. anything from bumping an internal counter to firing missiles 
> and wiping hard drives).
> 
> But value types ought to have no side effects (besides memory allocation and 
> logging maybe), and so we don't necessarily need that strong a naming 
> convention to limit their collateral damage.
> 
> If the `mutate` keyword became required for calling `mutating` methods, then 
> operators would remain the only place where naming convention were needed to 
> distinguish mutation:
> 
> Mutating assignment is explicit: `xs = [1, 2] + xs + [2, 1]` (i.e. `=` 
> without `let` or `var` means mutation)
> Mutating method call becomes explicit: `mutate xs.sort()` and `let x = mutate 
> xs.removeAtIndex(2)`
> Mutating function arguments are explicit with the `&` prefix: `swap(, )`
> Mutating operators are implicit and by convention, should end with the `=` 
> symbol: `xs += [8, 9]`
> Reference types have no notion of `mutating` members (and probably ought to 
> remain that way) so they mutate implicitly.
> 
>> I should also point out that under the assignment method paradigm one
>> would probably need to re-evalutate rules for naming.  Under the current
>> API guidelines' approach, we'd write:
>> 
>>x.=sorted()  // sort x in-place
>> 
>> and I am not sure how easy that would be for people to swallow
>> considering how much more straightforward
>> 
>>x.sort() // 

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

[Tyler Cloutier via swift-evolution]

That being said I try to follow most of the discussions on swift-evolution and 
there does seem to be a great deal of hand wringing regarding this and things 
related to or affected by this.

> On Apr 22, 2016, at 12:00 AM, Tyler Cloutier via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> If I recall correctly there was a thread with a similar idea which instead 
> would create a new operator for mutation or a new way of method invocation, 
> such that mutating methods would be called with &. or something similar. e.g.
> 
> foo&.add(5)
> 
> I think the consensus was that that was not a particularly familiar syntax 
> and it would add a decent amount of noise.
> 
> There may have also been some issues with the grammar, I can't recall.
> 
>> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hey
>> 
>> I think adding “&” to methods will reduce the readability of the code. Also, 
>> keyword “mutating” makes it super clear and readable that my method is 
>> mutating the values.
>> 
>> 1. mutating func add(value: Double){…}
>> 
>> 2. func add&(value: Double){…}
>> 
>> I think it’s easy to skip the information encoded into the 2nd function 
>> which is this function is mutating a value as compared to 1st. When I read 
>> 1st function I start reading with keyword “mutating” making its intentions 
>> clear to me.
>> 
>> Also, it might become a symbol nightmare with following type signature of a 
>> function-
>> 
>> func nightmare&(title: String?) -> String? -> String?{…}
>> 
>> I can see the advantage of using “&” when calling a function. It makes clear 
>> at the call site that this method is mutating but still I don’t find 
>> eliminating “mutating” a good step for the reasons mentioned above.
>> 
>> Maybe we can think of some better solution.
>> 
>> Thanks
>> 
>> -Krishna
>> 
>>> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> swift-evolution@swift.org
>> 
>> ___
>> 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] mutating/non-mutating suggestion from a Rubyist

[Tyler Cloutier via swift-evolution]

If I recall correctly there was a thread with a similar idea which instead 
would create a new operator for mutation or a new way of method invocation, 
such that mutating methods would be called with &. or something similar. e.g.

foo&.add(5)

I think the consensus was that that was not a particularly familiar syntax and 
it would add a decent amount of noise.

There may have also been some issues with the grammar, I can't recall.

> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution 
>  wrote:
> 
> Hey
> 
> I think adding “&” to methods will reduce the readability of the code. Also, 
> keyword “mutating” makes it super clear and readable that my method is 
> mutating the values.
> 
> 1. mutating func add(value: Double){…}
> 
> 2. func add&(value: Double){…}
> 
> I think it’s easy to skip the information encoded into the 2nd function which 
> is this function is mutating a value as compared to 1st. When I read 1st 
> function I start reading with keyword “mutating” making its intentions clear 
> to me.
> 
> Also, it might become a symbol nightmare with following type signature of a 
> function-
> 
> func nightmare&(title: String?) -> String? -> String?{…}
> 
> I can see the advantage of using “&” when calling a function. It makes clear 
> at the call site that this method is mutating but still I don’t find 
> eliminating “mutating” a good step for the reasons mentioned above.
> 
> Maybe we can think of some better solution.
> 
> Thanks
> 
> -Krishna
> 
>> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution 
>>  wrote:
>> 
>> swift-evolution@swift.org
> 
> ___
> 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-0065 A New Model for Collections and Indices

[Tyler Cloutier via swift-evolution]

I won’t do a full review because I don’t think I have spent enough time reading 
through the discussion, but just reading the proposal I’d say I’m an huge 
proponent of this change. Irrespective of the performance benefits, I think 
it’s a massive win for an easily understandable mental model.

Tyler


> On Apr 10, 2016, at 2:41 PM, 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] [Idea] Add forced conversion for Error catching pattern matching

[Tyler Cloutier via swift-evolution]

> 
> On Mar 21, 2016, at 6:01 AM, Haravikk  wrote:
> 
> I’m a ±1; for the way things are I’m a +1, but I think I’d still prefer to 
> have typed errors that the compiler can use to check for an exhaustive list, 
> as it would be easy for a forced conversion to result in unexpected runtime 
> errors later if you ever need to add a new error type to your .applyAction() 
> method, since doing so wouldn’t result in any warnings/errors at compile time.
> 

That is true, but I think that is the intended behavior. Consider the case 
where applyAction is a method which is to be overridden in by a subclass. If 
the subclass needs to throw a different type of error, it cannot because the 
it’s not declared super classes method definition. I ran into this problem the 
other day in Java. The solution was to throw a runtime exception and in Java it 
seems that there is a tendency to drift towards more and more runtime 
exceptions for exactly these types of reasons. The problem with runtime 
exceptions is that there’s no way to know if they are thrown by a method at 
it’s call site.

At least with the as! operator, people familiar with Swift will immediately 
recognize that as a potentially app crashing operation.

> I agree about catch _ and default; either default should be allowed for 
> do/catch, or be removed from switches, to promote consistency, but that’s a 
> separate issue I think.
> 
>> On 20 Mar 2016, at 20:26, Tyler Fleming Cloutier via swift-evolution 
>> > wrote:
>> 
>> I recall that there was quite a bit of discussion a while back about adding 
>> typed error declarations for methods that throw for the purpose of 
>> exhaustive pattern matching on errors.
>> 
>> There were interesting arguments on either side, and I think that the result 
>> was to maintain the status quo. There’s still the issue of having to add the 
>> extra catch statement to every do block for exhaustive matches.
>> 
>> Would it be wise to allow force conversion for the cases in which the 
>> developer believes the match is exhaustive? ie
>> 
>> do {
>> let action = chooseAction(game)
>> game = try game.applyAction(action)
>> } catch let e as ActionError {
>> game.failedAction = e
>> } catch _ {
>> fatalError(“This is an unfortunate bit of noise :/")
>> }
>> 
>> becomes
>> 
>> do {
>> let action = chooseAction(game)
>> game = try game.applyAction(action)
>> } catch let e as! ActionError {
>> game.failedAction = e
>> }
>> 
>> 
>> Also as a brief aside, it’s not super intuitive to me that the syntax for 
>> the catch pattern matching wildcard is 
>> 
>> catch _
>> 
>> whereas it is
>> 
>> default
>>  
>> for switches. I think I saw Chris mention somewhere that default was chosen 
>> because of it’s wide familiarity. Does anyone recall the reason?
>> 
>> Thanks,
>> 
>> Tyler
>> ___
>> 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 syntactic sugar for iterating over an Optional

[Tyler Cloutier via swift-evolution]

The syntax could be
for x in array? {

}

It wouldn't necessarily be consistent with 

if let foo = foo {

}

But as I've mentioned in another thread regarding the if let syntax and 
variable shadowing, it would probably make more sense to new users if the if 
let syntax was the following.

if let foo = foo? {

}

The ? is always used to conditionally unwrap optionals. It strikes me as odd 
that they are not used to unwrap them in control flow statements. 

i.e. Why should 

array?.forEach

be any different than,

for x in array?


Tyler

> On Dec 20, 2015, at 12:15 PM, Marco Masser via swift-evolution 
>  wrote:
> 
> I have to admit that Radek’s comment about “for … in? …” meaning an iteration 
> over a SequenceType containing Optional Values is valid.
> 
> But I think “for? … in …” is worse because it separates the “?” from the 
> thing that is the Optional thing. Consider:
> 
> for? x in array { … }
> 
> vs.
> 
> for x in? array { … }
> 
> If any of these two is about iterating over an Optional, it’s 
> the second one – at least to me. The first one reads much more like the “x” 
> could be optional.
> 
> Marco
> 
> 
>> On 2015-12-18, at 22:24, Radosław Pietruszewski via swift-evolution 
>>  wrote:
>> 
>> That’s… definitely an improvement as far as ambiguity is concerned, but I 
>> still don’t believe it passes the usefulness threshold, and I don’t really 
>> like the precedent of having a `for?`…
>> 
>> PS. FWIW, I like the spirit of the proposal, just not this solution. I’m all 
>> for “expressivity enhancements” — little things that helps me write cleaner 
>> code and express my intention better. But this doesn’t seem worth the 
>> trouble of extending the language.
>> 
>> — Radek
>> 
>>> On 18 Dec 2015, at 22:20, Jacob Bandes-Storch  wrote:
>>> 
>>> How about `for? object in array` instead?
>>> 
>>> On Fri, Dec 18, 2015 at 1:13 PM, Paul Cantrell via swift-evolution 
>>>  wrote:
> `for object in? array` … suggests that there’s something optional about 
> checking for inclusion, not about the array itself. It could easily be 
> interpreted as “iterate for all non-nil elements of array (where array: 
> [T?])” — a use case arguably more common than this.
 
 
 That’s a really good point.
 
 P
 
 
> On Dec 18, 2015, at 3:06 PM, Radosław Pietruszewski  
> wrote:
> 
> Personally, I’m -1 for the proposal. I see this as a solution to a very 
> minor, fairly rare, and not generalizable problem.
> 
> Perhaps more importantly: the syntax is confusing to my eyes. `for object 
> in? array` doesn’t immediately convey its semantics to me. It suggests 
> that there’s something optional about checking for inclusion, not about 
> the array itself. It could easily be interpreted as “iterate for all 
> non-nil elements of array (where array: [T?])” — a use case arguably more 
> common than this.
> 
> In the vast majority of cases, arrays shouldn’t be optional in the first 
> place. It’s rare that there’s a semantic difference between “empty array” 
> and “no array”.
> 
>> Sure, in that example it’s quite simple. It’s not the “?? []” syntax 
>> itself, which is perfectly clear; it’s having that dangling off the end 
>> of some longer expression. In real-world context, it does become 
>> additional noise.
> 
> That is a good point, albeit one that’s more broad than that — I dislike 
> how `as?` often forces me to add additional parentheses — and not strong 
> enough to warrant an introduction of a new `in?` construct IMHO.
> 
> — Radek
> 
>>> On 18 Dec 2015, at 21:56, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Dec 17, 2015, at 4:08 AM, Jeremy Pereira 
  wrote:
 
 
 On 16 Dec 2015, at 19:52, Paul Cantrell via swift-evolution 
  wrote:
 
 I do this a lot:
 
for object in array ?? [] {
 
 …and it does impair readability a bit at times.
>>> 
>>> Does it? It seems fairly understandable to me even though I have never 
>>> seen it before.
>> 
>> Sure, in that example it’s quite simple. It’s not the “?? []” syntax 
>> itself, which is perfectly clear; it’s having that dangling off the end 
>> of some longer expression. In real-world context, it does become 
>> additional noise.
>> 
>>> I think there is a good reason for keeping this construct a bit 
>>> “clunky”. Generally APIs give you a nil array for one of two reasons:
>>> 
>>> - there was some sort of error in retrieving the elements
>>> - there were no qualifying elements found.
>> 
>> You’re forgetting the third case, the 

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Tyler Cloutier via swift-evolution]

I've always thought that, 

if let foo = foo? {

}

makes more sense than 

if let foo = foo {

}

as the ? indicates that you are unwrapping the optional and then assigning it 
to the new variable

> On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution 
>  wrote:
> 
> I’ve only read the last couple of posts but has anybody already suggested 
> using something like this:
> 
> if let foo! {
>   // code that uses foo
> }
> 
> People already know that the ! is unwrapping a value and that let is defining 
> a new constant. So why not combine those two?
> Alternatively it could also be:
> 
> if let foo? {
>   // code that uses foo
> }
> 
> What do you think?
> 
> – Cihat
> 
>>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
>>> :
>>> 
>>> 
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
>>>  wrote:
>>> 
>>> I was going to suggest something similar (a hard naming problem also):
>>> 
>>> if has foo {
>>> // foo is now unwrapped and non-optional
>>> }
>>> 
>>> guard has foo else { return }
>>> 
>>> Does the same thing as `let foo = foo` in practice, but places it in a 
>>> somewhat different mental model. Instead of unwrapping and immediately 
>>> assigning to a new constant with the same name (which just looks kind of 
>>> silly, like some magic voodoo ritual), it sort of asserts that we “have” 
>>> foo (i.e. it’s not nil), and therefore from that point it can just be 
>>> treated as non-optional.
>>> 
>>> IMHO this, although introduces a new keyword, makes more sense than trying 
>>> to reuse “let” in a context where it seems nonsensical. Perhaps this would 
>>> be closer to Swift’s goals, by reducing very common boilerplate, but 
>>> without harming clarity in a way adding a new meaning to “let” would.
>>> 
>>> Curious to hear Chris Lattner’s opinion :-) 
>> 
>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable 
>> with the idea that a single declared property might have different static 
>> types in different regions of code.
>> 
>>> 
>>> — Radek
>>> 
 On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
  wrote:
 
 What if we made the keyword "unwrap"? 
 
 if unwrap someViewController {
 // now there is a shadowing nonoptional (unwrapped) variable of the same 
 name only within this scope, boiling down to simple syntactic sugar for 
 optional binding and it is fairly clear. 
 } 
 
 
> On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution 
>  wrote:
> As much fun as it to example with foo, I would argue the opposite when 
> you use some real world variable names:
> 
> if let someInterestingViewConroller = someInterestingViewConroller {
> }
> 
> vs
> 
> If let someInterestingViewConroller {
> }
> 
> We know what let does and it should be enough to impart the necessary 
> information for this statement.
> 
> When it comes to newcomers I think you'd be hard pressed to find somebody 
> who'd be able to understand either form without teaching; so not losing 
> much there.
> 
> 
>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>>>  wrote:
>>> 
>>> I’ve had similar ideas to this. Instead of ditching the if let syntax 
>>> altogether, another approach would be to use the existing name if no 
>>> new name is given, so that this code:
>>> 
>>> if let foo = foo { /* use foo */ }
>>> 
>>> could become this code:
>>> 
>>> if let foo { /* use foo */ }
>>> 
>>> In both cases, foo is non-optional inside the braces. If you gave it 
>>> another name with the if let syntax, that would work as it does today.
>> 
>> Hi Jeff,
>> 
>> This is commonly requested - the problem is that while it does help 
>> reduce boilerplate, it runs counter to the goal of improving clarity.
>> 
>> -Chris
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
  ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>>  ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>>