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 <[email protected]> wrote: > > Offlist on purpose? > > On Tue, Dec 27, 2016 at 5:03 PM, thislooksfun <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution >>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> On 27 Dec 2016, at 13:43, Tino Heth <[email protected] <mailto:[email protected]>> >>>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
