-1 I think the basic type system should remain free of such constructs.
I.e. if a Throws? is necessary on a + operation between integers, then the integers should be encapsulated into their own type. In fact I am thinking lately of the “need” for a new type system in parallel to the current type system specifically for arithmetic. It would consist of Naturals, Reals, Imaginary etc. These new types would also have Nan and Infinite as members and use these to deal with out-of-bounds situations. Besides, it should be possible to constrain a subtype of them to a predefined ranges etc. While these are just ‘thoughts’ at the moment, I did come to the conclusion that “one size fits all” is not the correct approach. And I apply the same thinking to the suggested Throws?. Imo it would introduce side effects into the current type system that would only benefit a small subset of users, and it would -probably- not completely satisfy those user fully. Hence a new arithmetic based type system would probably be better. And until (if ever) such a system is available it would imo be better to keep things as they are and implement specific mathematical requirements in wrappers. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 12 Jan 2017, at 23:58, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > I really like swift’s error handling system overall. It strikes a good > balance between safety and usability. > > There are some cases where it would be nice to throw errors, but errors are > rarely expected in most use cases, so the overhead of ‘try’, etc… would make > things unusable. Thus fatalError or optionals are used instead. For example, > operators like ‘+’ could never throw because adding ’try’ everywhere would > make arithmetic unbearable. But in a few cases it would make my algorithm > much cleaner if I just assume it will work and then catch overflow/underflow > errors if they happen, and resolve each of them with special cases. Or > perhaps I am dealing with user entered values, and want to stop the > calculation and display a user visible error (e.g. a symbol in a spreadsheet > cell) instead of crashing. > > I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’. > > These would be used for cases where error handling is not the default desired > behavior, but having it as an option is desired occasionally. Essentially, > the user would no longer have to preface the call with ‘try’, as the compiler > would implicitly add ‘try?’ or ‘try!’ respectively. > > Thus, the function would act like a non-throwing function (either trapping or > returning an optional in the case of error), but the user could add ‘try’ to > the call to override that behavior and deal with the error more explicitly. > > Another example would be bounds checking on arrays. If subscripting arrays > was marked as ‘throws!’ then it would have the same default behavior it does > now (trapping on bounds error). But a user could add ‘try?’ to return nil > for a bounds error in cases where they explicitly want that, or they could > add ‘try’ to deal with it as an error using do-catch. > > I think this would really increase the availability of error handling in > areas where it is impractical right now… > > Thanks, > Jon > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
