> On Jan 6, 2016, at 1:12 PM, Don Wills via swift-users <swift-users@swift.org> > wrote: > > >> On Jan 6, 2016, at 1:15 PM, Jens Alfke <j...@mooseyard.com> wrote: >> >> * The requirement of the ‘try’ prefix means that if a function that isn’t >> failable later gets modified to be failable, every call site will now >> trigger a compile error due to the missing ‘try’ keyword. This means the >> programmer who made the change will have to go through the codebase and >> consider the possibility of failure and adjust the call site accordingly. >> This is a really good thing! > > It also means that every third party API provider will *never* be able to > change any method signature from failable to non-failable or vice-versa. > That is a really bad thing! This concern is why Microsoft rightly chose to > have *only* non-checked exceptions in C# (Java has both checked and > non-checked).
You can resiliently go from failable to not failable just fine without recompiling code; the compiler will warn about redundant try's, but it isn't an error, and the try keywords can be cleaned up easily. Introducing failability to non-failable APIs fundamentally requires all of your users to now audit their code for error safety; some languages choose not to let the compiler help you with this. Note that unlike Java, we intentionally don't restrict errors to a particular type, so you can introduce new failure modes without breaking your API. -Joe _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
