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

[Joe Groff]

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

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