[swift-evolution] [pitch] rename 'guard' to 'ensure'

Tue Oct 25 14:16:11 CDT 2016

There is more difference between “guard” and “ensure”.
“Guarding” is something you do at the gate, not just everywhere. This has imo an impact on how code is structured. (It did for me)
“Ensuring” is something you can do everywhere.
Myself, I tend to use “guard” mostly at the beginning of a routine.
Further in I tend to use “if’s” unless I need to define a variable for subsequent use and want to avoid nesting.

Rien.
PS: non native….
PPS: No opinion on either changing or keeping guard

> On 25 Oct 2016, at 20:44, Jay Abbott via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hey Joe,
> 
> I tend to agree, it seems like a tiny niggle for experienced C-family developers who have used if(negative condition) as a guard for years, and those with knowledge in other languages where it is already known. But for new developers, learning the language of the future as a first-language (such as my other half, who is learning Swift as her first programming language with the "Swift Playgrounds" app), doesn't it make sense for such a concept to fit right in with their existing linguistic model of the world? This makes a language intuitive rather than something you need to 'learn'.
> 
> This is where "strong motivation" and "overwhelming evidence" lose their meanings (to me). This group does seem to be strongly motivated to help new developers, and ensure Swift is easy and intuitive for them, as well as powerful for experienced developers. Is it practical to gather evidence on how new developers learn and internalise "guard" or any other part of the language? Probably not, so how can we ever have "overwhelming evidence" for anything related to intuitiveness for new developers? Also is there a grey area for source-breaking changes? I mean obviously a change is either breaking or it's not, but if we were to take Marco's idea and use "guard:" instead of "ensure" - existing articles and QA online would still be searchable/relevant, the compiler could emit a fixme error to add the colon when it came across old syntax (or Xcode's converter or a simple project-wide search/replace would rectify old syntax), etc. so there are breaking changes, and then there are trivial-to-rectify breaking changes. Another point is: If there is a single breaking change, for strong reasons, doesn't that invalidate all arguments against other (automatically convertible) breaking changes which have not-so-strong reasons? If code needs to be converted, then what difference does it make how many trivial automated changes there are? And isn't that the entire point of a major version bump anyway?
> 
> I think as a group we should be cautious of:
> * hard/fast/unbreakable rules
> * subjective terms like "strong motivation" and even "overwhelming evidence", especially where our evidence is our own arguments and examples, as made and interpreted by some of the experienced to genius level developers on this list.
> * denying or failing to recognise grey areas.
> 
> I'm not having a go at you Joe, or anyone else who has made these points. I actually agree that this particular issue seems too trivial to warrant a change, but I'm trying to question if that's the right conclusion (which is what motivated me to post this thread in the first place). The 'cost' seems small, and while the 'benefit' seems tiny to us, it might actually be quite huge for new developers.
> 
> 
> On Tue, 25 Oct 2016 at 18:20 Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
> At this point in Swift's evolution, source-breaking changes to the language require strong motivation. We can't really entertain superficial keyword changes like this without overwhelming evidence that the existing syntax is problematic in practice. `guard` has precedent in functional languages, for instance in Haskell where the `guard` function is idiomatically used as part of monadic `do`-notation computations, and has the same positive condition semantics in those languages.
> 
> -Joe
> 
> > On Oct 25, 2016, at 9:38 AM, Jay Abbott via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > I mentioned this in passing on a different thread. Although it caused some slight confusion when I first learned the 'guard' keyword, it was easy to overcome and I didn't think the issue was strong enough to warrant a change. However, after reading the other discussion on that thread (around the possibility of a 'matches' keyword and how code is "read out" or "internally verbalised"), and seeing how passionate everyone here is about Swift, I'm thinking that maybe it should be changed.
> >
> > The issue is that in English, 'guard' has an inverted logical connotation to how it is used in Swift. For example, take this sentence:
> >
> > "In some functions it's a good idea is to put some checks in place, in order to guard against invalid input values."
> >
> > Swift's 'guard' keyword is to guard against invalid values.
> > Or to put it another way, to ensure that we have valid values.
> >
> > However, the way it reads in Swift, we guard that we have valid values.
> >
> > I fully understand and agree that it's better to state the true condition for valid values here, using else to perform a contingency. And I understand why the word 'guard' was picked (given the above example sentence). I just think that 'ensure' would be better.
> >
> > ensure x > 0 else {
> >     return
> > }
> >
> > ensure camp.isSafe else {
> >     runForTheHills()
> > }
> >
> > ensure let thingy = object as? Thingy else {
> >     return ExamineThingyResult.NotAThingy
> > }
> >
> > As I said, I thought it was too small a niggle to worry about, but seeing how people on here care so much about making Swift better, and the willingness to change things, I thought I'd suggest it. Although it would be a breaking change, the code changes are easy.
> >
> > So what do people think? In particular it would be interesting to hear from non-native English speakers on this, did 'guard' confuse you or did 'guard' cause your understanding of the English word to be confused?
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161025/228d3f98/attachment.html>