Add an implicit return nil if function reaches end before return explicitly called


(James Froggatt) #1

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 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: <4AC6F31E-9E46-47B3-8CAE-B5EDD04043D5@gmail.com>

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

------------- End Message -------------

From James F


(John McCall) #2

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.

···

On Jun 22, 2016, at 1:36 PM, James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:

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: <4AC6F31E-9E46-47B3-8CAE-B5EDD04043D5@gmail.com>

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

------------- End Message -------------

From James F
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charlie Monroe) #3

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 <swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 1:36 PM, James Froggatt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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: <4AC6F31E-9E46-47B3-8CAE-B5EDD04043D5@gmail.com <mailto:4AC6F31E-9E46-47B3-8CAE-B5EDD04043D5@gmail.com>>

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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

------------- End Message -------------

From James F
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution