[swift-users] "business applications market" flame

[Joe Groff]

> On Jan 6, 2016, at 1:12 PM, Don Wills via swift-users <swift-users at swift.org> wrote:
> 
> 
>> On Jan 6, 2016, at 1:15 PM, Jens Alfke <jens at 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