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 <
[email protected]> wrote:
>
> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <
> [email protected]> wrote:
>
> On Oct 26, 2016, at 1:11 AM, alessandro aresta <[email protected]>
> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
