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

[Jay Abbott]

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 at swift.org> wrote:

>
> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Oct 26, 2016, at 1:11 AM, alessandro aresta <performerstone at 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 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/20161027/c399f685/attachment.html>