cc'ing the list back in to catch up on this. -- E
> On Mar 16, 2016, at 10:54 AM, Chris Wood <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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 >>>>> <[email protected] <mailto:[email protected]>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
