This kind of sounds like the proposal to have implicit return in guard
statements.
I agree with John that this kind of feels incosistent and obscure.
An alternative that could be used everywhere though may look like this:
func myFunc() -> String {
autoreturn {
return "Hello"
}
if Date.today.isSunday {
return "Sunday"
}
}
The `autoreturn` would act as `defer` on paths that do not have a return
statement, would be applicable in any function (i.e. any return type allowed).
I can see this being useful if you need to return default value that needs to
have some further initialization and the method is quite long.
> On Jun 22, 2016, at 10:55 PM, John McCall via swift-evolution
> <[email protected]> wrote:
>
>> On Jun 22, 2016, at 1:36 PM, James Froggatt via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>> Welcome, Logan.
>>
>> Functions currently return the empty tuple, ‘()’, by default. Void is a
>> typealias to the empty tuple type. It is also possible to write ‘return ()’
>> explicitly, rather than just ‘return’. (This is generally a detail of the
>> language, so may be unfamiliar)
>
> It is more correct to say that it is illegal to reach the end of a function
> whose return type is not (). Falling off the end of a function that returns
> ()? will not implicitly return Optional.Some(()); it will produce an error:
>
> (swift) func foo() -> ()? {}
> <REPL Input>:1:20: error: missing return in a function expected to return
> '()?'
> func foo() -> ()? {}
> ^
>
> We could amend this rule to permit reaching the end of an optional-returning
> function, with the semantics of returning nil. I do not, however, think that
> would be a good idea; it turns simple mistakes into bugs, feels inconsistent
> in the language, and is unnecessarily obscure for readers.
>
> John.
>
>>
>> It is unclear in your proposal as it stands which (if any) a function
>> returning ‘()?’ would use as its default: (), or nil?
>> Would the ‘nil’ keyword still be required when writing return explicitly?
>>
>> While this does match behaviour present in other parts of the language, and
>> I see the benefit of having implicit returns in this otherwise
>> straightforward case, I'm struggling to decide as to whether this is worth
>> the extra complexity of having two orthogonal implicit return mechanisms.
>>
>> ------------ Begin Message ------------
>> Group: gmane.comp.lang.swift.evolution
>> MsgID: <[email protected]
>> <mailto:[email protected]>>
>>
>> I believe Swift should no longer require an explicit return on all functions
>> and instead do an implicit nil return if the function reaches the end of its
>> control flow and has an optional return type.
>>
>> This could be useful to keep code clean and compact, by only having to write
>> code for cases that our function handles and just returning nil otherwise
>> automatically.
>>
>>
>> Consider:
>>
>> func toInt(string : String?) -> Int?
>> {
>> if let s = string
>> {
>> return s.intValue
>> }
>>
>> //Make this return implicitly happen instead of requiring it.
>> //return nil
>> }
>>
>>
>>
>> This also very much goes along with the implicit return within a guard
>> statement that I have seen proposed. Here:
>>
>> func toInt(string: String?) -> Int?
>> {
>> guard let s = string else {
>> //this could be implicitly returned using the same logic, since the guard
>> means we have reached the end of our code path without returning
>> //return nil
>> }
>> return s.toInt()
>> }
>>
>>
>> These methods could be re-written as so:
>>
>> This could allow us to write the examples below much cleaner
>> func toInt(string : String?) -> Int?
>> {
>> if let s = string
>> {
>> return s.toInt()
>> }
>> }
>>
>> func toInt(string: String?) -> Int?
>> {
>> guard let s = string else {}
>> return s.toInt()
>> }
>>
>> // it would be even cooler if we could omit the else {} and make them not it
>> return by default. But that’s another thing all together
>> func toInt(string: String?) -> Int?
>> {
>> guard let s = string
>> return s.toInt()
>> }
>>
>>
>> Thanks for reading my first post to the Swift open source discussion board!
>> -Logan
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ------------- End Message -------------
>>
>>
>>
>> From James F
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
