[swift-evolution] Making `.self` After `Type` Optional

Tanner Nelson tannernelson at gmail.com
Thu Mar 10 11:15:24 CST 2016


I'm wondering if this mailing list is the best place to discuss the implementation details. The proposal PR was closed because the motivation was not clear. But it seems like we have sufficient motivation from the responses to this thread so far. 

I would much rather be pasting code snippets in GitHub comments with the nice syntax formatting.

> On Mar 10, 2016, at 11:14 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Mar 10, 2016, at 3:00 AM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 9 Mar 2016, at 19:23, Tanner Nelson via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> - Require spaces around infix operators and no spaces around generics
>> 
>> While I know some people’s preference is for spacing to be left to linters and other tools, I do think that requiring space around operators is a good requirement to make; it should make it easier for the compiler, and easier for readability, plus it actually fits with Swift’s goal of avoiding mistakes by making it harder to mistakenly use negation vs subtract and other weird cases (like this particular one).
>> 
>> I’d say that all operators taking two arguments should have whitespace on either side, while prefix and postfix operators shouldn’t be allowed to have trailing and leading space respectively (the latter may already be the case, I can’t check just now).
>> 
>> That said, I’d say that removing comparison operators from types make sense too, as I can’t imagine when you’d need to do this?
> 
> We really want this to be a parse-time disambiguation so that the grammar isn't dependent on name lookup like C is. Banning the '<' operator on types doesn't help because at parse time we don't even know whether we have a type reference or not.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160310/5c82a05e/attachment.html>


More information about the swift-evolution mailing list