[swift-evolution] Proposal to remove semicolons
colin.cornaby at mac.com
Tue Dec 15 10:24:12 CST 2015
Yeah, that’s kind of where I’m at too. Both those things are handy for long term C developer muscle memory as well, and don’t really hurt things. I don’t have extremely strong feelings on this, but if what the Swift team is going for is a dropping of C holdovers, this seems like a candidate too.
> On Dec 15, 2015, at 12:11 AM, João Nunes <joao3001 at hotmail.com> wrote:
> In that case why did you accept to remove for loop c style and ++/-- operators? It is the same reasoning.
> Sent from my iPhone
> On 15 Dec 2015, at 06:56, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> On Dec 14, 2015, at 3:44 PM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>>>> On Dec 14, 2015, at 11:01 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> There are two different topics here, and I’d suggest exploring them separately.
>>>> - The semicolon within a line is a expressivity feature.
>>>> - The semicolon at the end of the line is accepted, but generally ignored.
>>>> Most people seem to be focusing on the second one. IMO, I think that it adds value to the language for people coming from semi-colon oriented languages or bouncing between multiple languages (that muscle memory takes awhile to break). OTOH, it is just syntactic noise (along with redundant parens in conditions and many other things), and so having a warning (probably opt-in) for it would make sense to me.
>>> This seems firmly in linter/style warning territory. Unlike with other features that are being removed in Swift 3.0, optional semicolons at the end of are utterly harmless: nobody is going to have to reason about them beyond “oh, I can ignore that.
>> I agree. I am missing the motivation for what harm they are causing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution