<div dir="ltr"><font face="monospace, monospace">guard !guardKeywordIsRenamedToSomethingElse else { return nil }</font><div><br></div><div>-1</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 5:52 PM, Matt Whiteside via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Feb 23, 2016, at 00:54, Radosław Pietruszewski via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I don’t have a problem with “guard”, and I have grown used to it, but I will give you that “ensure” is probably clearer. “ensure *this condition is true*”, “ensure that I can let foo = bar” — seems easier to conceptualize its meaning from syntax than “guard”…<br>
><br>
> The only problem I have is that “ensure” exists in a different language I know (Ruby), where it has different meaning.<br>
><br>
> So… I’m not sure it’s worth changing “guard” now and I probably wouldn’t be *for* the change, but I also probably wouldn’t argue against it either ;)<br>
><br>
> — Radek<br>
<br>
</span>My thoughts are almost the same, except that I wouldn’t consider the fact that ensure means something different in Ruby to be a problem. IMO, something like ‘always’ would have been a clearer keyword for what Ruby intended there anyway.<br>
<br>
Matt<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>