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

Tue Dec 27 23:28:57 CST 2016

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 at 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 at 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 <xiaodi.wu at gmail.com> wrote:
>>
>> Offlist on purpose?
>>
>> On Tue, Dec 27, 2016 at 5:03 PM, thislooksfun <thislooksfun at repbot.org>
>> 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 <xiaodi.wu at gmail.com> 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 at 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 at 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 <wh1pch81n at gmail.com> 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <swift-
>> evolution at 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 <swift-evolution at haravikk.me>
>> wrote:
>>
>> On 27 Dec 2016, at 13:43, Tino Heth <2th at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>>
>> swift-evolution mailing list
>>
>> swift-evolution at swift.org
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161227/b7fe728b/attachment.html>