[swift-evolution] [Pitch] Giving functions default return values

[Xiaodi Wu]

On Wed, Jul 13, 2016 at 1:14 PM, Tim Vermeulen via swift-evolution <
swift-evolution at swift.org> wrote:

> I thought that was mainly about former proposals in the Github repo, but
> I’ll gladly bring this up again at a more appropriate time.
>
> To address your message: I wouldn’t really want guard <condition> else { }
> to be valid code. The default return value is simply returned if the end of
> the function body is reached and nothing has been returned yet. guard
> <condition> else { return } could possibly be allowed in case of a default
> return value, but definitely not an empty guard body. This wouldn’t cause
> any problems, would it?
>

This specific idea you're proposing has been brought up on the list
previously, I think maybe twice. Visual Basic was mentioned previously, in
case that would help you search through list archives. It has not been
previously received well, but if after looking through the archives you
feel it's still relevant to discuss, I'd also mention that post-Swift 3
would be more appropriate.


> On 13 Jul 2016, at 17:47, Charlie Monroe <charlie at charliemonroe.net>
> wrote:
>
> Hi Tim,
>
> the core team asked us to defer any discussion on post-Swift-3 related
> proposals.
>
> That said, there have been several discussion around this topic (in the
> past few months) and I believe the general attitude towards them was
> negative, due to it leading to statements such as
>
> guard <condition> else { }
>
> which
>
> a) doesn't express what will happen when the condition is not met, making
> the code hard to read
>
> b) can lead to bugs in code since the compiler makes sure that the flow
> doesn't continue beyond the guard statement and with default returns, this
> would compiler without a warning or an error:
>
> for obj in array {
> guard obj.meetsConditions() else {
> // Implicit return - most likely not intentional,
> // you most likely want "continue" in here
> }
>
> // ...
> }
>
>
> On Jul 13, 2016, at 4:57 PM, Tim Vermeulen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> This idea is purely additive and isn’t to be considered for Swift 3.
>
> Oftentimes a function has a very obvious default argument to fall back on.
> If the return value is optional, this is generally nil. If the return value
> is Bool, it’s probably `false`. Often this fallback value is returned at
> the end of the function, just to return something if nothing has been
> returned yet. For instance, consider this TreeNode class:
>
> class TreeNode<Element> {
>
>     var value: Element
>     var children: [TreeNode]
>
>     init(value: Element) {
>         self.value = value
>         children = []
>     }
>
>     func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool
> {
>         if try predicate(value) {
>             return true
>         }
>
>         for child in children {
>             if try child.contains(predicate) {
>                 return true
>             }
>         }
>
>         return false // 1
>     }
>
>     func first(where predicate: (Element) throws -> Bool) rethrows ->
> Element? {
>         if try predicate(value) {
>             return value
>         }
>
>         for child in children {
>             if let result = try child.first(where: predicate) {
>                 return result
>             }
>         }
>
>         return nil // 2
>     }
>
>     var leftMostDescendant: TreeNode? {
>         if let child = children.first {
>             return child.leftMostDescendant ?? child
>         }
>
>         return nil // 3
>     }
>
> }
>
> These code patterns are quite usual. If we could give default return
> values to functions, we could get rid of the final `return` statements:
>
> func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool =
> false {
>     if try predicate(value) {
>         return true
>     }
>
>     for child in children {
>         if try child.contains(predicate) {
>             return true
>         }
>     }
> }
>
> func first(where predicate: (Element) throws -> Bool) rethrows -> Element?
> = nil {
>     if try predicate(value) {
>         return value
>     }
>
>     for child in children {
>         if let result = try child.first(where: predicate) {
>             return result
>         }
>     }
> }
>
> var leftMostDescendant: TreeNode? = nil {
>     if let child = children.first {
>         return child.leftMostDescendant ?? child
>     }
> }
>
> The default return value shouldn’t be part of the function signature (i.e.
> it shouldn’t appear in interface files) because it’s an implementation
> detail, but right after the return type is probably the most natural place
> to put it (similar to default function parameters).
>
> Let me know what you think.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/02517968/attachment.html>