> 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] <mailto:[email protected]>> wrote:
>
>> On Oct 26, 2016, at 1:11 AM, alessandro aresta <[email protected]
>> <mailto:[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. Personally I think that guard is fine, while ensure
reads a bit better I like that guard sounds more authoritative, which suits its
requirement to return/break/continue.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
