[swift-evolution] Proposal to remove semicolons

[Erica Sadun]

cc'ing the list back in to catch up on this.

-- E

> On Mar 16, 2016, at 10:54 AM, Chris Wood <chris at interealtime.com> wrote:
> 
> I really need to remember the “reply to all” button for these mailing lists. *Facepalm* :)
> 
> Chris
> 
>> On Mar 16, 2016, at 4:25 PM, Chris Wood <chris at interealtime.com> wrote:
>> 
>> I suspect it does (haven’t tested it), but the chances of there being a function that returns Void and a line of code that returns Void are fairly good (especially in UI code).
>> 
>> Chris
>> 
>>> On Mar 16, 2016, at 4:16 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>> 
>>> Well that makes sense to me honestly unless you think there should be some condition that 
>>> a return value should at least start on the same line as the return keyword. Although you'd
>>> think the closure would know if it's -> Void or -> T and parse the return accordingly
>>> 
>>> -- E
>>> 
>>>> On Mar 16, 2016, at 9:37 AM, Chris Wood <chris at interealtime.com <mailto:chris at interealtime.com>> wrote:
>>>> 
>>>> Erica:
>>>> 
>>>> The return case is (supposedly) handled as a compiler warning. It does warn that code on following lines will be treated as an argument to the return call normally (it does in a simple test project or playground). Except in the code I’m working on, it didn’t warn and happily compiled (and there was much swearing as a result!)
>>>> 
>>>> That looks like a compiler bug, and I’ve filed a radar (25192157) already.
>>>> 
>>>> Personally I think the compiler warning (when it works) and a trailing semicolon is acceptable in this case (as there may be a time when I want arguments to ‘return’ on the next line for some obscure reason).
>>>> 
>>>> Chris Wood
>>>> 
>>>> 
>>>>> On Mar 16, 2016, at 3:30 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>>> 
>>>>> -1
>>>>> 
>>>>> I think end-of-line semicolons are ugly. I also think the decision to use them or not use them
>>>>> should be left to individuals and not enforced by the compiler.
>>>>> 
>>>>> In the current implementation a semicolon can be optionally added after any statement and
>>>>> is proactively used to separate statements on a single line. Changing the language to enforce
>>>>> what appears to be a style choice is not something I'd support.
>>>>> 
>>>>> The issue with the return needing a semicolon sounds odd to me. I'm curious as to whether
>>>>> that's something that needs fixing.
>>>>> 
>>>>> -- E
>>>>> 
>>>>> On Mar 16, 2016, at 9:25 AM, Chris Wood via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> A word of warning on this - I’ve just hit a case where an end of line semicolon is actually critical!
>>>>> 
>>>>> If you’re debugging and need an early exit from a function, you add “return” somewhere in the middle of the code. But return can take an argument, so the compiler takes the argument from the following line which you think won’t be executed. Bad things happen, followed by swearing.
>>>>> 
>>>>> So in that particular case, you do in fact need to write:
>>>>> 
>>>>> return;
>>>>> 
>>>>> There may be other edge cases where it’s necessary to explicitly mark the end of something in the same way.
>>>>> 
>>>>> Chris Wood
>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I submitted a PR with a proposal to remove the swift end of line semicolons.
>>>>> 
>>>>> It was rejected because i didn't discuss it here. So here i'm discussing it :)
>>>>> 
>>>>> My proposal is simple: remove the semicolons in the end of lines.
>>>>> It isn't needed and makes the code ugly.
>>>>> It must be decided wether to use it or not for every project we start in the coding style.
>>>>> 
>>>>> What do you think?
>>>>> 
>>>>> João Nunes
>>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160316/3d30a0fe/attachment.html>