<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="font-family: LucidaGrande;" class="">There is no way to encode that an initializer can only fail because of a simple programming error when all you have next to it is "throws". When I see "init?", I know that the function can fail because I didn't check parameters. When I see "init() throws", I know that it can fail for a more complex reason, like failing to get a handle to some resource. The exception object will tell me why and if I don't have a shot at recovery, I expect to have at least something to tell the user.</span><div class=""><font face="LucidaGrande" class=""><br class=""></font></div><div class=""><font face="LucidaGrande" class="">I have no intention of developing a habit of writing try? in front of initializers when I can't discern the reason that they can fail.</font></div><div class=""><div class=""><div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 3 mars 2016 à 16:43:19, Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 3 Mar 2016, at 20:53, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:<br class=""><br class="">There are established guidelines for Swift error handling.<br class=""></blockquote><br class="">That’s fine, but this proposal would change that so I’m sure it’s really relevant. No one’s arguing that the current advice is bad, as it’s fine given that failable initialisers currently exist, but if they were to be removed then that advice simply needs to change.<br class=""><br class=""><blockquote type="cite" class="">The guidance is that returning nil is appropriate when your function could fail due to simple domain errors, for instance passing a negative value as a parameter where they aren't allowed.<br class=""></blockquote><br class="">If that’s all you need then what’s wrong with throwing some generic purpose illegal argument type exception and using try? It’s functionally the same, i.e- removing failable initialisers doesn’t actually remove a capability, it just removes what is essentially now a redundant one. In other words, try? on a throwable initialiser is now functionally identical to a failable initialiser and isn't appreciably more complex, especially if there’s a common exception that can be thrown for general purpose invalid argument errors (not sure if there is one right now, but it could be added to the proposal).<br class=""><br class="">That means we really have two identical features, one of which has greater flexibility, so does it make sense to keep the less capable variant?<br class=""><br class=""><blockquote type="cite" class="">The duality is that an error reported through the throwing mechanism should be non-trivial.<br class=""></blockquote><br class="">Is calling an initialiser with invalid values really trivial?<br class=""><br class=""><blockquote type="cite" class="">I am wary of using the try? keyword in general (as it discards potentially meaningful information) and I'm happy that initializers are allowed to be failable.<br class=""></blockquote><br class="">The difference between try? discarding potentially useful information and a failable initialiser is that the failable initialiser provides no potentially useful information. That to me is a reason against failable initialisers, as they’re simply providing a generic failure condition in the form of nil. Besides, I don’t think that try? has inherent problems, it explicitly indicates that you are aware that the initialiser can fail, and choose to ignore the actual error in favour of working with nil instead (or providing a default with ??). Sometimes the reason for something failing just doesn’t matter to you, only that it did fail.<br class=""><br class="">That’s not to say that throwable initialisers can’t just return a single error type either; they absolutely can. The benefit of them over failable initialisers is that they could produce any number of useful errors depending upon what can actually go wrong.</div></div></blockquote></div><br class=""></div></div></div></body></html>