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

[David Sweeris]

> On Oct 27, 2016, at 08:09, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 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).
> 
> This would just risk more confusion I think when mixing and matching code that uses one or the other.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161027/e0ad71c7/attachment.html>