Rename 'guard' to 'ensure'


(John Flanagan) #1

The functionality of ‘guard’ is great and this proposal has nothing to do with changing that. The only suggestion is that the word ‘ensure’ would better communicate what a ‘guard’ statement does to those encountering it for the first time and would make code more readable in general.

Example:

ensure foo != nil else {
   return;
}

-John


(Shawn Erickson) #2

Ensure(TM) ...has a little much sugar for my wants in a drink

I get and like the suggestion from a grammar pov however guard is a little
more forceful in terminology which aligns with the fact that you cannot
proceed past the guard unless the condition is met. (I have a vision of a
little guard standing at his guard post checking papers)

-Shawn

···

On Mon, Feb 22, 2016 at 9:01 AM John Flanagan via swift-evolution < swift-evolution@swift.org> wrote:

The functionality of ‘guard’ is great and this proposal has nothing to do
with changing that. The only suggestion is that the word ‘ensure’ would
better communicate what a ‘guard’ statement does to those encountering it
for the first time and would make code more readable in general.

Example:

ensure foo != nil else {
   return;
}

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Radek Pietruszewski) #3

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”…

The only problem I have is that “ensure” exists in a different language I know (Ruby), where it has different meaning.

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 :wink:

— Radek

···

On 19 Feb 2016, at 22:49, John Flanagan via swift-evolution <swift-evolution@swift.org> wrote:

The functionality of ‘guard’ is great and this proposal has nothing to do with changing that. The only suggestion is that the word ‘ensure’ would better communicate what a ‘guard’ statement does to those encountering it for the first time and would make code more readable in general.

Example:

ensure foo != nil else {
   return;
}

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Haravikk) #4

I’m not strictly against the proposal, but I don’t think that renaming to ensure adds anything.

guard is essentially a neat feature for programming defensively, so guard to me is stronger fit thematically in that sense.

···

On 19 Feb 2016, at 21:49, John Flanagan via swift-evolution <swift-evolution@swift.org> wrote:

The functionality of ‘guard’ is great and this proposal has nothing to do with changing that. The only suggestion is that the word ‘ensure’ would better communicate what a ‘guard’ statement does to those encountering it for the first time and would make code more readable in general.

Example:

ensure foo != nil else {
   return;
}

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #5

" a vision of a little guard standing at his guard post checking papers"

Raises hand. Me too. I like my little guard.

On the other hand, I'd love if assert/precondition would be combined
into a single call, with an optional `forReleaseBuild:` arg (better
named) that defaults to false.

I really don't want to do that. Assert and precondition have different
use-cases, and I don't want people to ask “do I want this on in a
release build?” (which is a hard decision to make correctly and
consistently) when they write them. I want them to ask, “Am I checking
whether this method is being called correctly or is this just a
self-sanity check?”

···

on Mon Feb 22 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On Feb 22, 2016, at 10:07 AM, Shawn Erickson via swift-evolution >> <swift-evolution@swift.org> wrote:

Ensure(TM) ...has a little much sugar for my wants in a drink

I get and like the suggestion from a grammar pov however guard is a
little more forceful in terminology which aligns with the fact that
you cannot proceed past the guard unless the condition is met. (I
have a vision of a little guard standing at his guard post checking
papers)

-Shawn

On Mon, Feb 22, 2016 at 9:01 AM John Flanagan via swift-evolution >> <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> >> wrote:
The functionality of ‘guard’ is great and this proposal has nothing
to do with changing that. The only suggestion is that the word
‘ensure’ would better communicate what a ‘guard’ statement does to
those encountering it for the first time and would make code more
readable in general.

Example:

ensure foo != nil else {
   return;
}

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Erica Sadun) #6

" a vision of a little guard standing at his guard post checking papers"

Raises hand. Me too. I like my little guard.

On the other hand, I'd love if assert/precondition would be combined into a single call, with an optional `forReleaseBuild:` arg (better named) that defaults to false.

-- E

···

On Feb 22, 2016, at 10:07 AM, Shawn Erickson via swift-evolution <swift-evolution@swift.org> wrote:

Ensure(TM) ...has a little much sugar for my wants in a drink

I get and like the suggestion from a grammar pov however guard is a little more forceful in terminology which aligns with the fact that you cannot proceed past the guard unless the condition is met. (I have a vision of a little guard standing at his guard post checking papers)

-Shawn

On Mon, Feb 22, 2016 at 9:01 AM John Flanagan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
The functionality of ‘guard’ is great and this proposal has nothing to do with changing that. The only suggestion is that the word ‘ensure’ would better communicate what a ‘guard’ statement does to those encountering it for the first time and would make code more readable in general.

Example:

ensure foo != nil else {
   return;
}

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #7

" a vision of a little guard standing at his guard post checking papers"

Raises hand. Me too. I like my little guard.

On the other hand, I'd love if assert/precondition would be combined
into a single call, with an optional `forReleaseBuild:` arg (better
named) that defaults to false.

I really don't want to do that. Assert and precondition have different
use-cases, and I don't want people to ask “do I want this on in a
release build?” (which is a hard decision to make correctly and
consistently) when they write them. I want them to ask, “Am I checking
whether this method is being called correctly or is this just a
self-sanity check?”

Agreed. There are (usually very unfortunate) reasons for me to turn on
self-sanity checks for release builds, as well.

Having the ability to do that is something I would support.

There is also the possibility of an assert/precondition having
side-effects, and people being confused that the forReleaseBuild:false
version never calls their code at all. This is exasperated IMO since
the methods use @autoclosure.

exacerbated, yes.

···

on Mon Feb 22 2016, David Waite <swift-evolution@swift.org> wrote:

On Feb 22, 2016, at 11:15 AM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:
on Mon Feb 22 2016, Erica Sadun <swift-evolution@swift.org> wrote:

--
-Dave


(David Waite) #8

Agreed. There are (usually very unfortunate) reasons for me to turn on self-sanity checks for release builds, as well.

There is also the possibility of an assert/precondition having side-effects, and people being confused that the forReleaseBuild:false version never calls their code at all. This is exasperated IMO since the methods use @autoclosure.

-DW

···

On Feb 22, 2016, at 11:15 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Feb 22 2016, Erica Sadun <swift-evolution@swift.org> wrote:

" a vision of a little guard standing at his guard post checking papers"

Raises hand. Me too. I like my little guard.

On the other hand, I'd love if assert/precondition would be combined
into a single call, with an optional `forReleaseBuild:` arg (better
named) that defaults to false.

I really don't want to do that. Assert and precondition have different
use-cases, and I don't want people to ask “do I want this on in a
release build?” (which is a hard decision to make correctly and
consistently) when they write them. I want them to ask, “Am I checking
whether this method is being called correctly or is this just a
self-sanity check?”


(Greg Parker) #9

Conversely, "do I want this on in a release build" is precisely the decision I usually make in my own code. The dichotomy is not parameter validation versus sanity checks. Instead the dichotomy is checks that are fast enough for release builds versus checks that are too slow or have rare false positives and must be left only for non-release builds. "assert" and "precondition" are not useful names for that usage.

···

On Feb 22, 2016, at 10:15 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Feb 22 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On the other hand, I'd love if assert/precondition would be combined
into a single call, with an optional `forReleaseBuild:` arg (better
named) that defaults to false.

I really don't want to do that. Assert and precondition have different
use-cases, and I don't want people to ask “do I want this on in a
release build?” (which is a hard decision to make correctly and
consistently) when they write them. I want them to ask, “Am I checking
whether this method is being called correctly or is this just a
self-sanity check?”

--
Greg Parker gparker@apple.com Runtime Wrangler


(Dave Abrahams) #10

Well, I'd be open to a proposal for a checkInReleaseBuilds: Bool = false
parameter to assert, for those people who want to run their sanity
checks in release builds, but I don't think I want to retire precondition().

···

on Mon Feb 22 2016, Greg Parker <swift-evolution@swift.org> wrote:

On Feb 22, 2016, at 10:15 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Feb 22 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On the other hand, I'd love if assert/precondition would be combined
into a single call, with an optional `forReleaseBuild:` arg (better
named) that defaults to false.

I really don't want to do that. Assert and precondition have different
use-cases, and I don't want people to ask “do I want this on in a
release build?” (which is a hard decision to make correctly and
consistently) when they write them. I want them to ask, “Am I checking
whether this method is being called correctly or is this just a
self-sanity check?”

Conversely, "do I want this on in a release build" is precisely the
decision I usually make in my own code. The dichotomy is not parameter
validation versus sanity checks. Instead the dichotomy is checks that
are fast enough for release builds versus checks that are too slow or
have rare false positives and must be left only for non-release
builds. "assert" and "precondition" are not useful names for that
usage.

--
-Dave


(Shawn Erickson) #11

We need a guard emoji... how about calling it🛂?

:wink:

···

On Mon, Feb 22, 2016 at 9:25 AM Erica Sadun <erica@ericasadun.com> wrote:

> " a vision of a little guard standing at his guard post checking papers"

Raises hand. Me too. I like my little guard.

On the other hand, I'd love if assert/precondition would be combined into
a single call, with an optional `forReleaseBuild:` arg (better named) that
defaults to false.

-- E

On Feb 22, 2016, at 10:07 AM, Shawn Erickson via swift-evolution < > swift-evolution@swift.org> wrote:

Ensure(TM) ...has a little much sugar for my wants in a drink

I get and like the suggestion from a grammar pov however guard is a little
more forceful in terminology which aligns with the fact that you cannot
proceed past the guard unless the condition is met. (I have a vision of a
little guard standing at his guard post checking papers)

-Shawn

On Mon, Feb 22, 2016 at 9:01 AM John Flanagan via swift-evolution < > swift-evolution@swift.org> wrote:

The functionality of ‘guard’ is great and this proposal has nothing to do
with changing that. The only suggestion is that the word ‘ensure’ would
better communicate what a ‘guard’ statement does to those encountering it
for the first time and would make code more readable in general.

Example:

ensure foo != nil else {
   return;
}

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(John Flanagan) #12

I'm not sure that "sugar" is the right word, but I will give you that "guard" is probably too well established to be usurped by ensure™ just for the sake of grammar.
-John

···

_____________________________
From: Shawn Erickson <shawnce@gmail.com>
Sent: Monday, February 22, 2016 11:07 AM
Subject: Re: [swift-evolution] Rename 'guard' to 'ensure'
To: John Flanagan <john@jflan.com>, <swift-evolution@swift.org>

       Ensure(TM) ...has a little much sugar for my wants in a drink
   
I get and like the suggestion from a grammar pov however guard is a little more forceful in terminology which aligns with the fact that you cannot proceed past the guard unless the condition is met. (I have a vision of a little guard standing at his guard post checking papers)
   
-Shawn
         On Mon, Feb 22, 2016 at 9:01 AM John Flanagan via swift-evolution < swift-evolution@swift.org> wrote:
               The functionality of ‘guard’ is great and this proposal has nothing to do with changing that. The only suggestion is that the word ‘ensure’ would better communicate what a ‘guard’ statement does to those encountering it for the first time and would make code more readable in general.
                Example:
                ensure foo != nil else { return; }
                -John _______________________________________________
swift-evolution mailing list
     swift-evolution@swift.org
     https://lists.swift.org/mailman/listinfo/swift-evolution


(Matt Whiteside) #13

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.

Matt

···

On Feb 23, 2016, at 00:54, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

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”…

The only problem I have is that “ensure” exists in a different language I know (Ruby), where it has different meaning.

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 :wink:

— Radek


(Vanderlei Martinelli) #14

guard !guardKeywordIsRenamedToSomethingElse else { return nil }

-1

···

On Tue, Feb 23, 2016 at 5:52 PM, Matt Whiteside via swift-evolution < swift-evolution@swift.org> wrote:

> On Feb 23, 2016, at 00:54, Radosław Pietruszewski via swift-evolution < > swift-evolution@swift.org> wrote:
>
> 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”…
>
> The only problem I have is that “ensure” exists in a different language
I know (Ruby), where it has different meaning.
>
> 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 :wink:
>
> — Radek

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.

Matt
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution