I agree that by having different implicit ending statements (i.e. break/return/etc.) based on context makes it more complicated and less intuitive. Having said that, I do think that an implicit ‘return’ with/without a warning (rather than an error), gives people the opportunity to either exclude or include the ‘return’ statement if they wish. This give the developers the optionality to choose what is the better code design based on their personal preference (like one liner ‘if’s with or without brackets). I do think that if there is a warning, it should also have the option to be suppressed.
If you think the ‘return’ statement has to be stated, then why don’t we enforce a ‘return’ statement at the end of void functions? ‘guard’ should be treated and recognized in a way that ‘return’ is obvious, like void function endings. I agree that because it is a new thing, it might take time for people to see it as obviously as that. Looking at the previous requests for this, it seems like it is a pain point for several developers who see it redundant as most of their “guard”s use the same “return” or “return nil” statement. I think this current solution gives both ends the needed flexibility. Yarden On June 20, 2016 at 5:29:17 PM, Dany St-Amant ([email protected]) wrote: Le 20 juin 2016 à 02:30, Yarden Eitan via swift-evolution < [email protected]> a écrit : ... My proposal is to allow for an implicit return when no ending statement is provided. We could take this one step further and have the compiler aware of it’s most inner scope and see if it is a while loop for example and implicitly allow a break. But I think at least as a first step, by having an implicit “return” we are saving the repetitiveness on many cases where there are multiple guard statements and the return from them is obvious. A 'guard' in a loop can commonly be used with either 'continue' or 'break', the compiler would not be able to guess your intent. And whatever default would be selected, it would be the wrong one for many scenarios. The 'return' is an important keyword which, I think, should not be obfuscated as one often need to quickly find all exit point of a function, when debugging/analyzing code. This goes along the line of the Swift “switch” statement, which doesn’t follow it’s predecessors and force a “break” but rather it is already implicitly there. If you bring the consistency card, I would be more on the page of making 'break' mandatory and explicit in the 'switch'. Dany If this proposal is too much of a leap, an alternative is to allow an implicit return but provide a warning (not an error). This warning can be suppressed using an @implicitreturn prefix to the guard statement or something along those lines (@implicitreturn guard a = b else { print(“foo”) } ).
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
