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

Sent from my iPhone > On Oct 27, 2016, at 17:53, Charles Srstka via swift-evolution > wrote: > > As long as we’re considering Ensure, how about Depends? It will keep optional > values from leaking out. +1 ___

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

> On Oct 25, 2016, at 11:38 AM, Jay Abbott via swift-evolution > wrote: > > I mentioned this in passing on a different thread > . > Although it caused some slight confusion when I

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

> Am 26.10.2016 um 18:41 schrieb Chris Lattner via swift-evolution > : > >> On Oct 26, 2016, at 1:11 AM, alessandro aresta >> wrote: >> Ensure is more comprehensible, guard is for sure "always" been there in >> older languages... could it

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

> On Oct 27, 2016, at 08:21, Jay Abbott wrote: > > You’re really in pun mode today, David! :) > It's the best mode  > But I do really like Marco’s suggestion of guard: because it changes the > interpretation… > > guard: x > 0 else { return } > This now reads as: This is

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

> On Oct 27, 2016, at 08:09, Haravikk wrote: > > >> On 27 Oct 2016, at 13:31, David Sweeris via swift-evolution >> wrote: >> >> >> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution >> wrote: >>

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

You’re really in pun mode today, David! :) Even though I originally pitched this, I go along with the source-churn arguments people have made[1], and the one about ensure potentially being used for something else in the future. But I do really like Marco’s suggestion of guard: because it changes

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

> On 27 Oct 2016, at 13:31, David Sweeris via swift-evolution > wrote: > > > On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution > > wrote: > >> On Oct 26, 2016, at 1:11 AM, alessandro aresta

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

> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution > wrote: > >> On Oct 26, 2016, at 1:11 AM, alessandro aresta >> wrote: >> Ensure is more comprehensible, guard is for sure "always" been there in >> older languages... could

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

On Oct 26, 2016, at 1:11 AM, alessandro aresta wrote: > Ensure is more comprehensible, guard is for sure "always" been there in older > languages... could it be kind of aliased somehow? I tend to confuse guard > sometimes, despite many few decades of using it. No, we

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

Ensure is more comprehensible, guard is for sure "always" been there in older languages... could it be kind of aliased somehow? I tend to confuse guard sometimes, despite many few decades of using it. On Wed, Oct 26, 2016 at 2:52 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org>

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

> On Oct 25, 2016, at 10:20 AM, Joe Groff via swift-evolution > 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

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

> On Oct 25, 2016, at 11:44 AM, Jay Abbott 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

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

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

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

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

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

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

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

> > I don’t read “*Guard that x is higher than 0 else … *”, but instead I > read it like “*Guard! x must be higher than 0 else …*”. > > I see, yes I hadn't considered this interpretation... > > Probably adding a colon could make it more clear to the reader: > > guard: x > 0 else { > return >

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

> On Oct 25, 2016, at 10:38 AM, Jay Abbott via swift-evolution > wrote: > > I mentioned this in passing on a different thread > . > Although it caused some slight confusion when I

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

I don’t really mind the “guard” keyword after having used it hundreds of times, but it didn’t really make a lot of sense to me to start with (I’m not a native speaker). “ensure” definitely conveys the meaning better, in my opinion. I’d be in favor of this change. I bet most people won’t think

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

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." That’s a good point, but I think it

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

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