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

[Russ Bishop via swift-evolution]

> On Jan 11, 2017, at 10:35 AM, Erica Sadun  wrote:
> 
>> 
>> On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 I thought there is already a pending proposal on typed throws?
>>> 
>>> There was, I vaguely recall that it was by Russ?  I don’t see any open PRs 
>>> for it.
>> 
>> Hey now, there is no need for name calling ;)
>> 
>> 
>>> 
>>> I’m personally a big fan of typed throws, but I know that John McCall has 
>>> strong concerns.  I can’t argue that typed throws is a high priority at the 
>>> moment, but as soon as we start talking about concurrency the topic of a 
>>> Result type will come back up (for use with futures/async).
>> 
>> I fall firmly in John McCall’s camp on this one. If someone wants to read 
>> that part of the thread: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html
>>  
>> 
>> 
>> Of course if we want to automatically convert a throws function into an 
>> awaitable Result then that naturally begs the question of either Result’s 
>> error is typed as Error or not. I think I fall into the “as Error” camp here 
>> too because Swift’s switch is powerful enough to pattern match on the type 
>> fairly nicely but I haven’t thought about it very much.
>> 
>> 
>> All that said… if Swift got a macro system Rust’s error-chain seems to have 
>> some interesting ideas that avoid a lot of boilerplate.
> 
> If Swift has a canonical built-in system for reporting an Error, why wouldn't 
> it be used here? Why use casting?
> 
> — E

I was using shorthand for “struct Result { let error: Error? }” vs “struct 
Result { let error: E? }”… as in I prefer not having a second 
generic type parameter to denote the error.

Russ



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

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

[Erica Sadun via swift-evolution]

> On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution 
>  wrote:
> 
> 
>> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> I thought there is already a pending proposal on typed throws?
>> 
>> There was, I vaguely recall that it was by Russ?  I don’t see any open PRs 
>> for it.
> 
> Hey now, there is no need for name calling ;)
> 
> 
>> 
>> I’m personally a big fan of typed throws, but I know that John McCall has 
>> strong concerns.  I can’t argue that typed throws is a high priority at the 
>> moment, but as soon as we start talking about concurrency the topic of a 
>> Result type will come back up (for use with futures/async).
> 
> I fall firmly in John McCall’s camp on this one. If someone wants to read 
> that part of the thread: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html
>  
> 
> 
> Of course if we want to automatically convert a throws function into an 
> awaitable Result then that naturally begs the question of either Result’s 
> error is typed as Error or not. I think I fall into the “as Error” camp here 
> too because Swift’s switch is powerful enough to pattern match on the type 
> fairly nicely but I haven’t thought about it very much.
> 
> 
> All that said… if Swift got a macro system Rust’s error-chain seems to have 
> some interesting ideas that avoid a lot of boilerplate.

If Swift has a canonical built-in system for reporting an Error, why wouldn't 
it be used here? Why use casting?

-- E


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

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

[Russ Bishop via swift-evolution]

> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> I thought there is already a pending proposal on typed throws?
> 
> There was, I vaguely recall that it was by Russ?  I don’t see any open PRs 
> for it.

Hey now, there is no need for name calling ;)


> 
> I’m personally a big fan of typed throws, but I know that John McCall has 
> strong concerns.  I can’t argue that typed throws is a high priority at the 
> moment, but as soon as we start talking about concurrency the topic of a 
> Result type will come back up (for use with futures/async).

I fall firmly in John McCall’s camp on this one. If someone wants to read that 
part of the thread: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html
 


Of course if we want to automatically convert a throws function into an 
awaitable Result then that naturally begs the question of either Result’s error 
is typed as Error or not. I think I fall into the “as Error” camp here too 
because Swift’s switch is powerful enough to pattern match on the type fairly 
nicely but I haven’t thought about it very much.


All that said… if Swift got a macro system Rust’s error-chain seems to have 
some interesting ideas that avoid a lot of boilerplate.


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

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

[Jeremy Pereira via swift-evolution]

> On 9 Jan 2017, at 22:11, Anton Zhilin via swift-evolution 
>  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
> )

This is returning an error (or legitimate value) not throwing, yes? Because to 
me, and most other people probably, throwing is different to returning a 
legitimate value, not least because the normal control flow is interrupted. 
Making it look like a return value is confusing and wrong IMO.


> 
> 
> 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
>  | ())
> 
> ___
> 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 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

[Anton Zhilin via swift-evolution]

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 | ())

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

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

[Brandon Knope via swift-evolution]

I agree this looks better when something is being returned. 

What would it look like if the function returns nothing but can throw an error?

Brandon

> On Jan 9, 2017, at 4:10 AM, Tyler Cloutier via swift-evolution 
>  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.
> 
> 
>> 
>>> // 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
___
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] Move placement of 'throws' statement

[Jeremy Pereira via swift-evolution]

> On 4 Jan 2017, at 20:39, thislooksfun  wrote:
> 
> I still personally prefer the `throwing` prefix, but the way it currently is 
> also works just fine, I'll just have to adjust.

Yes, if error throwing had come up on Swift Evolution before it was 
implemented, I would have been in that camp too, mainly because of my 
Objective-C and Java background - it would have seemed “logical" to me to put 
the “denotes can throw” keyword at the opposite end of the declaration to the 
return type. However, I am now used to the way it is and I think it works fine.


> 
> -thislooksfun (tlf)
> 
>> On Jan 4, 2017, at 6:10 AM, Jeremy Pereira via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> I'm sorry if people dislike the placement of "throws", but that ship has 
>>> sailed,
>>> and any attempt to "fix" it at this point is just going to cause problems 
>>> for
>>> negligible benefit.
>>> 
>>> As I see it, the current syntax has one mild deficiency, called out 
>>> previously
>>> in this thread: a reader has to recognize that "throws -> X" does not mean
>>> that the function throws an X, but instead that it either throws or returns 
>>> an X.
>>> It's always nice when something is immediately obvious and doesn't have to
>>> be explicitly learned, and I appreciate and mourn that my design may have
>>> fallen short of that standard here. However, overall I still do think the 
>>> syntax
>>> is much cleaner than the alternatives, especially as return types grow more
>>> complicated, and that this small rule is not at all difficult to master.
>> 
>> I’m going to stand up for the way it is now. I do not think the design falls 
>> short or is deficient. Bearing in mind that “->” actually means “returns”, I 
>> honestly can’t see why anybody would think 
>> 
>>func foo() throws -> Int
>> 
>> could possibly be a function that throws an Int, especially if they have any 
>> knowledge of how the throw mechanism works in Swift (or any other language, 
>> for that matter). 
>> 
>> If it had been decided to put throws at the end, we’d probably be having an 
>> argument now that 
>> 
>>func foo() -> Int throws
>> 
>> appears to return an Int that throws, an argument with much more validity, 
>> as pointed out upthread, because 
>> 
>>func foo() -> () -> Int throws
>> 
>> really is ambiguous.
>> 
>> 
>>> 
>>> For what it's worth, this visual ambiguity is precisely why I would insist 
>>> that
>>> any typed-throws addition be spelled "throws(X)" instead of "throws X".
>>> 
>>> John.
>>> 
>>> 
 
> which work inconsistently and surprisingly in some cases.
> 
> Here is a different way of looking at this: The predictable case is
> the one we already have now (and we wouldn’t take it away).  Is your
> beef with the current syntax so great that you think it is worth
> adding complexity to the language to privilege some special cases?
 
 Not really, no.
 
 -- 
 -Dave
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

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

[Erica Sadun via swift-evolution]

I too am happy with the status quo.

As a reminder,  structured markup supports "- throws:" annotation

-- E

> On Jan 4, 2017, at 5:10 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
>> 
>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> I'm sorry if people dislike the placement of "throws", but that ship has 
>> sailed,
>> and any attempt to "fix" it at this point is just going to cause problems for
>> negligible benefit.
>> 
>> As I see it, the current syntax has one mild deficiency, called out 
>> previously
>> in this thread: a reader has to recognize that "throws -> X" does not mean
>> that the function throws an X, but instead that it either throws or returns 
>> an X.
>> It's always nice when something is immediately obvious and doesn't have to
>> be explicitly learned, and I appreciate and mourn that my design may have
>> fallen short of that standard here. However, overall I still do think the 
>> syntax
>> is much cleaner than the alternatives, especially as return types grow more
>> complicated, and that this small rule is not at all difficult to master.
> 
> I’m going to stand up for the way it is now. I do not think the design falls 
> short or is deficient. 

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

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

[thislooksfun via swift-evolution]

As I originally mentioned, once you are familiar with the facts that A) 
`throws` takes no parameters, and B) that `->` is returns, then I agree that 
iit is perfectly clear.

My original (and still continuing, but getting better) confusion might make 
more sense after seeing the following translated into Java (which was my 
original language)

//Swift:
func getData() throws -> Int {
  ...
}

//Java:
int getData() throws NumberFormatException {
  ...
}

Once again, after you're used to the Swift way, it makes perfect sense (and I 
kind of like it better than Java), but the initial switch-over from any 
statically defined thrown type language can be somewhat confusing.

I still personally prefer the `throwing` prefix, but the way it currently is 
also works just fine, I'll just have to adjust.

-thislooksfun (tlf)

> On Jan 4, 2017, at 6:10 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
>> 
>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> I'm sorry if people dislike the placement of "throws", but that ship has 
>> sailed,
>> and any attempt to "fix" it at this point is just going to cause problems for
>> negligible benefit.
>> 
>> As I see it, the current syntax has one mild deficiency, called out 
>> previously
>> in this thread: a reader has to recognize that "throws -> X" does not mean
>> that the function throws an X, but instead that it either throws or returns 
>> an X.
>> It's always nice when something is immediately obvious and doesn't have to
>> be explicitly learned, and I appreciate and mourn that my design may have
>> fallen short of that standard here. However, overall I still do think the 
>> syntax
>> is much cleaner than the alternatives, especially as return types grow more
>> complicated, and that this small rule is not at all difficult to master.
> 
> I’m going to stand up for the way it is now. I do not think the design falls 
> short or is deficient. Bearing in mind that “->” actually means “returns”, I 
> honestly can’t see why anybody would think
> 
>func foo() throws -> Int
> 
> could possibly be a function that throws an Int, especially if they have any 
> knowledge of how the throw mechanism works in Swift (or any other language, 
> for that matter).
> 
> If it had been decided to put throws at the end, we’d probably be having an 
> argument now that
> 
>func foo() -> Int throws
> 
> appears to return an Int that throws, an argument with much more validity, as 
> pointed out upthread, because
> 
>func foo() -> () -> Int throws
> 
> really is ambiguous.
> 
> 
>> 
>> For what it's worth, this visual ambiguity is precisely why I would insist 
>> that
>> any typed-throws addition be spelled "throws(X)" instead of "throws X".
>> 
>> John.
>> 
>> 
>>> 
 which work inconsistently and surprisingly in some cases.
 
 Here is a different way of looking at this: The predictable case is
 the one we already have now (and we wouldn’t take it away).  Is your
 beef with the current syntax so great that you think it is worth
 adding complexity to the language to privilege some special cases?
>>> 
>>> Not really, no.
>>> 
>>> --
>>> -Dave
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 


signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jeremy Pereira via swift-evolution]

> On 3 Jan 2017, at 16:29, John McCall via swift-evolution 
>  wrote:
> 
> 
> 
> I'm sorry if people dislike the placement of "throws", but that ship has 
> sailed,
> and any attempt to "fix" it at this point is just going to cause problems for
> negligible benefit.
> 
> As I see it, the current syntax has one mild deficiency, called out previously
> in this thread: a reader has to recognize that "throws -> X" does not mean
> that the function throws an X, but instead that it either throws or returns 
> an X.
> It's always nice when something is immediately obvious and doesn't have to
> be explicitly learned, and I appreciate and mourn that my design may have
> fallen short of that standard here. However, overall I still do think the 
> syntax
> is much cleaner than the alternatives, especially as return types grow more
> complicated, and that this small rule is not at all difficult to master.

I’m going to stand up for the way it is now. I do not think the design falls 
short or is deficient. Bearing in mind that “->” actually means “returns”, I 
honestly can’t see why anybody would think 

func foo() throws -> Int

could possibly be a function that throws an Int, especially if they have any 
knowledge of how the throw mechanism works in Swift (or any other language, for 
that matter). 

If it had been decided to put throws at the end, we’d probably be having an 
argument now that 

func foo() -> Int throws

appears to return an Int that throws, an argument with much more validity, as 
pointed out upthread, because 

func foo() -> () -> Int throws

really is ambiguous.


> 
> For what it's worth, this visual ambiguity is precisely why I would insist 
> that
> any typed-throws addition be spelled "throws(X)" instead of "throws X".
> 
> John.
> 
> 
>> 
>>> which work inconsistently and surprisingly in some cases.
>>> 
>>> Here is a different way of looking at this: The predictable case is
>>> the one we already have now (and we wouldn’t take it away).  Is your
>>> beef with the current syntax so great that you think it is worth
>>> adding complexity to the language to privilege some special cases?
>> 
>> Not really, no.
>> 
>> -- 
>> -Dave
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Derrick Ho via swift-evolution]

John McCall +1
I agree. The placement should remain the same.
On Tue, Jan 3, 2017 at 8:29 AM John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Wed Dec 28 2016, Chris Lattner  > wrote:
>
> On Dec 28, 2016, at 9:52 AM, Dave Abrahams  wrote:
>
> it would be ambiguous to move the ‘throws’ keyword to the end of the
> function type, because you'd get:
>
>
> let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>
>
> I see.
>
> We *could* say that the "throws" keyword comes after the return type
> unless it's a function type, in which case it comes after the return
> type's parameter list
>
>  let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>
> I admit this is a horrible rule from a language designer's point of view
> but there's a chance it could end up being better for users.
>
>
> Indeed this is horrid for an ivory tower language designer, but the
> pragmatic among them often have to make concessions to the real world.
> That said, I think this would be worse for typical swift programmers
> as well: it introduces multiple ways to do things,
>
>
> Do you mean it introduces multiple ways to do the *same* thing?  I
> didn't think I was introducing any of those.  If you think I was, you
> probably misunderstood my suggestion (or I did!), FWIW.
>
>
> Chris's point is that we can't stop allowing "throws" where it currently
> is, and
> therefore any proposal which allows it in a new place creates two ways of
> spelling the same thing.
>
> Also, your proposal reinterprets the currently-valid syntax:
>   (_ a : Int) -> (_ b : Float) throws -> Double
> Currently this means a non-throwing function that returns a throwing
> function.
> Your proposal flips it around.
>
> Also, I would find this extremely surprising as a user.  A core aspect of
> the
> first function type is written *inside* the second?  With all respect,
> Dave,
> that is just bizarre. :)
>
> I'm sorry if people dislike the placement of "throws", but that ship has
> sailed,
> and any attempt to "fix" it at this point is just going to cause problems
> for
> negligible benefit.
>
> As I see it, the current syntax has one mild deficiency, called out
> previously
> in this thread: a reader has to recognize that "throws -> X" does not mean
> that the function throws an X, but instead that it either throws or
> returns an X.
> It's always nice when something is immediately obvious and doesn't have to
> be explicitly learned, and I appreciate and mourn that my design may have
> fallen short of that standard here. However, overall I still do think the
> syntax
> is much cleaner than the alternatives, especially as return types grow more
> complicated, and that this small rule is not at all difficult to master.
>
> For what it's worth, this visual ambiguity is precisely why I would insist
> that
> any typed-throws addition be spelled "throws(X)" instead of "throws X".
>
> John.
>
>
>
> which work inconsistently and surprisingly in some cases.
>
> Here is a different way of looking at this: The predictable case is
> the one we already have now (and we wouldn’t take it away).  Is your
> beef with the current syntax so great that you think it is worth
> adding complexity to the language to privilege some special cases?
>
>
> Not really, no.
>
> --
> -Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Dec 28 2016, Chris Lattner  > wrote:
> 
>>> On Dec 28, 2016, at 9:52 AM, Dave Abrahams  wrote:
>>> 
 it would be ambiguous to move the ‘throws’ keyword to the end of the
 function type, because you'd get:
 
>> 
let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>>> 
>>> I see.  
>>> 
>>> We *could* say that the "throws" keyword comes after the return type
>>> unless it's a function type, in which case it comes after the return
>>> type's parameter list
>>> 
>>>  let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>>> 
>>> I admit this is a horrible rule from a language designer's point of view
>>> but there's a chance it could end up being better for users.
>> 
>> Indeed this is horrid for an ivory tower language designer, but the
>> pragmatic among them often have to make concessions to the real world.
>> That said, I think this would be worse for typical swift programmers
>> as well: it introduces multiple ways to do things, 
> 
> Do you mean it introduces multiple ways to do the *same* thing?  I
> didn't think I was introducing any of those.  If you think I was, you
> probably misunderstood my suggestion (or I did!), FWIW.

Chris's point is that we can't stop allowing "throws" where it currently is, and
therefore any proposal which allows it in a new place creates two ways of
spelling the same thing.

Also, your proposal reinterprets the currently-valid syntax:
  (_ a : Int) -> (_ b : Float) throws -> Double
Currently this means a non-throwing function that returns a throwing function.
Your proposal flips it around.

Also, I would find this extremely surprising as a user.  A core aspect of the
first function type is written *inside* the second?  With all respect, Dave,
that is just bizarre. :)

I'm sorry if people dislike the placement of "throws", but that ship has sailed,
and any attempt to "fix" it at this point is just going to cause problems for
negligible benefit.

As I see it, the current syntax has one mild deficiency, called out previously
in this thread: a reader has to recognize that "throws -> X" does not mean
that the function throws an X, but instead that it either throws or returns an 
X.
It's always nice when something is immediately obvious and doesn't have to
be explicitly learned, and I appreciate and mourn that my design may have
fallen short of that standard here. However, overall I still do think the syntax
is much cleaner than the alternatives, especially as return types grow more
complicated, and that this small rule is not at all difficult to master.

For what it's worth, this visual ambiguity is precisely why I would insist that
any typed-throws addition be spelled "throws(X)" instead of "throws X".

John.


> 
>> which work inconsistently and surprisingly in some cases.
>> 
>> Here is a different way of looking at this: The predictable case is
>> the one we already have now (and we wouldn’t take it away).  Is your
>> beef with the current syntax so great that you think it is worth
>> adding complexity to the language to privilege some special cases?
> 
> Not really, no.
> 
> -- 
> -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

[Dave Abrahams via swift-evolution]

on Wed Dec 28 2016, Chris Lattner  wrote:

>> On Dec 28, 2016, at 9:52 AM, Dave Abrahams  wrote:
>> 
>>> it would be ambiguous to move the ‘throws’ keyword to the end of the
>>> function type, because you'd get:
>>> 
>
>>> let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>> 
>> I see.  
>> 
>> We *could* say that the "throws" keyword comes after the return type
>> unless it's a function type, in which case it comes after the return
>> type's parameter list
>> 
>>   let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>> 
>> I admit this is a horrible rule from a language designer's point of view
>> but there's a chance it could end up being better for users.
>
> Indeed this is horrid for an ivory tower language designer, but the
> pragmatic among them often have to make concessions to the real world.
> That said, I think this would be worse for typical swift programmers
> as well: it introduces multiple ways to do things, 

Do you mean it introduces multiple ways to do the *same* thing?  I
didn't think I was introducing any of those.  If you think I was, you
probably misunderstood my suggestion (or I did!), FWIW.

> which work inconsistently and surprisingly in some cases.
>
> Here is a different way of looking at this: The predictable case is
> the one we already have now (and we wouldn’t take it away).  Is your
> beef with the current syntax so great that you think it is worth
> adding complexity to the language to privilege some special cases?

Not really, no.

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

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

[Chris Lattner via swift-evolution]

> On Dec 28, 2016, at 9:52 AM, Dave Abrahams  wrote:
> 
>> it would be ambiguous to move the ‘throws’ keyword to the end of the
>> function type, because you'd get:
>> 
>>  let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
> 
> I see.  
> 
> We *could* say that the "throws" keyword comes after the return type
> unless it's a function type, in which case it comes after the return
> type's parameter list
> 
>   let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
> 
> I admit this is a horrible rule from a language designer's point of view
> but there's a chance it could end up being better for users.

Indeed this is horrid for an ivory tower language designer, but the pragmatic 
among them often have to make concessions to the real world.  That said, I 
think this would be worse for typical swift programmers as well: it introduces 
multiple ways to do things, which work inconsistently and surprisingly in some 
cases.  

Here is a different way of looking at this: The predictable case is the one we 
already have now (and we wouldn’t take it away).  Is your beef with the current 
syntax so great that you think it is worth adding complexity to the language to 
privilege some special cases?

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

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

[Chris Lattner via swift-evolution]

> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I thought there is already a pending proposal on typed throws?

There was, I vaguely recall that it was by Russ?  I don’t see any open PRs for 
it.

I’m personally a big fan of typed throws, but I know that John McCall has 
strong concerns.  I can’t argue that typed throws is a high priority at the 
moment, but as soon as we start talking about concurrency the topic of a Result 
type will come back up (for use with futures/async).

I think that discussion will naturally drive the priority on settling the typed 
throws debate.

-Chris

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

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

[thislooksfun via swift-evolution]

+1 for optional type definition. As someone also coming from Java, I agree that 
its implementation is less than ideal. When I first suggested moving the 
`throws` statement, I thought the decision on whether or not to declare (even 
optionally) the exception types had already been made. I see now that I was 
mistaken.

It seems clear that the two issues are closely tied, and the decision on moving 
the `throws` statement can't be made until a decision on type defined errors is 
made.
For that reason, perhaps this should now move to a new thread discussing how 
best to implement a(n optional) typed `throws` system?

-thislooksfun (tlf)

> On Dec 28, 2016, at 3:59 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> -1 for addressing this now. Typed throws will undoubtedly affect this change 
> and the two issues should be addressed at the same time.
> 
> As a Java veteran, I agree with the sentiment to avoid the Java exception 
> typing mechanism which complicates using and maintaining large projects. 
> Knowing the recoverable exceptions that a function can throw cane be useful, 
> however, and some sort of optional listing of exception types is probably the 
> best solution.
> 
> 
>> On Dec 28, 2016, at 2:36 PM, Anton Zhilin via swift-evolution 
>> > wrote:
>> 
>> TLDR: I support moving throws, and also think that ‘typed throws’ should fit 
>> for Phase 2, at least.
>> 
>> let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>> Count me in those who cried in anger :)
>> 
>> I see why current syntax is very logical for currying:
>> 
>> let x: (Int) throws -> (Float) throws -> Double   // clean
>> 
>> let x: (Int) -> (Float) -> Double throws throws   // looks ambiguous
>> Although, the ambiguity can be resolved using parentheses:
>> 
>> let x: (Int) -> ((Float) -> Double throws) throws
>> 
>> let x: (Int) -> ((Float) -> Double throws Error2) throws Error1   // with 
>> 'typed throws'
>> Compare it to how we incorporate optionals (which are just another form of 
>> error handling) in curried functions now:
>> 
>> let x: (Int) -> ((Float) -> Double?)?
>> Overall, current Swift syntax is uniquely nice to error handling in curried 
>> functions. Is it worth keeping this advantage? Probably not, if the new form 
>> does not contain too much noise and is even more logical. Everything slides 
>> into place, if throws is a binary operator on types with precedence higher 
>> than ->. Although A throws B is not a type on itself, I can clearly see it 
>> becoming one in the future. Then try will handle pattern matching of such 
>> types.
>> 
>> Another point for the suggested syntax: as we now know, Swift users prefer 
>> to see results after -> in function declarations. Is it stretching too far 
>> to conclude that error type is a possible result, and should also come after 
>> ->?
>> 
>> ___
>> 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] Move placement of 'throws' statement

[Christopher Kornher via swift-evolution]

-1 for addressing this now. Typed throws will undoubtedly affect this change 
and the two issues should be addressed at the same time.

As a Java veteran, I agree with the sentiment to avoid the Java exception 
typing mechanism which complicates using and maintaining large projects. 
Knowing the recoverable exceptions that a function can throw cane be useful, 
however, and some sort of optional listing of exception types is probably the 
best solution.


> On Dec 28, 2016, at 2:36 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> TLDR: I support moving throws, and also think that ‘typed throws’ should fit 
> for Phase 2, at least.
> 
> let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
> Count me in those who cried in anger :)
> 
> I see why current syntax is very logical for currying:
> 
> let x: (Int) throws -> (Float) throws -> Double   // clean
> 
> let x: (Int) -> (Float) -> Double throws throws   // looks ambiguous
> Although, the ambiguity can be resolved using parentheses:
> 
> let x: (Int) -> ((Float) -> Double throws) throws
> 
> let x: (Int) -> ((Float) -> Double throws Error2) throws Error1   // with 
> 'typed throws'
> Compare it to how we incorporate optionals (which are just another form of 
> error handling) in curried functions now:
> 
> let x: (Int) -> ((Float) -> Double?)?
> Overall, current Swift syntax is uniquely nice to error handling in curried 
> functions. Is it worth keeping this advantage? Probably not, if the new form 
> does not contain too much noise and is even more logical. Everything slides 
> into place, if throws is a binary operator on types with precedence higher 
> than ->. Although A throws B is not a type on itself, I can clearly see it 
> becoming one in the future. Then try will handle pattern matching of such 
> types.
> 
> Another point for the suggested syntax: as we now know, Swift users prefer to 
> see results after -> in function declarations. Is it stretching too far to 
> conclude that error type is a possible result, and should also come after ->?
> 
> ___
> 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

[Anton Zhilin via swift-evolution]

TLDR: I support moving throws, and also think that ‘typed throws’ should
fit for Phase 2, at least.

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

Count me in those who cried in anger :)
--

I see why current syntax is very logical for currying:

let x: (Int) throws -> (Float) throws -> Double   // clean

let x: (Int) -> (Float) -> Double throws throws   // looks ambiguous

Although, the ambiguity can be resolved using parentheses:

let x: (Int) -> ((Float) -> Double throws) throws

let x: (Int) -> ((Float) -> Double throws Error2) throws Error1   //
with 'typed throws'

Compare it to how we incorporate optionals (which are just another form of
error handling) in curried functions now:

let x: (Int) -> ((Float) -> Double?)?

Overall, current Swift syntax is uniquely nice to error handling in curried
functions. Is it worth keeping this advantage? Probably not, if the new
form does not contain too much noise and is even more logical. Everything
slides into place, if throws is a binary operator on types with precedence
higher than ->. Although A throws B is not a type on itself, I can clearly
see it becoming one in the future. Then try will handle pattern matching of
such types.

Another point for the suggested syntax: as we now know, Swift users prefer
to see results after -> in function declarations. Is it stretching too far
to conclude that error type is a possible result, and should also come
after ->?
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Guillaume Lessard via swift-evolution]

> On 28 déc. 2016, at 10:52, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Tue Dec 27 2016, Chris Lattner  wrote:
> 
>> it would be ambiguous to move the ‘throws’ keyword to the end of the
>> function type, because you'd get:
>> 
>>  let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
> 
> I see.  
> 
> We *could* say that the "throws" keyword comes after the return type
> unless it's a function type, in which case it comes after the return
> type's parameter list
> 
>   let x : (_ a : Int) -> (_ b: Float) throws -> Double throws

I can’t parse this at all; which is which?
Could you illustrate this strange rule to return (a) a non-throwing function 
from a throwing function, and (b) a throwing function from a non-throwing 
function?

Cheers,
Guillaume Lessard

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

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

[Dave Abrahams via swift-evolution]

on Wed Dec 28 2016, Goffredo Marocchi  wrote:

> I sense s disturbance in the force as if hundreds of pure functional
> programmers cried in anger ;).

Remember: Your focus determines your reality.

>
>> On 28 Dec 2016, at 17:52, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>>> on Tue Dec 27 2016, Chris Lattner  wrote:
>>> 
>>> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
> 
> // Move `throws` to the end
> func baz() -> String throws
 
 I agree that reads much better.
>>> 
>>> This doesn’t work unless you’re willing to break consistency with
>>> function type syntax, or if you’re willing to make function
>>> [type/decl] syntax ambiguous.
>>> 
>>> How would you express this, for example?
>>> 
>>>let x : (_ a : Int) throws -> (_ b: Float) throws -> Double
>>> 
>>> it would be ambiguous to move the ‘throws’ keyword to the end of the
>>> function type, because you'd get:
>>> 
>>>let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>> 
>> I see.  
>> 
>> We *could* say that the "throws" keyword comes after the return type
>> unless it's a function type, in which case it comes after the return
>> type's parameter list
>> 
>>   let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>> 
>> I admit this is a horrible rule from a language designer's point of view
>> but there's a chance it could end up being better for users.
>> Functions-that-return-functions are, after all, the 0.1% case.
>> 
>> -- 
>> -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

-- 
-Dave

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

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

[Goffredo Marocchi via swift-evolution]

I sense s disturbance in the force as if hundreds of pure functional 
programmers cried in anger ;).

Sent from my iPhone

> On 28 Dec 2016, at 17:52, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Tue Dec 27 2016, Chris Lattner  wrote:
>> 
>> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution 
>>  wrote:
 
 // Move `throws` to the end
 func baz() -> String throws
>>> 
>>> I agree that reads much better.
>> 
>> This doesn’t work unless you’re willing to break consistency with
>> function type syntax, or if you’re willing to make function
>> [type/decl] syntax ambiguous.
>> 
>> How would you express this, for example?
>> 
>>let x : (_ a : Int) throws -> (_ b: Float) throws -> Double
>> 
>> it would be ambiguous to move the ‘throws’ keyword to the end of the
>> function type, because you'd get:
>> 
>>let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
> 
> I see.  
> 
> We *could* say that the "throws" keyword comes after the return type
> unless it's a function type, in which case it comes after the return
> type's parameter list
> 
>   let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
> 
> I admit this is a horrible rule from a language designer's point of view
> but there's a chance it could end up being better for users.
> Functions-that-return-functions are, after all, the 0.1% case.
> 
> -- 
> -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

[Dave Abrahams via swift-evolution]

on Tue Dec 27 2016, Chris Lattner  wrote:

> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution 
>  wrote:
>>> 
>>> // Move `throws` to the end
>>> func baz() -> String throws
>> 
>> I agree that reads much better.
>
> This doesn’t work unless you’re willing to break consistency with
> function type syntax, or if you’re willing to make function
> [type/decl] syntax ambiguous.
>
> How would you express this, for example?
>
>   let x : (_ a : Int) throws -> (_ b: Float) throws -> Double
>
> it would be ambiguous to move the ‘throws’ keyword to the end of the
> function type, because you'd get:
>
>   let x : (_ a : Int) -> (_ b: Float) -> Double throws throws

I see.  

We *could* say that the "throws" keyword comes after the return type
unless it's a function type, in which case it comes after the return
type's parameter list

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

I admit this is a horrible rule from a language designer's point of view
but there's a chance it could end up being better for users.
Functions-that-return-functions are, after all, the 0.1% case.

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

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

[Chris Lattner via swift-evolution]

On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution 
 wrote:
>> 
>> // Move `throws` to the end
>> func baz() -> String throws
> 
> I agree that reads much better.

This doesn’t work unless you’re willing to break consistency with function type 
syntax, or if you’re willing to make function [type/decl] syntax ambiguous.

How would you express this, for example?

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

it would be ambiguous to move the ‘throws’ keyword to the end of the function 
type, because you'd get:

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

-Chris

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

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

[T.J. Usiyan via swift-evolution]

I don't know how this became a discussion for specifying errors when
throwing but +1 on the off chance that this thread is actually used to
gauge interest.

On Tue, Dec 27, 2016 at 10:27 PM, Daniel Leping via swift-evolution <
swift-evolution@swift.org> wrote:

> -1 for checked exceptions. Don't make it java. For thous interested why,
> just google. It's common frustration in Java world so the info is
> everywhere.
>
> In general you end up with wrapping and wrapping and wrapping the fine
> grained exceptions into general ones. And you have more exception classes
> than functional ones. Please, don't go this path.
>
> On Wed, 28 Dec 2016 at 3:46 thislooksfun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> That's fair. The reasoning I read about mentioned making it easier for
>> newcomers, but it's very possible that was a 3rd party opinion (I don't
>> remember). I certainly did not intend to upset anyone.
>>
>> Either way, I do still believe that the current placement / syntax isn't
>> entirely clear.
>>
>>
>>
>> -thislooksfun (tlf)
>>
>>
>>
>>
>>
>>
>>
>> On Dec 27, 2016, at 4:09 PM, Xiaodi Wu  wrote:
>>
>> Offlist on purpose?
>>
>> On Tue, Dec 27, 2016 at 5:03 PM, thislooksfun 
>> wrote:
>>
>> Thinking about it logically, it's placement does fit, yes.
>>
>>
>> :) That's all one can ask.
>>
>>
>> I'm not debating that the current placement is logical once you get used
>> to it, but on a related note, so are ++ and --, which were removed to make
>> the language easier and more immediately intuitive for new programmers.
>>
>>
>> Bringing up ++ and -- on the list just makes everyone unhappy; also,
>> classical for;; loops. It's like Godwin's law for Swift Evolution :P
>>
>> But FWIW, making it easier for new programmers was not the whole
>> rationale (or, if I recall, even a large part of it). There's a whole
>> school of thought in language design that removing ++ and -- and for;;
>> loops is the _more logical_ thing to do from a modern language design
>> perspective. I don't have the link, but there was an article recently
>> evaluating Rust, Go, Swift, and a bunch of other C-family languages for the
>> "quality" of their design. An opinionated piece, to be sure, but having ++
>> and for;; were regarded as negatives that languages would lose points for.
>> So let's be clear that it's not a way of thinking that originated from
>> Swift wanting to help beginners, nor is it even limited to Swift at all.
>>
>>
>> My only point was that if they are willing to go to such lengths to make
>> the language easy to understand as to remove a very well known feature like
>> the incremention and decremention operators, maybe the placement of
>> `throws` should be reviewed to make sure it's also intuitive.
>>
>>
>>
>> -thislooksfun (tlf)
>>
>>
>>
>>
>>
>>
>>
>> On Dec 27, 2016, at 3:58 PM, Xiaodi Wu  wrote:
>>
>> Agree, it doesn't seem to read naturally at first glance.
>>
>> However, one way perhaps to think about the rationale for this is that
>> `throws` does "fit" logically between the parameters and the return type: a
>> function that throws might take certain arguments and, by throwing, never
>> return a value of the stated return type. In that perspective, `throws`
>> could be justified in its current position interposed between the input and
>> the desired output.
>>
>>
>> On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution > evolut...@swift.org> wrote:
>>
>> If some form of explicitly typed errors is added, my initial problem goes
>> away. The only reason I suggested the move in the first place, is that a
>> combination of `throws` and return (-> T) statements makes it *look* like
>> there is already explicitly typed errors, especially to those of us coming
>> from Java.
>>
>> -thislooksfun (tlf)
>>
>> On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Moving “throws” or changing it to a prefix “throwing” as was originally
>> suggested are relatively minor, reasonable improvements.
>>
>> We do need to consider if it restricts future language evolution (such as
>> potentially listing all of the thrown errors), so that’s why it’s relevant
>> to talk a little bit about that and what are options would be; but I think
>> fundamental, non-backwards compatible changes to how you invoke throwing
>> functions are probably too big to be reasonable.
>>
>>
>> I'm -1 on big changes such as suggested as well. The deliberate choice to
>> separate error handling from other code with `do { }` was a deliberate
>> design choice and it'd be very disruptive to break that now. And in terms
>> of just gut feeling, switching over errors and return values at the same
>> time seems like going in the wrong direction.
>>
>>
>> - Karl
>>
>> On 27 Dec 2016, at 22:31, Derrick Ho  wrote:
>>
>> Right. it should support the normal return type as well as the errors.
>> Here is my 

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

[Daniel Leping via swift-evolution]

-1 for checked exceptions. Don't make it java. For thous interested why,
just google. It's common frustration in Java world so the info is
everywhere.

In general you end up with wrapping and wrapping and wrapping the fine
grained exceptions into general ones. And you have more exception classes
than functional ones. Please, don't go this path.

On Wed, 28 Dec 2016 at 3:46 thislooksfun via swift-evolution <
swift-evolution@swift.org> wrote:

> That's fair. The reasoning I read about mentioned making it easier for
> newcomers, but it's very possible that was a 3rd party opinion (I don't
> remember). I certainly did not intend to upset anyone.
>
> Either way, I do still believe that the current placement / syntax isn't
> entirely clear.
>
>
>
> -thislooksfun (tlf)
>
>
>
>
>
>
>
> On Dec 27, 2016, at 4:09 PM, Xiaodi Wu  wrote:
>
> Offlist on purpose?
>
> On Tue, Dec 27, 2016 at 5:03 PM, thislooksfun 
> wrote:
>
> Thinking about it logically, it's placement does fit, yes.
>
>
> :) That's all one can ask.
>
>
> I'm not debating that the current placement is logical once you get used
> to it, but on a related note, so are ++ and --, which were removed to make
> the language easier and more immediately intuitive for new programmers.
>
>
> Bringing up ++ and -- on the list just makes everyone unhappy; also,
> classical for;; loops. It's like Godwin's law for Swift Evolution :P
>
> But FWIW, making it easier for new programmers was not the whole rationale
> (or, if I recall, even a large part of it). There's a whole school of
> thought in language design that removing ++ and -- and for;; loops is the
> _more logical_ thing to do from a modern language design perspective. I
> don't have the link, but there was an article recently evaluating Rust, Go,
> Swift, and a bunch of other C-family languages for the "quality" of their
> design. An opinionated piece, to be sure, but having ++ and for;; were
> regarded as negatives that languages would lose points for. So let's be
> clear that it's not a way of thinking that originated from Swift wanting to
> help beginners, nor is it even limited to Swift at all.
>
>
> My only point was that if they are willing to go to such lengths to make
> the language easy to understand as to remove a very well known feature like
> the incremention and decremention operators, maybe the placement of
> `throws` should be reviewed to make sure it's also intuitive.
>
>
>
> -thislooksfun (tlf)
>
>
>
>
>
>
>
> On Dec 27, 2016, at 3:58 PM, Xiaodi Wu  wrote:
>
> Agree, it doesn't seem to read naturally at first glance.
>
> However, one way perhaps to think about the rationale for this is that
> `throws` does "fit" logically between the parameters and the return type: a
> function that throws might take certain arguments and, by throwing, never
> return a value of the stated return type. In that perspective, `throws`
> could be justified in its current position interposed between the input and
> the desired output.
>
>
> On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If some form of explicitly typed errors is added, my initial problem goes
> away. The only reason I suggested the move in the first place, is that a
> combination of `throws` and return (-> T) statements makes it *look* like
> there is already explicitly typed errors, especially to those of us coming
> from Java.
>
> -thislooksfun (tlf)
>
> On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Moving “throws” or changing it to a prefix “throwing” as was originally
> suggested are relatively minor, reasonable improvements.
>
> We do need to consider if it restricts future language evolution (such as
> potentially listing all of the thrown errors), so that’s why it’s relevant
> to talk a little bit about that and what are options would be; but I think
> fundamental, non-backwards compatible changes to how you invoke throwing
> functions are probably too big to be reasonable.
>
>
> I'm -1 on big changes such as suggested as well. The deliberate choice to
> separate error handling from other code with `do { }` was a deliberate
> design choice and it'd be very disruptive to break that now. And in terms
> of just gut feeling, switching over errors and return values at the same
> time seems like going in the wrong direction.
>
>
> - Karl
>
> On 27 Dec 2016, at 22:31, Derrick Ho  wrote:
>
> Right. it should support the normal return type as well as the errors.
> Here is my revised suggestion.
>
> func foo() throws -> String {}
>
> switch try foo() {
> case .returnValue(let value):
> // do something with value
>
> case .MyEnumErrorFirstError:
> // handle error
>
> default:
> // handle NSError
> }
> On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu  wrote:
>
> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <
> 

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

[thislooksfun via swift-evolution]

That's fair. The reasoning I read about mentioned making it easier for 
newcomers, but it's very possible that was a 3rd party opinion (I don't 
remember). I certainly did not intend to upset anyone.

Either way, I do still believe that the current placement / syntax isn't 
entirely clear.

-thislooksfun (tlf)

> On Dec 27, 2016, at 4:09 PM, Xiaodi Wu  wrote:
> 
> Offlist on purpose?
> 
> On Tue, Dec 27, 2016 at 5:03 PM, thislooksfun  > wrote:
> Thinking about it logically, it's placement does fit, yes.
> 
> :) That's all one can ask.
>  
> I'm not debating that the current placement is logical once you get used to 
> it, but on a related note, so are ++ and --, which were removed to make the 
> language easier and more immediately intuitive for new programmers.
> 
> Bringing up ++ and -- on the list just makes everyone unhappy; also, 
> classical for;; loops. It's like Godwin's law for Swift Evolution :P
> 
> But FWIW, making it easier for new programmers was not the whole rationale 
> (or, if I recall, even a large part of it). There's a whole school of thought 
> in language design that removing ++ and -- and for;; loops is the _more 
> logical_ thing to do from a modern language design perspective. I don't have 
> the link, but there was an article recently evaluating Rust, Go, Swift, and a 
> bunch of other C-family languages for the "quality" of their design. An 
> opinionated piece, to be sure, but having ++ and for;; were regarded as 
> negatives that languages would lose points for. So let's be clear that it's 
> not a way of thinking that originated from Swift wanting to help beginners, 
> nor is it even limited to Swift at all.
>  
> My only point was that if they are willing to go to such lengths to make the 
> language easy to understand as to remove a very well known feature like the 
> incremention and decremention operators, maybe the placement of `throws` 
> should be reviewed to make sure it's also intuitive.
> 
> -thislooksfun (tlf)
> 
>> On Dec 27, 2016, at 3:58 PM, Xiaodi Wu > > wrote:
>> 
>> Agree, it doesn't seem to read naturally at first glance.
>> 
>> However, one way perhaps to think about the rationale for this is that 
>> `throws` does "fit" logically between the parameters and the return type: a 
>> function that throws might take certain arguments and, by throwing, never 
>> return a value of the stated return type. In that perspective, `throws` 
>> could be justified in its current position interposed between the input and 
>> the desired output.
>> 
>> 
>> On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution 
>> > wrote:
>> If some form of explicitly typed errors is added, my initial problem goes 
>> away. The only reason I suggested the move in the first place, is that a 
>> combination of `throws` and return (-> T) statements makes it look like 
>> there is already explicitly typed errors, especially to those of us coming 
>> from Java.
>> 
>> -thislooksfun (tlf)
>> 
>>> On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution 
>>> > wrote:
>>> 
>>> Moving “throws” or changing it to a prefix “throwing” as was originally 
>>> suggested are relatively minor, reasonable improvements.
>>> 
>>> We do need to consider if it restricts future language evolution (such as 
>>> potentially listing all of the thrown errors), so that’s why it’s relevant 
>>> to talk a little bit about that and what are options would be; but I think 
>>> fundamental, non-backwards compatible changes to how you invoke throwing 
>>> functions are probably too big to be reasonable.
>>> 
>> 
>> 
>> I'm -1 on big changes such as suggested as well. The deliberate choice to 
>> separate error handling from other code with `do { }` was a deliberate 
>> design choice and it'd be very disruptive to break that now. And in terms of 
>> just gut feeling, switching over errors and return values at the same time 
>> seems like going in the wrong direction.
>>  
>>> - Karl
>>> 
 On 27 Dec 2016, at 22:31, Derrick Ho > wrote:
 
 Right. it should support the normal return type as well as the errors. 
 Here is my revised suggestion.
 
 func foo() throws -> String {}
 
 switch try foo() {
 case .returnValue(let value):
 // do something with value
 
 case .MyEnumErrorFirstError:
 // handle error
 
 default: 
 // handle NSError
 }
 On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu > wrote:
 On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution 
 > wrote:
 I suppose "throws" could be enhanced to produce a 

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

[Tino Heth via swift-evolution]

> 
> Under the hood each expression passed to "throw" could make something like
> 
> enum bar_abcdefj_throw {
> case genericError // all NSError go here
> case MyEnumErrorFirstError
> }
> 
> Where abcdefj is unique characters.
> 
> 
> This enum would only be visible through the catch blocks which would act like 
> a switch statement.

Imho that's to much magic and way to special, and as errors often are regular 
enums themselves, we'd end up in two levels of them.

There has been a discussion about ad-hoc enums before, but those were supposed 
to be used as parameters (which seems lot less complicated to me — but still 
wasn't simple enough to be added to the language).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

FYI, here's the December 2015 discussion on typed throws:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003284.html


On Tue, Dec 27, 2016 at 4:57 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> Right now, we basically have "throws Error", and no matter what is
> actually thrown, we can always catch exhaustive by keeping the statement
> unspecific.
>
>
> True, but for me it's more about knowing what a method can throw
>
> That's always possible if throw can be annotated with a list of errors; in
> this case, it's up to the library author to be specific
>
>
> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>
> Imho to much confusion with no real benefit:
> Shouldn't it be up to the caller to decide which errors need special
> treatment? The library can't enforce proper handling at all.
>
>
> Partly, but it's really just intended to distinguish things that are
> genuine runtime errors, versus things that shouldn't have happened,
>
> That reminds me to much on the route Java took...
>
> If the distinctions not significant enough though then the "optional"
> error types could just be ignored for now, I think the more important
> ability is the ellipsis indicating "plus other errors" so we can specify
> either exhaustive lists of error types, or keep them open-ended, in which
> case the types listed are those that would be placed as catch blocks, with
> the ellipsis indicating that a catch-all is still required (or throw on the
> current method).
>
> That are three levels of error whereas one should be enough — and I'm
> really not a fan of ellipsis:
> Just require the list to be complete, which can always be achieved by
> adding Error (or Any — imho we should remove the restriction that throwable
> types have to conform to an empty protocol).
> In this case, the meaning of the list would be more or less only
> documentation (it's no restriction on what can be thrown), but that would
> be fine for me, and it could be used for autocompletion as well.
>
> ___
> 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

[Xiaodi Wu via swift-evolution]

Agree, it doesn't seem to read naturally at first glance.

However, one way perhaps to think about the rationale for this is that
`throws` does "fit" logically between the parameters and the return type: a
function that throws might take certain arguments and, by throwing, never
return a value of the stated return type. In that perspective, `throws`
could be justified in its current position interposed between the input and
the desired output.


On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution <
swift-evolution@swift.org> wrote:

> If some form of explicitly typed errors is added, my initial problem goes
> away. The only reason I suggested the move in the first place, is that a
> combination of `throws` and return (-> T) statements makes it *look* like
> there is already explicitly typed errors, especially to those of us coming
> from Java.
>
> -thislooksfun (tlf)
>
> On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Moving “throws” or changing it to a prefix “throwing” as was originally
> suggested are relatively minor, reasonable improvements.
>
> We do need to consider if it restricts future language evolution (such as
> potentially listing all of the thrown errors), so that’s why it’s relevant
> to talk a little bit about that and what are options would be; but I think
> fundamental, non-backwards compatible changes to how you invoke throwing
> functions are probably too big to be reasonable.
>
>
I'm -1 on big changes such as suggested as well. The deliberate choice to
separate error handling from other code with `do { }` was a deliberate
design choice and it'd be very disruptive to break that now. And in terms
of just gut feeling, switching over errors and return values at the same
time seems like going in the wrong direction.


> - Karl
>
> On 27 Dec 2016, at 22:31, Derrick Ho  wrote:
>
> Right. it should support the normal return type as well as the errors.
> Here is my revised suggestion.
>
> func foo() throws -> String {}
>
> switch try foo() {
> case .returnValue(let value):
> // do something with value
>
> case .MyEnumErrorFirstError:
> // handle error
>
> default:
> // handle NSError
> }
> On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu  wrote:
>
>> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I suppose "throws" could be enhanced to produce a compiletime enum
>>
>> func bar() throws {
>> throw NSError()
>> throw MyEnumError.firstError
>> }
>>
>> Under the hood each expression passed to "throw" could make something like
>>
>> enum bar_abcdefj_throw {
>> case genericError // all NSError go here
>> case MyEnumErrorFirstError
>> }
>>
>> Where abcdefj is unique characters.
>>
>>
>> This enum would only be visible through the catch blocks which would act
>> like a switch statement.
>>
>> Speaking of switch statements do they currently support "try" expressions?
>>
>> switch try foo() {
>> case .MyEnumErrorFirstError:
>> // handle error
>> default:
>> // handle NSError and everything else
>> }
>>
>>
>> If I'm not mistaken, `switch try foo()` switches over the return value of
>> foo(); you'd switch over the error in a catch block.
>>
>>
>> The benefit of this approach is that it would be additive. And no source
>> breakage.
>>
>> At the risk of being off topic if there is interest in this I can start a
>> new thread for this.
>>
>> On Tue, Dec 27, 2016 at 9:54 AM Haravikk 
>> wrote:
>>
>> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote:
>> Imho this is no problem:
>> Right now, we basically have "throws Error", and no matter what is
>> actually thrown, we can always catch exhaustive by keeping the statement
>> unspecific.
>>
>>
>> True, but for me it's more about knowing what a method can throw;
>> currently to know that you need to consult documentation which, while fine,
>> isn't the best way to do that when the compiler could know and it's then up
>> to you whether to let it auto-complete for all throwable types, or just be
>> generic for some or all of them (or pass the buck).
>>
>> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>>
>> Imho to much confusion with no real benefit:
>> Shouldn't it be up to the caller to decide which errors need special
>> treatment? The library can't enforce proper handling at all.
>>
>>
>> Partly, but it's really just intended to distinguish things that are
>> genuine runtime errors, versus things that shouldn't have happened, i.e- an
>> illegal argument type error shouldn't occur if you're using a method
>> correctly, so it's more like something you might check as an assertion. I
>> should have been more clear that the main difference is in how fix-its
>> might recommend the errors are handled; specific types would produce catch
>> blocks, but optionals might be grouped into a catch-all at the end (e.g-
>> they're special interest that you 

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

[Tino Heth via swift-evolution]

>> Right now, we basically have "throws Error", and no matter what is actually 
>> thrown, we can always catch exhaustive by keeping the statement unspecific.
> 
> True, but for me it's more about knowing what a method can throw
That's always possible if throw can be annotated with a list of errors; in this 
case, it's up to the library author to be specific

> 
>>> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>> Imho to much confusion with no real benefit:
>> Shouldn't it be up to the caller to decide which errors need special 
>> treatment? The library can't enforce proper handling at all.
> 
> Partly, but it's really just intended to distinguish things that are genuine 
> runtime errors, versus things that shouldn't have happened,
That reminds me to much on the route Java took...

> If the distinctions not significant enough though then the "optional" error 
> types could just be ignored for now, I think the more important ability is 
> the ellipsis indicating "plus other errors" so we can specify either 
> exhaustive lists of error types, or keep them open-ended, in which case the 
> types listed are those that would be placed as catch blocks, with the 
> ellipsis indicating that a catch-all is still required (or throw on the 
> current method).
That are three levels of error whereas one should be enough — and I'm really 
not a fan of ellipsis:
Just require the list to be complete, which can always be achieved by adding 
Error (or Any — imho we should remove the restriction that throwable types have 
to conform to an empty protocol).
In this case, the meaning of the list would be more or less only documentation 
(it's no restriction on what can be thrown), but that would be fine for me, and 
it could be used for autocompletion as well.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[thislooksfun via swift-evolution]

If some form of explicitly typed errors is added, my initial problem goes away. 
The only reason I suggested the move in the first place, is that a combination 
of `throws` and return (-> T) statements makes it look like there is already 
explicitly typed errors, especially to those of us coming from Java.

-thislooksfun (tlf)

> On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution 
>  wrote:
> 
> Moving “throws” or changing it to a prefix “throwing” as was originally 
> suggested are relatively minor, reasonable improvements.
> 
> We do need to consider if it restricts future language evolution (such as 
> potentially listing all of the thrown errors), so that’s why it’s relevant to 
> talk a little bit about that and what are options would be; but I think 
> fundamental, non-backwards compatible changes to how you invoke throwing 
> functions are probably too big to be reasonable.
> 
> - Karl
> 
>> On 27 Dec 2016, at 22:31, Derrick Ho > > wrote:
>> 
>> Right. it should support the normal return type as well as the errors. Here 
>> is my revised suggestion.
>> 
>> func foo() throws -> String {}
>> 
>> switch try foo() {
>> case .returnValue(let value):
>> // do something with value
>> 
>> case .MyEnumErrorFirstError:
>> // handle error
>> 
>> default: 
>> // handle NSError
>> }
>> On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu > > wrote:
>> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution 
>> > wrote:
>> I suppose "throws" could be enhanced to produce a compiletime enum 
>> 
>> func bar() throws {
>> throw NSError()
>> throw MyEnumError.firstError
>> }
>> 
>> Under the hood each expression passed to "throw" could make something like
>> 
>> enum bar_abcdefj_throw {
>> case genericError // all NSError go here
>> case MyEnumErrorFirstError
>> }
>> 
>> Where abcdefj is unique characters.
>> 
>> 
>> This enum would only be visible through the catch blocks which would act 
>> like a switch statement.
>> 
>> Speaking of switch statements do they currently support "try" expressions?
>> 
>> switch try foo() {
>> case .MyEnumErrorFirstError:
>> // handle error
>> default: 
>> // handle NSError and everything else
>> }
>> 
>> If I'm not mistaken, `switch try foo()` switches over the return value of 
>> foo(); you'd switch over the error in a catch block.
>>  
>> The benefit of this approach is that it would be additive. And no source 
>> breakage.
>> 
>> At the risk of being off topic if there is interest in this I can start a 
>> new thread for this.
>> 
>> On Tue, Dec 27, 2016 at 9:54 AM Haravikk > > wrote:
>>> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de > 
>>> wrote:
>>> Imho this is no problem:
>>> Right now, we basically have "throws Error", and no matter what is actually 
>>> thrown, we can always catch exhaustive by keeping the statement unspecific.
>> 
>> True, but for me it's more about knowing what a method can throw; currently 
>> to know that you need to consult documentation which, while fine, isn't the 
>> best way to do that when the compiler could know and it's then up to you 
>> whether to let it auto-complete for all throwable types, or just be generic 
>> for some or all of them (or pass the buck).
>> 
 myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>>> Imho to much confusion with no real benefit:
>>> Shouldn't it be up to the caller to decide which errors need special 
>>> treatment? The library can't enforce proper handling at all.
>> 
>> Partly, but it's really just intended to distinguish things that are genuine 
>> runtime errors, versus things that shouldn't have happened, i.e- an illegal 
>> argument type error shouldn't occur if you're using a method correctly, so 
>> it's more like something you might check as an assertion. I should have been 
>> more clear that the main difference is in how fix-its might recommend the 
>> errors are handled; specific types would produce catch blocks, but optionals 
>> might be grouped into a catch-all at the end (e.g- they're special interest 
>> that you might not be bothered about), but the compiler would still be aware 
>> of them should you decide to add them.
>> 
>> If the distinctions not significant enough though then the "optional" error 
>> types could just be ignored for now, I think the more important ability is 
>> the ellipsis indicating "plus other errors" so we can specify either 
>> exhaustive lists of error types, or keep them open-ended, in which case the 
>> types listed are those that would be placed as catch blocks, with the 
>> ellipsis indicating that a catch-all is still required (or throw on the 
>> current method).
>> 
>>> One thing to note with explicit errors is that we'd basically introduce sum 
>>> types…
>> 

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

[Matt Whiteside via swift-evolution]

> On Dec 27, 2016, at 06:38, Anton Zhilin via swift-evolution 
>  wrote:
> On syntax, I feel like this is the obvious one:
> 
> func convert(_: String) -> Int throws IntegerConversionError
I agree this is the best syntax, though I might add a comma in there for even 
more readability:

func convert(_:String) -> Int, throws IntegerConversionError {
   ...
}


I wonder if this might be problematic in the presence of trailing where clauses 
though, as in this contrived example:

func doSomething(seq:S) -> Int where S.Iterator == T, S.Iterator: 
Hashable, throws SomeKindOfError {
   ...
}

It seems like it should be alright, but perhaps I’m missing something.

-Matt


> Basically, we say that the function can either return an Int, or throw an 
> IntegerConversionError. (Side note: yes, not NumericConversionError, if we 
> want the API to both provide most detailed information when we need it, and 
> express the range of possible errors for a particular function through the 
> type system. However, one can also create hierarchies of error protocols to 
> aid in abstraction—both abstraction and preciseness are important.)
> 
> But can we make a step even further? One can say that the function returns 
> “either Int or an error”. Rust users blame Swift for creating syntax sugar 
> for everything—maybe we can live without it this time? Look at it this way: 
> we already have a deep support for Optional in the language. It’s so 
> seamless, many people don’t even realize they work with Optional. Can we 
> make working with a standard enum Result this simple?
> 
> We can even leave current syntax in place, just T throws E will be a sugar 
> for Result. Methods of error handling described in this manifesto 
>  will be 
> represented, respectively, by Optional, Result, and fatalError, with all of 
> them defined in the standard library—isn’t that reasonable?
> 
> ___
> 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

[Karl via swift-evolution]

Moving “throws” or changing it to a prefix “throwing” as was originally 
suggested are relatively minor, reasonable improvements.

We do need to consider if it restricts future language evolution (such as 
potentially listing all of the thrown errors), so that’s why it’s relevant to 
talk a little bit about that and what are options would be; but I think 
fundamental, non-backwards compatible changes to how you invoke throwing 
functions are probably too big to be reasonable.

- Karl

> On 27 Dec 2016, at 22:31, Derrick Ho  wrote:
> 
> Right. it should support the normal return type as well as the errors. Here 
> is my revised suggestion.
> 
> func foo() throws -> String {}
> 
> switch try foo() {
> case .returnValue(let value):
> // do something with value
> 
> case .MyEnumErrorFirstError:
> // handle error
> 
> default: 
> // handle NSError
> }
> On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu  > wrote:
> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution 
> > wrote:
> I suppose "throws" could be enhanced to produce a compiletime enum 
> 
> func bar() throws {
> throw NSError()
> throw MyEnumError.firstError
> }
> 
> Under the hood each expression passed to "throw" could make something like
> 
> enum bar_abcdefj_throw {
> case genericError // all NSError go here
> case MyEnumErrorFirstError
> }
> 
> Where abcdefj is unique characters.
> 
> 
> This enum would only be visible through the catch blocks which would act like 
> a switch statement.
> 
> Speaking of switch statements do they currently support "try" expressions?
> 
> switch try foo() {
> case .MyEnumErrorFirstError:
> // handle error
> default: 
> // handle NSError and everything else
> }
> 
> If I'm not mistaken, `switch try foo()` switches over the return value of 
> foo(); you'd switch over the error in a catch block.
>  
> The benefit of this approach is that it would be additive. And no source 
> breakage.
> 
> At the risk of being off topic if there is interest in this I can start a new 
> thread for this.
> 
> On Tue, Dec 27, 2016 at 9:54 AM Haravikk  > wrote:
>> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de > wrote:
>> Imho this is no problem:
>> Right now, we basically have "throws Error", and no matter what is actually 
>> thrown, we can always catch exhaustive by keeping the statement unspecific.
> 
> True, but for me it's more about knowing what a method can throw; currently 
> to know that you need to consult documentation which, while fine, isn't the 
> best way to do that when the compiler could know and it's then up to you 
> whether to let it auto-complete for all throwable types, or just be generic 
> for some or all of them (or pass the buck).
> 
>>> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>> Imho to much confusion with no real benefit:
>> Shouldn't it be up to the caller to decide which errors need special 
>> treatment? The library can't enforce proper handling at all.
> 
> Partly, but it's really just intended to distinguish things that are genuine 
> runtime errors, versus things that shouldn't have happened, i.e- an illegal 
> argument type error shouldn't occur if you're using a method correctly, so 
> it's more like something you might check as an assertion. I should have been 
> more clear that the main difference is in how fix-its might recommend the 
> errors are handled; specific types would produce catch blocks, but optionals 
> might be grouped into a catch-all at the end (e.g- they're special interest 
> that you might not be bothered about), but the compiler would still be aware 
> of them should you decide to add them.
> 
> If the distinctions not significant enough though then the "optional" error 
> types could just be ignored for now, I think the more important ability is 
> the ellipsis indicating "plus other errors" so we can specify either 
> exhaustive lists of error types, or keep them open-ended, in which case the 
> types listed are those that would be placed as catch blocks, with the 
> ellipsis indicating that a catch-all is still required (or throw on the 
> current method).
> 
>> One thing to note with explicit errors is that we'd basically introduce sum 
>> types…
> 
> 
> Not necessarily; you could think of explicit errors as being doing something 
> like:
> 
>   enum MyErrorType {
>   case io_error(IOError)
>   case illegal_argument(IllegalArgumentError)
>   case unknown(Error)
>   }
> 
> i.e- boilerplate we could do right now, but would prefer not to, but still 
> allowing it to be handled as an enum.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> 

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

[Derrick Ho via swift-evolution]

Right. it should support the normal return type as well as the errors. Here
is my revised suggestion.

func foo() throws -> String {}

switch try foo() {
case .returnValue(let value):
// do something with value

case .MyEnumErrorFirstError:
// handle error

default:
// handle NSError
}
On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu  wrote:

> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I suppose "throws" could be enhanced to produce a compiletime enum
>
> func bar() throws {
> throw NSError()
> throw MyEnumError.firstError
> }
>
> Under the hood each expression passed to "throw" could make something like
>
> enum bar_abcdefj_throw {
> case genericError // all NSError go here
> case MyEnumErrorFirstError
> }
>
> Where abcdefj is unique characters.
>
>
> This enum would only be visible through the catch blocks which would act
> like a switch statement.
>
> Speaking of switch statements do they currently support "try" expressions?
>
> switch try foo() {
> case .MyEnumErrorFirstError:
> // handle error
> default:
> // handle NSError and everything else
> }
>
>
> If I'm not mistaken, `switch try foo()` switches over the return value of
> foo(); you'd switch over the error in a catch block.
>
>
> The benefit of this approach is that it would be additive. And no source
> breakage.
>
> At the risk of being off topic if there is interest in this I can start a
> new thread for this.
>
> On Tue, Dec 27, 2016 at 9:54 AM Haravikk 
> wrote:
>
> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote:
> Imho this is no problem:
> Right now, we basically have "throws Error", and no matter what is
> actually thrown, we can always catch exhaustive by keeping the statement
> unspecific.
>
>
> True, but for me it's more about knowing what a method can throw;
> currently to know that you need to consult documentation which, while fine,
> isn't the best way to do that when the compiler could know and it's then up
> to you whether to let it auto-complete for all throwable types, or just be
> generic for some or all of them (or pass the buck).
>
> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>
> Imho to much confusion with no real benefit:
> Shouldn't it be up to the caller to decide which errors need special
> treatment? The library can't enforce proper handling at all.
>
>
> Partly, but it's really just intended to distinguish things that are
> genuine runtime errors, versus things that shouldn't have happened, i.e- an
> illegal argument type error shouldn't occur if you're using a method
> correctly, so it's more like something you might check as an assertion. I
> should have been more clear that the main difference is in how fix-its
> might recommend the errors are handled; specific types would produce catch
> blocks, but optionals might be grouped into a catch-all at the end (e.g-
> they're special interest that you might not be bothered about), but the
> compiler would still be aware of them should you decide to add them.
>
> If the distinctions not significant enough though then the "optional"
> error types could just be ignored for now, I think the more important
> ability is the ellipsis indicating "plus other errors" so we can specify
> either exhaustive lists of error types, or keep them open-ended, in which
> case the types listed are those that would be placed as catch blocks, with
> the ellipsis indicating that a catch-all is still required (or throw on the
> current method).
>
> One thing to note with explicit errors is that we'd basically introduce
> sum types…
>
>
> Not necessarily; you could think of explicit errors as being doing
> something like:
>
> enum MyErrorType {
> case io_error(IOError)
> case illegal_argument(IllegalArgumentError)
> case unknown(Error)
> }
>
> i.e- boilerplate we could do right now, but would prefer not to, but still
> allowing it to be handled as an enum.
>
>
> ___
> 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

[Xiaodi Wu via swift-evolution]

On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> I suppose "throws" could be enhanced to produce a compiletime enum
>
> func bar() throws {
> throw NSError()
> throw MyEnumError.firstError
> }
>
> Under the hood each expression passed to "throw" could make something like
>
> enum bar_abcdefj_throw {
> case genericError // all NSError go here
> case MyEnumErrorFirstError
> }
>
> Where abcdefj is unique characters.
>
>
> This enum would only be visible through the catch blocks which would act
> like a switch statement.
>
> Speaking of switch statements do they currently support "try" expressions?
>
> switch try foo() {
> case .MyEnumErrorFirstError:
> // handle error
> default:
> // handle NSError and everything else
> }
>

If I'm not mistaken, `switch try foo()` switches over the return value of
foo(); you'd switch over the error in a catch block.


> The benefit of this approach is that it would be additive. And no source
> breakage.
>
> At the risk of being off topic if there is interest in this I can start a
> new thread for this.
>
> On Tue, Dec 27, 2016 at 9:54 AM Haravikk 
> wrote:
>
>> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote:
>> Imho this is no problem:
>> Right now, we basically have "throws Error", and no matter what is
>> actually thrown, we can always catch exhaustive by keeping the statement
>> unspecific.
>>
>>
>> True, but for me it's more about knowing what a method can throw;
>> currently to know that you need to consult documentation which, while fine,
>> isn't the best way to do that when the compiler could know and it's then up
>> to you whether to let it auto-complete for all throwable types, or just be
>> generic for some or all of them (or pass the buck).
>>
>> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>>
>> Imho to much confusion with no real benefit:
>> Shouldn't it be up to the caller to decide which errors need special
>> treatment? The library can't enforce proper handling at all.
>>
>>
>> Partly, but it's really just intended to distinguish things that are
>> genuine runtime errors, versus things that shouldn't have happened, i.e- an
>> illegal argument type error shouldn't occur if you're using a method
>> correctly, so it's more like something you might check as an assertion. I
>> should have been more clear that the main difference is in how fix-its
>> might recommend the errors are handled; specific types would produce catch
>> blocks, but optionals might be grouped into a catch-all at the end (e.g-
>> they're special interest that you might not be bothered about), but the
>> compiler would still be aware of them should you decide to add them.
>>
>> If the distinctions not significant enough though then the "optional"
>> error types could just be ignored for now, I think the more important
>> ability is the ellipsis indicating "plus other errors" so we can specify
>> either exhaustive lists of error types, or keep them open-ended, in which
>> case the types listed are those that would be placed as catch blocks, with
>> the ellipsis indicating that a catch-all is still required (or throw on the
>> current method).
>>
>> One thing to note with explicit errors is that we'd basically introduce
>> sum types…
>>
>>
>> Not necessarily; you could think of explicit errors as being doing
>> something like:
>>
>> enum MyErrorType {
>> case io_error(IOError)
>> case illegal_argument(IllegalArgumentError)
>> case unknown(Error)
>> }
>>
>> i.e- boilerplate we could do right now, but would prefer not to, but
>> still allowing it to be handled as an enum.
>>
>
> ___
> 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

[Derrick Ho via swift-evolution]

I suppose "throws" could be enhanced to produce a compiletime enum

func bar() throws {
throw NSError()
throw MyEnumError.firstError
}

Under the hood each expression passed to "throw" could make something like

enum bar_abcdefj_throw {
case genericError // all NSError go here
case MyEnumErrorFirstError
}

Where abcdefj is unique characters.


This enum would only be visible through the catch blocks which would act
like a switch statement.

Speaking of switch statements do they currently support "try" expressions?

switch try foo() {
case .MyEnumErrorFirstError:
// handle error
default:
// handle NSError and everything else
}

The benefit of this approach is that it would be additive. And no source
breakage.

At the risk of being off topic if there is interest in this I can start a
new thread for this.
On Tue, Dec 27, 2016 at 9:54 AM Haravikk 
wrote:

> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote:
> Imho this is no problem:
> Right now, we basically have "throws Error", and no matter what is
> actually thrown, we can always catch exhaustive by keeping the statement
> unspecific.
>
>
> True, but for me it's more about knowing what a method can throw;
> currently to know that you need to consult documentation which, while fine,
> isn't the best way to do that when the compiler could know and it's then up
> to you whether to let it auto-complete for all throwable types, or just be
> generic for some or all of them (or pass the buck).
>
> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>
> Imho to much confusion with no real benefit:
> Shouldn't it be up to the caller to decide which errors need special
> treatment? The library can't enforce proper handling at all.
>
>
> Partly, but it's really just intended to distinguish things that are
> genuine runtime errors, versus things that shouldn't have happened, i.e- an
> illegal argument type error shouldn't occur if you're using a method
> correctly, so it's more like something you might check as an assertion. I
> should have been more clear that the main difference is in how fix-its
> might recommend the errors are handled; specific types would produce catch
> blocks, but optionals might be grouped into a catch-all at the end (e.g-
> they're special interest that you might not be bothered about), but the
> compiler would still be aware of them should you decide to add them.
>
> If the distinctions not significant enough though then the "optional"
> error types could just be ignored for now, I think the more important
> ability is the ellipsis indicating "plus other errors" so we can specify
> either exhaustive lists of error types, or keep them open-ended, in which
> case the types listed are those that would be placed as catch blocks, with
> the ellipsis indicating that a catch-all is still required (or throw on the
> current method).
>
> One thing to note with explicit errors is that we'd basically introduce
> sum types…
>
>
> Not necessarily; you could think of explicit errors as being doing
> something like:
>
> enum MyErrorType {
> case io_error(IOError)
> case illegal_argument(IllegalArgumentError)
> case unknown(Error)
> }
>
> i.e- boilerplate we could do right now, but would prefer not to, but still
> allowing it to be handled as an enum.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote:
> Imho this is no problem:
> Right now, we basically have "throws Error", and no matter what is actually 
> thrown, we can always catch exhaustive by keeping the statement unspecific.

True, but for me it's more about knowing what a method can throw; currently to 
know that you need to consult documentation which, while fine, isn't the best 
way to do that when the compiler could know and it's then up to you whether to 
let it auto-complete for all throwable types, or just be generic for some or 
all of them (or pass the buck).

>> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
> Imho to much confusion with no real benefit:
> Shouldn't it be up to the caller to decide which errors need special 
> treatment? The library can't enforce proper handling at all.

Partly, but it's really just intended to distinguish things that are genuine 
runtime errors, versus things that shouldn't have happened, i.e- an illegal 
argument type error shouldn't occur if you're using a method correctly, so it's 
more like something you might check as an assertion. I should have been more 
clear that the main difference is in how fix-its might recommend the errors are 
handled; specific types would produce catch blocks, but optionals might be 
grouped into a catch-all at the end (e.g- they're special interest that you 
might not be bothered about), but the compiler would still be aware of them 
should you decide to add them.

If the distinctions not significant enough though then the "optional" error 
types could just be ignored for now, I think the more important ability is the 
ellipsis indicating "plus other errors" so we can specify either exhaustive 
lists of error types, or keep them open-ended, in which case the types listed 
are those that would be placed as catch blocks, with the ellipsis indicating 
that a catch-all is still required (or throw on the current method).

> One thing to note with explicit errors is that we'd basically introduce sum 
> types…

Not necessarily; you could think of explicit errors as being doing something 
like:

enum MyErrorType {
case io_error(IOError)
case illegal_argument(IllegalArgumentError)
case unknown(Error)
}

i.e- boilerplate we could do right now, but would prefer not to, but still 
allowing it to be handled as an enum.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

Imho the concept of checked exceptions was ok, but the important information is 
the category of error - in how to respond and how to report to the user. Use of 
a type system encourages an ontology of errors by subsystem and not by 
appropriate programmatic response. You could have appropriate user interaction 
or recovery in response to "specified file was not found", but not to "some IO 
error has occurred". 

Eventually this impedance mismatch grew to having modules (packages) in Java 
"wrap" all errors in a module-specific error. Now it wasn't even "some IO error 
occurred" but "some error occurred in the XML module"

This is the danger of checked exceptions - that abstracting away the error 
makes it harder to reason about dealing with the error, so you just delegate 
further up the call stack, abstracting further as you go

-DW


Sent with my Thumbs

> On Dec 27, 2016, at 6:21 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> You need to list all exception types that can be thrown. And when you call 
> another throwing method without handling the exception, it needs to be listed 
> as well. Which means that you can end up with a method that has a list of a 
> dozen of exception names that can be thrown.
> 
>> On Dec 27, 2016, at 11:56 AM, Derrick Ho via swift-evolution 
>>  wrote:
>> 
>> Daniel Leping, I am unfamiliar with java. Do you have any resources that 
>> describe the nightmare in detail?
>> On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote:
 -1 for specifying errors for throws. Please don't. Proven by practice in 
 java it's a nightmare.
>>> 
>>> In Java, this topic is really interesting:
>>> It sounds like a great idea, but in real-life situations, afaics everyone 
>>> hates checked exceptions.
>>> 
>>> But Swift isn't Java, and our error handling is different from most 
>>> established languages, so imho we shouldn't base that decision on 
>>> experiences from other models only:
>>> I don't see downsides, because you already need "try" for everything that 
>>> can throw, and afaics, it would be easy to ignore the information that only 
>>> a set of exceptions can happen in a given context.
>>> 
>>> So, imho before there is a decision wether "throws" should be moved, the 
>>> possibility to annotate it with a fixed set of error types should be either 
>>> abandoned or incorporated. 
>> ___
>> 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] Move placement of 'throws' statement

[Xiaodi Wu via swift-evolution]

Not in a position to search for this myself at the moment, but for those
unaware, somewhere on this list archive are posts from the core team
describing the rationale for using throws instead of Result, and for having
untyped throws by default with the door open for typed throws in the future
as an _option_. Those threads were long and the points raised were
thoughtful, and it's unlikely that replaying the conversation again will
surface new points :)


On Tue, Dec 27, 2016 at 11:48 David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> Although I have only partially vetted it myself, this came up for a google
> search: http://wiki.c2.com/?JavaExceptionsAreParticularlyEvil
>
> -DW
>
> Sent with my Thumbs
>
> On Dec 27, 2016, at 5:56 AM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Daniel Leping, I am unfamiliar with java. Do you have any resources that
> describe the nightmare in detail?
> On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote:
>
> -1 for specifying errors for throws. Please don't. Proven by practice in
> java it's a nightmare.
>
> In Java, this topic is really interesting:
> It sounds like a great idea, but in real-life situations, afaics everyone
> hates checked exceptions.
>
> But Swift isn't Java, and our error handling is different from most
> established languages, so imho we shouldn't base that decision on
> experiences from other models only:
> I don't see downsides, because you already need "try" for everything that
> can throw, and afaics, it would be easy to ignore the information that only
> a set of exceptions can happen in a given context.
>
> So, imho before there is a decision wether "throws" should be moved, the
> possibility to annotate it with a fixed set of error types should be either
> abandoned or incorporated.
>
> ___
> 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] Move placement of 'throws' statement

[David Waite via swift-evolution]

Although I have only partially vetted it myself, this came up for a google 
search: http://wiki.c2.com/?JavaExceptionsAreParticularlyEvil

-DW

Sent with my Thumbs

> On Dec 27, 2016, at 5:56 AM, Derrick Ho via swift-evolution 
>  wrote:
> 
> Daniel Leping, I am unfamiliar with java. Do you have any resources that 
> describe the nightmare in detail?
> On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote:
>>> -1 for specifying errors for throws. Please don't. Proven by practice in 
>>> java it's a nightmare.
>> 
>> In Java, this topic is really interesting:
>> It sounds like a great idea, but in real-life situations, afaics everyone 
>> hates checked exceptions.
>> 
>> But Swift isn't Java, and our error handling is different from most 
>> established languages, so imho we shouldn't base that decision on 
>> experiences from other models only:
>> I don't see downsides, because you already need "try" for everything that 
>> can throw, and afaics, it would be easy to ignore the information that only 
>> a set of exceptions can happen in a given context.
>> 
>> So, imho before there is a decision wether "throws" should be moved, the 
>> possibility to annotate it with a fixed set of error types should be either 
>> abandoned or incorporated. 
> ___
> 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

[Anton Zhilin via swift-evolution]

This proposal should be reviewed as a part of “typed throws” proposal, with
the original PR  prepared
by David Owens.

Typed throws won’t change anything about how many types can be thrown. Only
one type/protocol will be specified in the function type. You will still be
able to specify throws Error by default, but in the cases, where API
authors put some effort in their error handling, these APIs will be
self-documented and undoubtably easier to work with. In many cases, one can
at least specify some existential error type, which will be
domain-specific, and still better than what we have now.

I feel like Swift, together with Rust, can change current overall mess in
error handling across many programming languages by providing not only
syntax, but also semantics and guidelines. Swift errors, unlike exceptions,
require dealing with them immediately. If one cannot deal with the error,
but error details can be useful on hier levels of abstraction (for actually
solving the problem, not logging), he still should put some work into
wrapping the error, leaving only important details and preparing them for
most conventient access.

On syntax, I feel like this is the obvious one:

func convert(_: String) -> Int throws IntegerConversionError

Basically, we say that the function can either return an Int, or throw an
IntegerConversionError. (Side note: yes, not NumericConversionError, if we
want the API to both provide most detailed information when we need it, and
express the range of possible errors for a particular function through the
type system. However, one can also create hierarchies of error protocols to
aid in abstraction—both abstraction and preciseness are important.)

But can we make a step even further? One can say that the function returns
“either Int or an error”. Rust users blame Swift for creating syntax sugar
for everything—maybe we can live without it this time? Look at it this way:
we already have a deep support for Optional in the language. It’s so
seamless, many people don’t even *realize* they work with Optional. Can
we make working with a standard enum Result this simple?

We can even leave current syntax in place, just T throws E will be a sugar
for Result. Methods of error handling described in this manifesto
 will be
represented, respectively, by Optional, Result, and fatalError, with all of
them defined in the standard library—isn’t that reasonable?
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> I think the problem really comes down to the inflexibility of it; if you 
> specify X, Y, and Z as throwable types, then all code calling that method 
> must handle those types in some way.
Imho this is no problem:
Right now, we basically have "throws Error", and no matter what is actually 
thrown, we can always catch exhaustive by keeping the statement unspecific.

>   func myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? 
> { … }
Imho to much confusion with no real benefit:
Shouldn't it be up to the caller to decide which errors need special treatment? 
The library can't enforce proper handling at all.

One thing to note with explicit errors is that we'd basically introduce sum 
types… I think this wouldn't be bad at all, but afaics, core strongly favours 
enums (and I fear it's to late to really discuss pros and cons of both 
approaches)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Georgios Moschovitis via swift-evolution]

Indeed,
func baz() throws -> String
is confusing. I do prefer these two alternatives:
// Move `throws` to the end
func baz() -> String throws

// Change it to a prefix modifier (like `mutating`)
throwing func baz() -> String
I think I prefer the first one (throws at the very end).

I wouldn’t mind this source-breaking change.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

I have rarely caught up into these situations - if I end up with multiple types 
of error, I generally create a wrapper error type. For example, my networking 
code includes a NetworkError type which encompasses all the errors that can 
happen within Foundation or my own code.

Could we not then in this way limit it to one declared type, to simplify the 
system? And then if you really don’t want to document type type, you either put:
> func myMethod(args:[String:Any]) throws Error { … }

Or:
> func myMethod(args:[String:Any]) throws { … }

As we currently do anyway?

How can giving more information at least optionally for safer and more correct 
code be a bad thing?

- Rod


> On 27 Dec 2016, at 11:21 pm, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution 
>> > wrote:
>> 
>> Daniel Leping, I am unfamiliar with java. Do you have any resources that 
>> describe the nightmare in detail?
> 
> I think the problem really comes down to the inflexibility of it; if you 
> specify X, Y, and Z as throwable types, then all code calling that method 
> must handle those types in some way.
> 
> Thing is, I wonder if this would be as much of a problem for Swift? We have 
> the try! and try? variations which make it very easy to ignore/simplify error 
> handling if we don't expect any to occur at all, or it doesn't matter if they 
> do, and we have the same basic means of handling generic unknown (or 
> unhandled) error types, plus throws and rethrows.
> 
> Part of the problem is that Java only ever treats the specified types as 
> mandatory (you *must* handle them somehow); I think a more elegant solution 
> could be if we could somehow mark them as optional, for example:
> 
>   func myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? 
> { … }
> 
> Here myMethod can throw two error types, IOError and IllegalArgumentError, 
> but while the first *must* be handled somehow, the latter is only optional as 
> a well formed args dictionary cannot possibly produce an error, i.e- it's an 
> error you might only want to check if the args dictionary was built 
> dynamically.
> 
> Basically in this case not handling an IOError would be an error, while not 
> handling IllegalArgumentError would be a warning (with some way to suppress 
> it). This means that APIs could even add new error types so long as they are 
> optional, though it's not advisable.
> 
> In addition to this we might introduce some mechanism for specifying *some* 
> of a method's error types, for example:
> 
>   func myMethod() throws IOError… { … }
> 
> Here myMethod specifies an explicit IOError that *must* be handled, but also 
> indicates that there are other, optional, types that don't need to be handled 
> explicitly. The idea here is that you specify only the most important types, 
> but can still indicate that there are other possible types (but maybe they're 
> rare, or only occur in very unusual circumstances described in 
> documentation), or you just want to leave the definition open-ended.
> 
> So yeah; personally I'm a supporter of being *able* to specify thrown types, 
> but do think it needs to be more flexible in what and how we specify them, to 
> avoid falling into the same pitfalls as Java. I definitely think that being 
> able to specify types that *must* be handled is useful, though we'd need to 
> make clear best practice (i.e- mandatory type handling should be reserved for 
> more serious errors in most cases).
> 
> Other things to consider are wether explicit thrown types could be marked as 
> handle immediately (i.e- throwing the error up the chain is a warning), and 
> whether non-explicit throws/rethrows could be automatically computed. For 
> example, if I have a method that has a plain throws, and handles three 
> methods, throwing errors of A, B? and C… respectively, with the first called 
> via try?, then my method's throwable types are B?, C…
> 
> 
> To conclude; while I like Swift's error handling as-is it's mostly because I 
> tend to use try! and try?, but when it comes to an actual try/catch I do like 
> Java's compiler supported enforcement making sure that I'm aware of which 
> types I'm supposed to do something with.
> ___
> 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

[Haravikk via swift-evolution]

> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution 
>  wrote:
> 
> Daniel Leping, I am unfamiliar with java. Do you have any resources that 
> describe the nightmare in detail?

I think the problem really comes down to the inflexibility of it; if you 
specify X, Y, and Z as throwable types, then all code calling that method must 
handle those types in some way.

Thing is, I wonder if this would be as much of a problem for Swift? We have the 
try! and try? variations which make it very easy to ignore/simplify error 
handling if we don't expect any to occur at all, or it doesn't matter if they 
do, and we have the same basic means of handling generic unknown (or unhandled) 
error types, plus throws and rethrows.

Part of the problem is that Java only ever treats the specified types as 
mandatory (you *must* handle them somehow); I think a more elegant solution 
could be if we could somehow mark them as optional, for example:

func myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? 
{ … }

Here myMethod can throw two error types, IOError and IllegalArgumentError, but 
while the first *must* be handled somehow, the latter is only optional as a 
well formed args dictionary cannot possibly produce an error, i.e- it's an 
error you might only want to check if the args dictionary was built dynamically.

Basically in this case not handling an IOError would be an error, while not 
handling IllegalArgumentError would be a warning (with some way to suppress 
it). This means that APIs could even add new error types so long as they are 
optional, though it's not advisable.

In addition to this we might introduce some mechanism for specifying *some* of 
a method's error types, for example:

func myMethod() throws IOError… { … }

Here myMethod specifies an explicit IOError that *must* be handled, but also 
indicates that there are other, optional, types that don't need to be handled 
explicitly. The idea here is that you specify only the most important types, 
but can still indicate that there are other possible types (but maybe they're 
rare, or only occur in very unusual circumstances described in documentation), 
or you just want to leave the definition open-ended.

So yeah; personally I'm a supporter of being *able* to specify thrown types, 
but do think it needs to be more flexible in what and how we specify them, to 
avoid falling into the same pitfalls as Java. I definitely think that being 
able to specify types that *must* be handled is useful, though we'd need to 
make clear best practice (i.e- mandatory type handling should be reserved for 
more serious errors in most cases).

Other things to consider are wether explicit thrown types could be marked as 
handle immediately (i.e- throwing the error up the chain is a warning), and 
whether non-explicit throws/rethrows could be automatically computed. For 
example, if I have a method that has a plain throws, and handles three methods, 
throwing errors of A, B? and C… respectively, with the first called via try?, 
then my method's throwable types are B?, C…


To conclude; while I like Swift's error handling as-is it's mostly because I 
tend to use try! and try?, but when it comes to an actual try/catch I do like 
Java's compiler supported enforcement making sure that I'm aware of which types 
I'm supposed to do something with.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

I think the clear middle ground is an approach where you *can* document the 
type, but let it not be required.

Additionally, we can treat that at the calling end as a built time assurance of 
the type for error that is passed into the standard “catch { }”, and the 
compiler can also check that all of your catch let … casts actually are 
possible, and so catching becomes like a switch. I don’t see this as changing 
anything we currently do, except giving us the option to declare more than the 
current: Currently “throws” means “throws Error”. Why can’t we allow more 
information to be passed?

I think the compiler needs to remove the overhead of specified error types. 
Just like Java may be seen as a nightmare, it’s clear here that the fact we can 
specify different error types means *guessing* the error types is just as much 
of a nightmare. It makes sense, even if only for documentation reasons, to 
allow a declarable way of denoting your error type, and feeding that 
information to the compiler for built time checks.

> On 27 Dec 2016, at 10:20 pm, Charlie Monroe via swift-evolution 
>  wrote:
> 
> For me, handling Swift errors is a nightmare. You have no idea what to expect 
> to be thrown. Some developers use NSError for use with Cocoa/UIKit (usually 
> errors meant for user interaction), but some use enums that even can have a 
> payload (extra info about the error). And you need to rely on the 
> documentation, which can be nonexistent or inaccurate. Not to mention, within 
> that call, another throwing method can be called, which may not be mentioned 
> in the docs, which may result in other error types being thrown.
> 
> And mainly, when the docs mention that only MyErrorEnum can be thrown, you 
> have a catch branch for MyErrorEnum, but the compiler will complain that not 
> all cases are handled. So you either need to catch a generic Error and 
> force-cast it, or add another catch _ branch calling fatalError - unhandled 
> error. Either way, not a pretty solution.
> 
> While I always hated Java's approach of listing all exceptions that can be 
> thrown, I equally hate current state of Swift, where you have no idea what's 
> comming at ya. In ObjC, you knew it was NSError. Yes, you still can bridge 
> any Error to NSError, but you loose a lot of potentially useful information 
> about the error.
> 
> 
>> On Dec 27, 2016, at 10:57 AM, Daniel Leping via swift-evolution 
>> > wrote:
>> 
>> -1 for specifying errors for throws. Please don't. Proven by practice in 
>> java it's a nightmare.
>> 
>> On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution 
>> > wrote:
>> I like the idea of "throw" having information about what might be thrown.
>> 
>> Maybe you have an enum of errors that may be thrown. How would the 
>> programmer know what might get thrown if they don't know the implementation 
>> details?
>> 
>> While adding the throwing info in the comments is good, we might be better 
>> off adding an attribute 
>> 
>> @throws(Error_Enum, Specific_error, ...)
>> 
>> Where the stuff in parenthesis is a comma separated list of possible errors. 
>> Maybe it's all the cases in enum are possible or maybe only a specific few 
>> are used...
>> 
>> Then we can do something like this
>> 
>> @throws(MyErrorEnum)
>> func foo() {
>> 
>> throw MyErrorEnum.firstError
>> 
>> }
>> 
>> With this info we can properly catch all error cases
>> 
>> do {
>> try foo()
>> } catch MyErrorEnum.firstError {
>> 
>> } catch {
>> }
>> 
>> As for blocks that throw we could probably add it in the same place where 
>> @escaping is.
>> On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution 
>> > wrote:
>> Maybe we can let the compiler use documentation comments for type-checking. 
>> Currently you can do:
>> 
>> /// does something
>> ///
>> /// - returns: Something cool
>> ///
>> /// - throws:
>> ///- `MyError.Something` if a certain thing happens
>> ///- `POSIXError` if something goes horribly wrong
>> ///
>> func doSomething() throws -> Int
>> 
>> I would prefer if we found some way to integrate that stuff in to the 
>> compiler. I mean, you would probably want to document why the errors get 
>> thrown anyway, and it’s better than clobbering up the function signature.
>> 
>> Maybe it seems weird to have the compiler look inside comments (especially 
>> if the set of thrown errors becomes a resilience-breaking part of the 
>> function), but why not? Swift’s documentation comments are just another 
>> source of structured data, and the compiler already understands them at a 
>> superficial level.
>> 
>> Just saying, there are options.
>> 
>>> On 27 Dec 2016, at 07:55, Tony Allevato >> > wrote:
>>> 
>>> One thing to keep in mind is that, if I 

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

[Charlie Monroe via swift-evolution]

You need to list all exception types that can be thrown. And when you call 
another throwing method without handling the exception, it needs to be listed 
as well. Which means that you can end up with a method that has a list of a 
dozen of exception names that can be thrown.

> On Dec 27, 2016, at 11:56 AM, Derrick Ho via swift-evolution 
>  wrote:
> 
> Daniel Leping, I am unfamiliar with java. Do you have any resources that 
> describe the nightmare in detail?
> On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de > 
> wrote:
>> -1 for specifying errors for throws. Please don't. Proven by practice in 
>> java it's a nightmare.
> 
> In Java, this topic is really interesting:
> It sounds like a great idea, but in real-life situations, afaics everyone 
> hates checked exceptions.
> 
> But Swift isn't Java, and our error handling is different from most 
> established languages, so imho we shouldn't base that decision on experiences 
> from other models only:
> I don't see downsides, because you already need "try" for everything that can 
> throw, and afaics, it would be easy to ignore the information that only a set 
> of exceptions can happen in a given context.
> 
> So, imho before there is a decision wether "throws" should be moved, the 
> possibility to annotate it with a fixed set of error types should be either 
> abandoned or incorporated. 
> ___
> 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

[Charlie Monroe via swift-evolution]

For me, handling Swift errors is a nightmare. You have no idea what to expect 
to be thrown. Some developers use NSError for use with Cocoa/UIKit (usually 
errors meant for user interaction), but some use enums that even can have a 
payload (extra info about the error). And you need to rely on the 
documentation, which can be nonexistent or inaccurate. Not to mention, within 
that call, another throwing method can be called, which may not be mentioned in 
the docs, which may result in other error types being thrown.

And mainly, when the docs mention that only MyErrorEnum can be thrown, you have 
a catch branch for MyErrorEnum, but the compiler will complain that not all 
cases are handled. So you either need to catch a generic Error and force-cast 
it, or add another catch _ branch calling fatalError - unhandled error. Either 
way, not a pretty solution.

While I always hated Java's approach of listing all exceptions that can be 
thrown, I equally hate current state of Swift, where you have no idea what's 
comming at ya. In ObjC, you knew it was NSError. Yes, you still can bridge any 
Error to NSError, but you loose a lot of potentially useful information about 
the error.


> On Dec 27, 2016, at 10:57 AM, Daniel Leping via swift-evolution 
>  wrote:
> 
> -1 for specifying errors for throws. Please don't. Proven by practice in java 
> it's a nightmare.
> 
> On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution 
> > wrote:
> I like the idea of "throw" having information about what might be thrown.
> 
> Maybe you have an enum of errors that may be thrown. How would the programmer 
> know what might get thrown if they don't know the implementation details?
> 
> While adding the throwing info in the comments is good, we might be better 
> off adding an attribute 
> 
> @throws(Error_Enum, Specific_error, ...)
> 
> Where the stuff in parenthesis is a comma separated list of possible errors. 
> Maybe it's all the cases in enum are possible or maybe only a specific few 
> are used...
> 
> Then we can do something like this
> 
> @throws(MyErrorEnum)
> func foo() {
> 
> throw MyErrorEnum.firstError
> 
> }
> 
> With this info we can properly catch all error cases
> 
> do {
> try foo()
> } catch MyErrorEnum.firstError {
> 
> } catch {
> }
> 
> As for blocks that throw we could probably add it in the same place where 
> @escaping is.
> On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution 
> > wrote:
> Maybe we can let the compiler use documentation comments for type-checking. 
> Currently you can do:
> 
> /// does something
> ///
> /// - returns: Something cool
> ///
> /// - throws:
> ///- `MyError.Something` if a certain thing happens
> ///- `POSIXError` if something goes horribly wrong
> ///
> func doSomething() throws -> Int
> 
> I would prefer if we found some way to integrate that stuff in to the 
> compiler. I mean, you would probably want to document why the errors get 
> thrown anyway, and it’s better than clobbering up the function signature.
> 
> Maybe it seems weird to have the compiler look inside comments (especially if 
> the set of thrown errors becomes a resilience-breaking part of the function), 
> but why not? Swift’s documentation comments are just another source of 
> structured data, and the compiler already understands them at a superficial 
> level.
> 
> Just saying, there are options.
> 
>> On 27 Dec 2016, at 07:55, Tony Allevato > > wrote:
>> 
>> One thing to keep in mind is that, if I recall correctly, some members of 
>> the core team have expressed a desire to enhance `throws` by letting users 
>> list the specific error types that a function can throw. If that is 
>> something that might happen in the future, moving the `throws/throwing` to 
>> the front would add a significant amount of noise before the function name.
>> 
>> 
>> On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution 
>> > wrote:
>> I agree that this could do with revision. It looks particularly ugly when 
>> you’re dealing with throwing closures.
>> 
>> Recently I had a signature like:
>> 
>> public func scan(length: File.ByteOffset.Stride?,
>>  by frameSize: File.ByteOffset.Stride,
>>  with handler: (_ range: Range, _ data: 
>> UnsafeRawBufferPointer) throws -> Bool) throws -> File.ByteOffset.Stride
>> 
>> It can get difficult to parse the signature towards the end. Marking the 
>> handler and function as throwing closer to the beginning would make it more 
>> readable IMO. One thing it allows me to do more easily is to remove the 
>> spaces around the arrow for the closure parameter (just a little thing which 
>> I find helps me read the trailing closure/return type more quickly).
>> 

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

[Derrick Ho via swift-evolution]

Daniel Leping, I am unfamiliar with java. Do you have any resources that
describe the nightmare in detail?
On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote:

> -1 for specifying errors for throws. Please don't. Proven by practice in
> java it's a nightmare.
>
> In Java, this topic is really interesting:
> It sounds like a great idea, but in real-life situations, afaics everyone
> hates checked exceptions.
>
> But Swift isn't Java, and our error handling is different from most
> established languages, so imho we shouldn't base that decision on
> experiences from other models only:
> I don't see downsides, because you already need "try" for everything that
> can throw, and afaics, it would be easy to ignore the information that only
> a set of exceptions can happen in a given context.
>
> So, imho before there is a decision wether "throws" should be moved, the
> possibility to annotate it with a fixed set of error types should be either
> abandoned or incorporated.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> -1 for specifying errors for throws. Please don't. Proven by practice in java 
> it's a nightmare.

In Java, this topic is really interesting:
It sounds like a great idea, but in real-life situations, afaics everyone hates 
checked exceptions.

But Swift isn't Java, and our error handling is different from most established 
languages, so imho we shouldn't base that decision on experiences from other 
models only:
I don't see downsides, because you already need "try" for everything that can 
throw, and afaics, it would be easy to ignore the information that only a set 
of exceptions can happen in a given context.

So, imho before there is a decision wether "throws" should be moved, the 
possibility to annotate it with a fixed set of error types should be either 
abandoned or incorporated. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Leping via swift-evolution]

-1 for specifying errors for throws. Please don't. Proven by practice in
java it's a nightmare.

On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

> I like the idea of "throw" having information about what might be thrown.
>
> Maybe you have an enum of errors that may be thrown. How would the
> programmer know what might get thrown if they don't know the implementation
> details?
>
> While adding the throwing info in the comments is good, we might be better
> off adding an attribute
>
> @throws(Error_Enum, Specific_error, ...)
>
> Where the stuff in parenthesis is a comma separated list of possible
> errors. Maybe it's all the cases in enum are possible or maybe only a
> specific few are used...
>
> Then we can do something like this
>
> @throws(MyErrorEnum)
> func foo() {
> 
> throw MyErrorEnum.firstError
> 
> }
>
> With this info we can properly catch all error cases
>
> do {
> try foo()
> } catch MyErrorEnum.firstError {
>
> } catch {
> }
>
> As for blocks that throw we could probably add it in the same place where
> @escaping is.
> On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Maybe we can let the compiler use documentation comments for
> type-checking. Currently you can do:
>
> /// does something
> ///
> /// - returns: Something cool
> ///
> /// - throws:
> ///- `MyError.Something` if a certain thing happens
> ///- `POSIXError` if something goes horribly wrong
> ///
> func doSomething() throws -> Int
>
> I would prefer if we found some way to integrate that stuff in to the
> compiler. I mean, you would probably want to document why the errors get
> thrown anyway, and it’s better than clobbering up the function signature.
>
> Maybe it seems weird to have the compiler look inside comments (especially
> if the set of thrown errors becomes a resilience-breaking part of the
> function), but why not? Swift’s documentation comments are just another
> source of structured data, and the compiler already understands them at a
> superficial level.
>
> Just saying, there are options.
>
> On 27 Dec 2016, at 07:55, Tony Allevato  wrote:
>
> One thing to keep in mind is that, if I recall correctly, some members of
> the core team have expressed a desire to enhance `throws` by letting users
> list the specific error types that a function can throw. If that is
> something that might happen in the future, moving the `throws/throwing` to
> the front would add a significant amount of noise before the function name.
>
>
> On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree that this could do with revision. It looks particularly ugly when
> you’re dealing with throwing closures.
>
> Recently I had a signature like:
>
> public func scan(length: File.ByteOffset.Stride?,
>  by frameSize: File.ByteOffset.Stride,
>  with handler:
> (_ range: Range, _ data: UnsafeRawBufferPointer) throws -> 
> Bool) throws -> File.ByteOffset.Stride
>
> It can get difficult to parse the signature towards the end. Marking the
> handler and function as throwing closer to the beginning would make it more
> readable IMO. One thing it allows me to do more easily is to remove the
> spaces around the arrow for the closure parameter (just a little thing
> which I find helps me read the trailing closure/return type more quickly).
>
> public throwing func scan(length: File.ByteOffset.Stride?,
>  by
> frameSize: File.ByteOffset.Stride,
>  with handler: throwing
> (_ range: Range, _ data: UnsafeRawBufferPointer)->Bool)
> -> File.ByteOffset.Stride
>
> - Karl
>
> On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution <
> swift-evolution@swift.org> 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
>
>

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

[Derrick Ho via swift-evolution]

I like the idea of "throw" having information about what might be thrown.

Maybe you have an enum of errors that may be thrown. How would the
programmer know what might get thrown if they don't know the implementation
details?

While adding the throwing info in the comments is good, we might be better
off adding an attribute

@throws(Error_Enum, Specific_error, ...)

Where the stuff in parenthesis is a comma separated list of possible
errors. Maybe it's all the cases in enum are possible or maybe only a
specific few are used...

Then we can do something like this

@throws(MyErrorEnum)
func foo() {

throw MyErrorEnum.firstError

}

With this info we can properly catch all error cases

do {
try foo()
} catch MyErrorEnum.firstError {

} catch {
}

As for blocks that throw we could probably add it in the same place where
@escaping is.
On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> Maybe we can let the compiler use documentation comments for
> type-checking. Currently you can do:
>
> /// does something
> ///
> /// - returns: Something cool
> ///
> /// - throws:
> ///- `MyError.Something` if a certain thing happens
> ///- `POSIXError` if something goes horribly wrong
> ///
> func doSomething() throws -> Int
>
> I would prefer if we found some way to integrate that stuff in to the
> compiler. I mean, you would probably want to document why the errors get
> thrown anyway, and it’s better than clobbering up the function signature.
>
> Maybe it seems weird to have the compiler look inside comments (especially
> if the set of thrown errors becomes a resilience-breaking part of the
> function), but why not? Swift’s documentation comments are just another
> source of structured data, and the compiler already understands them at a
> superficial level.
>
> Just saying, there are options.
>
> On 27 Dec 2016, at 07:55, Tony Allevato  wrote:
>
> One thing to keep in mind is that, if I recall correctly, some members of
> the core team have expressed a desire to enhance `throws` by letting users
> list the specific error types that a function can throw. If that is
> something that might happen in the future, moving the `throws/throwing` to
> the front would add a significant amount of noise before the function name.
>
>
> On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree that this could do with revision. It looks particularly ugly when
> you’re dealing with throwing closures.
>
> Recently I had a signature like:
>
> public func scan(length: File.ByteOffset.Stride?,
>  by frameSize: File.ByteOffset.Stride,
>  with handler:
> (_ range: Range, _ data: UnsafeRawBufferPointer) throws -> 
> Bool) throws -> File.ByteOffset.Stride
>
> It can get difficult to parse the signature towards the end. Marking the
> handler and function as throwing closer to the beginning would make it more
> readable IMO. One thing it allows me to do more easily is to remove the
> spaces around the arrow for the closure parameter (just a little thing
> which I find helps me read the trailing closure/return type more quickly).
>
> public throwing func scan(length: File.ByteOffset.Stride?,
>  by
> frameSize: File.ByteOffset.Stride,
>  with handler: throwing
> (_ range: Range, _ data: UnsafeRawBufferPointer)->Bool)
> -> File.ByteOffset.Stride
>
> - Karl
>
> On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution <
> swift-evolution@swift.org> 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
>
> // 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 

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

[Karl via swift-evolution]

Maybe we can let the compiler use documentation comments for type-checking. 
Currently you can do:

/// does something
///
/// - returns: Something cool
///
/// - throws:
///- `MyError.Something` if a certain thing happens
///- `POSIXError` if something goes horribly wrong
///
func doSomething() throws -> Int

I would prefer if we found some way to integrate that stuff in to the compiler. 
I mean, you would probably want to document why the errors get thrown anyway, 
and it’s better than clobbering up the function signature.

Maybe it seems weird to have the compiler look inside comments (especially if 
the set of thrown errors becomes a resilience-breaking part of the function), 
but why not? Swift’s documentation comments are just another source of 
structured data, and the compiler already understands them at a superficial 
level.

Just saying, there are options.

> On 27 Dec 2016, at 07:55, Tony Allevato  wrote:
> 
> One thing to keep in mind is that, if I recall correctly, some members of the 
> core team have expressed a desire to enhance `throws` by letting users list 
> the specific error types that a function can throw. If that is something that 
> might happen in the future, moving the `throws/throwing` to the front would 
> add a significant amount of noise before the function name.
> 
> 
> On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution 
> > wrote:
> I agree that this could do with revision. It looks particularly ugly when 
> you’re dealing with throwing closures.
> 
> Recently I had a signature like:
> 
> public func scan(length: File.ByteOffset.Stride?,
>  by frameSize: File.ByteOffset.Stride,
>  with handler: (_ range: Range, _ data: 
> UnsafeRawBufferPointer) throws -> Bool) throws -> File.ByteOffset.Stride
> 
> It can get difficult to parse the signature towards the end. Marking the 
> handler and function as throwing closer to the beginning would make it more 
> readable IMO. One thing it allows me to do more easily is to remove the 
> spaces around the arrow for the closure parameter (just a little thing which 
> I find helps me read the trailing closure/return type more quickly).
> 
> public throwing func scan(length: File.ByteOffset.Stride?,
>  by frameSize: File.ByteOffset.Stride,
>  with handler: throwing (_ range: 
> Range, _ data: UnsafeRawBufferPointer)->Bool) -> 
> File.ByteOffset.Stride
> 
> - Karl
>> On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution 
>> > 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
>> 
>> // 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 
>> 
> ___
> 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

[Tony Allevato via swift-evolution]

One thing to keep in mind is that, if I recall correctly, some members of
the core team have expressed a desire to enhance `throws` by letting users
list the specific error types that a function can throw. If that is
something that might happen in the future, moving the `throws/throwing` to
the front would add a significant amount of noise before the function name.


On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree that this could do with revision. It looks particularly ugly when
> you’re dealing with throwing closures.
>
> Recently I had a signature like:
>
> public func scan(length: File.ByteOffset.Stride?,
>  by frameSize: File.ByteOffset.Stride,
>  with handler:
> (_ range: Range, _ data: UnsafeRawBufferPointer) throws -> 
> Bool) throws -> File.ByteOffset.Stride
>
> It can get difficult to parse the signature towards the end. Marking the
> handler and function as throwing closer to the beginning would make it more
> readable IMO. One thing it allows me to do more easily is to remove the
> spaces around the arrow for the closure parameter (just a little thing
> which I find helps me read the trailing closure/return type more quickly).
>
> public throwing func scan(length: File.ByteOffset.Stride?,
>  by
> frameSize: File.ByteOffset.Stride,
>  with handler: throwing
> (_ range: Range, _ data: UnsafeRawBufferPointer)->Bool)
> -> File.ByteOffset.Stride
>
> - Karl
>
> On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution <
> swift-evolution@swift.org> 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
>
> // 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
>
> ___
> 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

[Karl via swift-evolution]

I agree that this could do with revision. It looks particularly ugly when 
you’re dealing with throwing closures.

Recently I had a signature like:

public func scan(length: File.ByteOffset.Stride?,
 by frameSize: File.ByteOffset.Stride,
 with handler: (_ range: Range, _ data: 
UnsafeRawBufferPointer) throws -> Bool) throws -> File.ByteOffset.Stride

It can get difficult to parse the signature towards the end. Marking the 
handler and function as throwing closer to the beginning would make it more 
readable IMO. One thing it allows me to do more easily is to remove the spaces 
around the arrow for the closure parameter (just a little thing which I find 
helps me read the trailing closure/return type more quickly).

public throwing func scan(length: File.ByteOffset.Stride?,
 by frameSize: File.ByteOffset.Stride,
 with handler: throwing (_ range: 
Range, _ data: UnsafeRawBufferPointer)->Bool) -> 
File.ByteOffset.Stride

- Karl

> On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution 
>  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
> 
> // 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

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

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

[Derrick Ho via swift-evolution]

I like to imagine "throws -> returnType" like a special tuple

let t = (e: NSError?, r: returnType)

Where "try" is a special function that accepts a tuple argument; a success
closure; and one or more error blocks

func try(
_ t: (e: NSError?, r: returnType)
, do: ()->()
, catch: ((Error)->())...
)

So you could think of it as modifying the return type.
On Mon, Dec 26, 2016 at 8:19 PM Daniel Leping via swift-evolution <
swift-evolution@swift.org> wrote:

> IMO, considering "throws" is a modifier of function/method and determines
> how the function can be called (another good example is mutating) the
> logical approach would be to make things consistent and move everything
> either to the beginning or to the end of declaration.
>
> As long as "throws" is the only modifier at the end it's very logical to
> move it to the beginning and rename to "throwing". It feels like "throws"
> at the end is rather a legacy, probably from other languages and was a
> _default_ way of thinking at the time of initial implementation.
>
> I personally can live with both, though for the sake of consistency it
> should be moved to the beginning.
>
> On Tue, 27 Dec 2016 at 6:00 thislooksfun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> As far as I know, `throws` only affects whether or not the code must be
> marked with a `try` statement, the actual return type/value is unchanged
> (since it would be unreached if an error was thrown).
>
>
>
> -thislooksfun (tlf)
>
>
>
>
>
>
>
>
>
> On Dec 26, 2016, at 1:18 PM, David Sweeris  wrote:
>
>
> On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution <
> swift-evolution@swift.org> 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
>
>
>
> // 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)
>
>
> Does `throws` affect the actual return type? That is, is the size of the
> returned data different between "func foo() -> Int8" and "func foo() throws
> -> Int8"? If so, the "throws" is quite literally part of the return type
> and the current syntax reflects that. If not, I *think* I'd probably be
> in favor of that last "prefix modifier" suggestion with either "throwing"
> or "@throwing" (depending on the exact semantics of the "@" part — I'm a
> bit unclear on that detail)... probably... maybe... I'll have to think
> about it some more.
>
> - Dave Sweeris
>
>
> ___
>
> swift-evolution mailing list
>
> swift-evolution@swift.org
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Leping via swift-evolution]

IMO, considering "throws" is a modifier of function/method and determines
how the function can be called (another good example is mutating) the
logical approach would be to make things consistent and move everything
either to the beginning or to the end of declaration.

As long as "throws" is the only modifier at the end it's very logical to
move it to the beginning and rename to "throwing". It feels like "throws"
at the end is rather a legacy, probably from other languages and was a
_default_ way of thinking at the time of initial implementation.

I personally can live with both, though for the sake of consistency it
should be moved to the beginning.

On Tue, 27 Dec 2016 at 6:00 thislooksfun via swift-evolution <
swift-evolution@swift.org> wrote:

> As far as I know, `throws` only affects whether or not the code must be
> marked with a `try` statement, the actual return type/value is unchanged
> (since it would be unreached if an error was thrown).
>
>
>
> -thislooksfun (tlf)
>
>
>
>
>
>
>
>
>
> On Dec 26, 2016, at 1:18 PM, David Sweeris  wrote:
>
>
> On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution <
> swift-evolution@swift.org> 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
>
>
>
> // 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)
>
>
> Does `throws` affect the actual return type? That is, is the size of the
> returned data different between "func foo() -> Int8" and "func foo() throws
> -> Int8"? If so, the "throws" is quite literally part of the return type
> and the current syntax reflects that. If not, I *think* I'd probably be
> in favor of that last "prefix modifier" suggestion with either "throwing"
> or "@throwing" (depending on the exact semantics of the "@" part — I'm a
> bit unclear on that detail)... probably... maybe... I'll have to think
> about it some more.
>
> - Dave Sweeris
>
>
> ___
>
> swift-evolution mailing list
>
> swift-evolution@swift.org
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[thislooksfun via swift-evolution]

As far as I know, `throws` only affects whether or not the code must be marked 
with a `try` statement, the actual return type/value is unchanged (since it 
would be unreached if an error was thrown).

-thislooksfun (tlf)

> On Dec 26, 2016, at 1:18 PM, David Sweeris  wrote:
> 
> 
> On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution 
> > 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
>> 
>> // 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)
> 
> Does `throws` affect the actual return type? That is, is the size of the 
> returned data different between "func foo() -> Int8" and "func foo() throws 
> -> Int8"? If so, the "throws" is quite literally part of the return type and 
> the current syntax reflects that. If not, I think I'd probably be in favor of 
> that last "prefix modifier" suggestion with either "throwing" or "@throwing" 
> (depending on the exact semantics of the "@" part — I'm a bit unclear on that 
> detail)... probably... maybe... I'll have to think about it some more.
> 
> - Dave Sweeris
> 

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

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

[thislooksfun via swift-evolution]

I agree that the current form is better than the old way, but a lot of Swift's 
syntax is based around trying to be friendly for new programmers (remember 
removal of ++ and --?), and the form `x throws -> y` reads a lot like `x can 
throw y`, since the arrow is pointing between the two. I just would like some 
way to make it explicitly clear to those who have not had years of experience 
with Swift that `throws` is a standalone modifier.

-thislooksfun (tlf)

> On Dec 26, 2016, at 12:41 PM, Derrick Ho  wrote:
> 
> I personally do not see anything wrong with its current placement.
> 
> It may be there because it was based on an existing cocoa pattern from 
> objective-c
> 
> - (NSString *)bazWithError:(NSError **)error { ... }
> 
> Because objective c could only return one thing, using pointer-to-pointer was 
> needed to deliver more than one.
> 
> When swift came along it became this...
> 
> func baz(error: NSErrorPointer) -> String
> 
> The style felt old-fashioned and was replaced with throw.
> 
> func baz() throws -> String
> 
> 
> The evolution is consistent.  The pattern is familiar.  I think we should 
> keep the placement of throw as it is.
> 
> On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution 
> > 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
> 
> 
> 
> // 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 
> 
> 
> 

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

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

[Dave Abrahams via swift-evolution]

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.

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

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

[Tony Allevato via swift-evolution]

"throws" makes more sense closer to the end of the function signature
because it's an outcome like the return type. Swift's function syntax is
fairly consistent in this regard:  func ()
.

Personally, I think the keyword is fine where it is and this is the kind of
change where there would have to be *significant* advantages to changing
it. I think it would be hard to make the case that a change at this point
would warrant breaking existing code.
On Mon, Dec 26, 2016 at 10:59 AM Lucas Neiva via swift-evolution <
swift-evolution@swift.org> wrote:

> I like "throwing" as a prefix. It's reads well and fits very nicely with
> "mutating".
>
> Remembering where to put the keyword for is also easier if it's at the
> beginning, where it fits grammatically as "throwing func".
>
> On 26 Dec 2016, at 19:53, Micah Hainline via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'd prefer the placement at the very end, I do think it would improve
> readability, especially when taking closures as parameters and returning
> closures. However, I don't think the value would be worth the cost of
> breaking existing code. At the least if this were to go forward I would
> think we'd want both styles to work even if one was preferred or the other
> was deprecated.
>
>
>
> On Dec 26, 2016, at 12:41 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I personally do not see anything wrong with its current placement.
>
> It may be there because it was based on an existing cocoa pattern from
> objective-c
>
> - (NSString *)bazWithError:(NSError **)error { ... }
>
> Because objective c could only return one thing, using pointer-to-pointer
> was needed to deliver more than one.
>
> When swift came along it became this...
>
> func baz(error: NSErrorPointer) -> String
>
> The style felt old-fashioned and was replaced with throw.
>
> func baz() throws -> String
>
>
> The evolution is consistent.  The pattern is familiar.  I think we should
> keep the placement of throw as it is.
>
> On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution <
> swift-evolution@swift.org> 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
>
>
>
> // 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
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution 
>  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
> 
> // 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)

Does `throws` affect the actual return type? That is, is the size of the 
returned data different between "func foo() -> Int8" and "func foo() throws -> 
Int8"? If so, the "throws" is quite literally part of the return type and the 
current syntax reflects that. If not, I think I'd probably be in favor of that 
last "prefix modifier" suggestion with either "throwing" or "@throwing" 
(depending on the exact semantics of the "@" part — I'm a bit unclear on that 
detail)... probably... maybe... I'll have to think about it some more.

- Dave Sweeris

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

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

[Lucas Neiva via swift-evolution]

I like "throwing" as a prefix. It's reads well and fits very nicely with 
"mutating".

Remembering where to put the keyword for is also easier if it's at the 
beginning, where it fits grammatically as "throwing func".

> On 26 Dec 2016, at 19:53, Micah Hainline via swift-evolution 
>  wrote:
> 
> I'd prefer the placement at the very end, I do think it would improve 
> readability, especially when taking closures as parameters and returning 
> closures. However, I don't think the value would be worth the cost of 
> breaking existing code. At the least if this were to go forward I would think 
> we'd want both styles to work even if one was preferred or the other was 
> deprecated. 
> 
> 
> 
>> On Dec 26, 2016, at 12:41 PM, Derrick Ho via swift-evolution 
>>  wrote:
>> 
>> I personally do not see anything wrong with its current placement.
>> 
>> It may be there because it was based on an existing cocoa pattern from 
>> objective-c
>> 
>> - (NSString *)bazWithError:(NSError **)error { ... }
>> 
>> Because objective c could only return one thing, using pointer-to-pointer 
>> was needed to deliver more than one.
>> 
>> When swift came along it became this...
>> 
>> func baz(error: NSErrorPointer) -> String
>> 
>> The style felt old-fashioned and was replaced with throw.
>> 
>> func baz() throws -> String
>> 
>> 
>> The evolution is consistent.  The pattern is familiar.  I think we should 
>> keep the placement of throw as it is.
>> 
>> On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution 
>>  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
>> 
>> 
>> 
>> // 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
>> 
>> 
>> ___
>> 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] Move placement of 'throws' statement

[Lucas Neiva via swift-evolution]

> On 26 Dec 2016, at 19:53, Micah Hainline via swift-evolution 
>  wrote:
> 
> I'd prefer the placement at the very end, I do think it would improve 
> readability, especially when taking closures as parameters and returning 
> closures. However, I don't think the value would be worth the cost of 
> breaking existing code. At the least if this were to go forward I would think 
> we'd want both styles to work even if one was preferred or the other was 
> deprecated. 
> 
> 
> 
>> On Dec 26, 2016, at 12:41 PM, Derrick Ho via swift-evolution 
>>  wrote:
>> 
>> I personally do not see anything wrong with its current placement.
>> 
>> It may be there because it was based on an existing cocoa pattern from 
>> objective-c
>> 
>> - (NSString *)bazWithError:(NSError **)error { ... }
>> 
>> Because objective c could only return one thing, using pointer-to-pointer 
>> was needed to deliver more than one.
>> 
>> When swift came along it became this...
>> 
>> func baz(error: NSErrorPointer) -> String
>> 
>> The style felt old-fashioned and was replaced with throw.
>> 
>> func baz() throws -> String
>> 
>> 
>> The evolution is consistent.  The pattern is familiar.  I think we should 
>> keep the placement of throw as it is.
>> 
>> On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution 
>>  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
>> 
>> 
>> 
>> // 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
>> 
>> 
>> ___
>> 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] Move placement of 'throws' statement

[Micah Hainline via swift-evolution]

I'd prefer the placement at the very end, I do think it would improve 
readability, especially when taking closures as parameters and returning 
closures. However, I don't think the value would be worth the cost of breaking 
existing code. At the least if this were to go forward I would think we'd want 
both styles to work even if one was preferred or the other was deprecated. 



> On Dec 26, 2016, at 12:41 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> I personally do not see anything wrong with its current placement.
> 
> It may be there because it was based on an existing cocoa pattern from 
> objective-c
> 
> - (NSString *)bazWithError:(NSError **)error { ... }
> 
> Because objective c could only return one thing, using pointer-to-pointer was 
> needed to deliver more than one.
> 
> When swift came along it became this...
> 
> func baz(error: NSErrorPointer) -> String
> 
> The style felt old-fashioned and was replaced with throw.
> 
> func baz() throws -> String
> 
> 
> The evolution is consistent.  The pattern is familiar.  I think we should 
> keep the placement of throw as it is.
> 
> On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution 
>  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
> 
> 
> 
> // 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
> 
> 
> ___
> 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

[Derrick Ho via swift-evolution]

I personally do not see anything wrong with its current placement.

It may be there because it was based on an existing cocoa pattern from
objective-c

- (NSString *)bazWithError:(NSError **)error { ... }

Because objective c could only return one thing, using pointer-to-pointer
was needed to deliver more than one.

When swift came along it became this...

func baz(error: NSErrorPointer) -> String

The style felt old-fashioned and was replaced with throw.

func baz() throws -> String


The evolution is consistent.  The pattern is familiar.  I think we should
keep the placement of throw as it is.

On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution <
swift-evolution@swift.org> 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



// 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution