[pitch] rename 'guard' to 'ensure'

Evolution Pitches
1

I mentioned this in passing on a different thread
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028371.html&gt;\.
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?

2

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

“Guard” is a computer science term for a test that must pass for execution to continue. Given that, I don’t think changing the keyword is warranted.

Preston

···

On Oct 25, 2016, at 10:38 AM, Jay Abbott via swift-evolution <swift-evolution@swift.org> wrote:

I mentioned this in passing on a different thread <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028371.html&gt;\. 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?

4

Right. Jay, I’m sorry if you or others find the name “guard” to be confusing, but there are many Swift developers that like it. I is almost inconceivable that we would change it at this point.

-Chris

···

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

5

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@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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

6

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 it’s worth it to to rename it now. It’s kind of a pain for people that come across articles mentioning guard, though Xcode could assist with this change. If “ensure” was current day syntax and someone would now propose to change it to “guard”, I’m almost certain nobody would really take them seriously (but that may just be my unfamiliarity with the English language).

···

I mentioned this in passing on adifferent thread(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028371.html\). 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 toguardagainstinvalidvalues.
Or to put it another way, toensurethat we havevalidvalues.

However, the way it reads in Swift, weguardthat we havevalidvalues.

I fully understand and agree that it's better to state thetruecondition forvalidvalues here, usingelseto 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?

7

As long as we’re considering Ensure, how about Depends? It will keep optional values from leaking out.

Charles

···

On Oct 25, 2016, at 11:38 AM, Jay Abbott via swift-evolution <swift-evolution@swift.org> wrote:

I mentioned this in passing on a different thread <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028371.html&gt;\. 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

These conditions are by their nature subjective and involve gray areas. I'm not denying that. It's true that new developers are an important audience for Swift, but we have a large and growing user base of existing developers now, and we don't want to inflict churn on them without a good justification. By all means, if you or someone else gathered evidence that changing a keyword made a massive improvement in learnability, reduced error rate, or other benefits, we'd pay attention. Our default position has to be to maintain stability absent that.

-Joe

···

On Oct 25, 2016, at 11:44 AM, Jay Abbott <jay@abbott.me.uk> 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.

9

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@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@apple.com <mailto:jgroff@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@swift.org <mailto:swift-evolution@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@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

10

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

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

Right. Jay, I’m sorry if you or others find the name “guard” to be
confusing, but there are many Swift developers that like it. I is almost
inconceivable that we would change it at this point.

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

--
*Alessandro Alexander Stone Aresta*

senior development & consulting

*email : performerstone@gmail.com <performerstone@gmail.com>*
*skype : alexanderstone2007*

*This is a confidential communication intended only for the
named addressee. *
* If you received this **communication **in **error, please notify
us and return and delete it without reading it. *

*This e-mail may not be *
*disclosed, copied or distributed*
* in **any form without the obtained permission in writing of Alessandro
Aresta. *

*In any case it may not be altered or otherwise *

*changed. *
* Whilst Alessandro Aresta believes that the information is correct
at the date of the e-mail, no warranty and *

*representation is given to this effect and no responsibility can be
accepted by Alessandro Aresta.*

11

As long as we’re considering Ensure, how about Depends? It will keep optional values from leaking out.

+1

···

Sent from my iPhone

On Oct 27, 2016, at 17:53, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

12

No, we don’t introduce needless aliases for keywords like this.

I haven’t seen it mentioned on this thread yet, but we did consider “ensure” back when the guard statement was being designed for Swift 2. We specifically avoided it because “ensure” is very much in the lexicon of pre and post conditions, and we want to reserve its use if/when we ever get there.

-Chris

···

On Oct 26, 2016, at 1:11 AM, alessandro aresta <performerstone@gmail.com> 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.

13

What about allowing internal non-type aliases?
    alias ensure = guard //can't be public
I know it's kinda encroaching on "macro" territory, but can't we already do simple text substitutions by importing a #define from C? Would allowing non-type aliases really be any different?

It'd address the concerns raised by I think nearly all of the "term-of-art" vs "term-of-English" proposals. Prohibiting aliases from being declared as `public` would guard the language's namespace, and ensure that it doesn't get polluted with every library author's favorite alternate spelling(s).

- Dave Sweeris

···

On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 26, 2016, at 1:11 AM, alessandro aresta <performerstone@gmail.com> wrote:
Ensure is more comprehensible, guard is for sure "always" been there in older languages... could it be kind of aliased somehow?

No, we don’t introduce needless aliases for keywords like this.

14

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 don’t introduce needless aliases for keywords like this.

I haven’t seen it mentioned on this thread yet, but we did consider “ensure” back when the guard statement was being designed for Swift 2. We specifically avoided it because “ensure” is very much in the lexicon of pre and post conditions, and we want to reserve its use if/when we ever get there.

Good point! Looking forward to that :-)
I always liked Eiffel's handling of pre and post conditions.

-Thorsten

···

Am 26.10.2016 um 18:41 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

On Oct 26, 2016, at 1:11 AM, alessandro aresta <performerstone@gmail.com> wrote:

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

15

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 the interpretation…

guard: x > 0 else { return }

This now reads as: *This is a guard: x must be greater than zero, otherwise
return*. The only issue is it has the same syntax as a break-label so
becomes potentially ambiguous/confusing. Is there another way that could be
achieved?

[1] For larger changes, but I think some of the arguments against breaking
changes are weak for smaller changes/refinements.
​

···

On Thu, 27 Oct 2016 at 13:31 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:

On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Oct 26, 2016, at 1:11 AM, alessandro aresta <performerstone@gmail.com> > wrote:

Ensure is more comprehensible, guard is for sure "always" been there in
older languages... could it be kind of aliased somehow?

No, we don’t introduce needless aliases for keywords like this.

What about allowing internal non-type aliases?
    alias ensure = guard //can't be public
I know it's kinda encroaching on "macro" territory, but can't we already
do simple text substitutions by importing a #define from C? Would allowing
non-type aliases really be any different?

It'd address the concerns raised by I think nearly all of the
"term-of-art" vs "term-of-English" proposals. Prohibiting aliases from
being declared as `public` would *guard* the language's namespace, and
*ensure* that it doesn't get polluted with every library author's
favorite alternate spelling(s).

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

16

This would just risk more confusion I think when mixing and matching code that uses one or the other. Personally I think that guard is fine, while ensure reads a bit better I like that guard sounds more authoritative, which suits its requirement to return/break/continue.

···

On 27 Oct 2016, at 13:31, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Oct 26, 2016, at 1:11 AM, alessandro aresta <performerstone@gmail.com <mailto:performerstone@gmail.com>> wrote:

Ensure is more comprehensible, guard is for sure "always" been there in older languages... could it be kind of aliased somehow?

No, we don’t introduce needless aliases for keywords like this.

What about allowing internal non-type aliases?
    alias ensure = guard //can't be public
I know it's kinda encroaching on "macro" territory, but can't we already do simple text substitutions by importing a #define from C? Would allowing non-type aliases really be any different?

It'd address the concerns raised by I think nearly all of the "term-of-art" vs "term-of-English" proposals. Prohibiting aliases from being declared as `public` would guard the language's namespace, and ensure that it doesn't get polluted with every library author's favorite alternate spelling(s).

17

You could make that argument about any code that "wraps" or duplicates stdlib/language behavior. That doesn't mean you shouldn't be able to use it. I'm not in front of my computer, so I can't double-check, but I'm pretty sure you can already put "#define ensure guard" in a C file and import it... This would just make the syntax nicer.

Come to think of it, that means this would be out of scope for phase 1.

- Dave Sweeris

···

On Oct 27, 2016, at 08:09, Haravikk <swift-evolution@haravikk.me> wrote:

On 27 Oct 2016, at 13:31, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 26, 2016, at 1:11 AM, alessandro aresta <performerstone@gmail.com> wrote:
Ensure is more comprehensible, guard is for sure "always" been there in older languages... could it be kind of aliased somehow?

No, we don’t introduce needless aliases for keywords like this.

What about allowing internal non-type aliases?
    alias ensure = guard //can't be public
I know it's kinda encroaching on "macro" territory, but can't we already do simple text substitutions by importing a #define from C? Would allowing non-type aliases really be any different?

It'd address the concerns raised by I think nearly all of the "term-of-art" vs "term-of-English" proposals. Prohibiting aliases from being declared as `public` would guard the language's namespace, and ensure that it doesn't get polluted with every library author's favorite alternate spelling(s).

This would just risk more confusion I think when mixing and matching code that uses one or the other.

18

You’re really in pun mode today, David! :)

It's the best mode :sunglasses:

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 a guard: x must be greater than zero, otherwise return. The only issue is it has the same syntax as a break-label so becomes potentially ambiguous/confusing. Is there another way that could be achieved?

The ambiguity could be resolved by disallowing keywords as labels. I don't use them much, though, so I'm not sure how much that would affect readability.

- Dave Sweeris

···

On Oct 27, 2016, at 08:21, Jay Abbott <jay@abbott.me.uk> wrote: