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

[Jay Abbott]

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> 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> 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
> > 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/dd056fa2/attachment.html>