On Mon, Jun 20, 2016 at 10:04 PM, Yarden Eitan via swift-evolution < [email protected]> wrote:
> 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. > Swift, by design, does not permit if statements without braces. It also, by design, does not have optional warnings. > > 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? > A `guard` statement is a control flow statement. It indicates that you are prematurely exiting the scope, and therefore by design it requires you to explain how you intend to do so. > ‘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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
