<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Apr 2016, at 10:05, Jacob Bandes-Storch &lt;<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Clarifying questions as comments:</div><div class=""><br class=""></div><div class=""><div class="gmail_extra"><div class="gmail_extra">&nbsp; &nbsp; guard device = MTLCreateSystemDefaultDevice() else {</div><div class="gmail_extra">&nbsp; &nbsp; &nbsp; &nbsp; fatalError()</div><div class="gmail_extra">&nbsp; &nbsp; }</div><div class="gmail_extra">&nbsp; &nbsp; device = nil &nbsp; <b class="">// Is this still allowed here?</b></div></div></div></div></div></blockquote><div><br class=""></div><div>Device instance variable is not an optional — so, no. The entire point of this would be to init potentially failable substate without having to deal with forcibly unwrapped optionals or having guards every time when substate needs to be accessed etc.&nbsp;</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_extra">&nbsp; &nbsp; device.newDefaultLibrary() &nbsp;<b class="">// Is this allowed without optional chaining?</b></div></div></div></div></div></blockquote><div><br class=""></div><div>Sure</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class=""><br class=""></div><div class="">Also, I don't see any reason this idea should be restricted to instance variables. It could work for any variable, I think, but in any case it gets tricky if the value is mutated again afterwards.</div></div></div></div></div></blockquote><div><br class=""></div><div>The problem as I see it is that guard enforces state consistency. If the guard fails, any code that access the guarded state becomes invalid. This is why guard else clause requires one to leave the enclosing scope — to ensure that the guarded variables cannot be accesses in valid code. If one extends the binding to other variables, one runs into the problem that these variables can be accessed from outside. This is why I am suggesting to restrict guard to constructors only and fail the object construction if the guard fails.&nbsp;</div><div><br class=""></div><div>— Taras</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class=""><br class=""></div><div class=""><div class=""><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Mon, Apr 11, 2016 at 12:31 AM, Taras Zakharko via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">One place where I find myself using the guard statement a lot is state initialisation. E.g. in init()<br class="">
<br class="">
guard let<br class="">
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;device&nbsp; &nbsp;= MTLCreateSystemDefaultDevice(),<br class="">
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;library&nbsp; = device.newDefaultLibrary()<br class="">
else {<br class="">
&nbsp; &nbsp;fatalError(“Could not initiallize Metal, aborting”)<br class="">
}<br class="">
<br class="">
Here, the two variables device and library are intended to be instance variables of an engine backbone system. However, because optional binding in guard can only introduce new local statements, one needs to add additional boilerplate in the end, e.g.:<br class="">
<br class="">
self.device = device<br class="">
self.library&nbsp; = library<br class="">
<br class="">
What I want to propose is a very simple QOL enhancement: allow optional binding to be used with instance variables in the constructors. If the binding fails, the instance construction cannot proceed (the relevant scope is the instance). The syntax would be<br class="">
<br class="">
guard&nbsp; device&nbsp; &nbsp;= MTLCreateSystemDefaultDevice(),<br class="">
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;library&nbsp; = device.newDefaultLibrary()<br class="">
else {<br class="">
&nbsp; &nbsp;fatalError(“Could not initiallize Metal, aborting”) // or return nil<br class="">
}<br class="">
<br class="">
<br class="">
Few notes:<br class="">
<br class="">
- This would only apply to guard statement, because binding in the if statement only applies to the internal if scope by definition<br class="">
- One could also ask for instance optional binding in any context where instance assignment is legal. However, this would make guard inconsistent, as it won’t be able to prevent inconsistent state from being invisible to the app. Therefore its best to restrict this to cases where state is being constructed, and fail the construction if the guard fails (hence init() )<br class="">
<br class="">
Best,<br class="">
<br class="">
&nbsp;Taras<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div><br class=""></div></div></div>
</div></blockquote></div><br class=""></body></html>