> On Oct 27, 2016, at 08:09, Haravikk <[email protected]> wrote:
>
>
>> On 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).
>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
