Pitch: Multi-statement if/switch/do expressions

Evolution Pitches
141

Fair enough - I’m becoming increasingly convinced of the pitch overall, including the specific choice of the keyword then.

However, there is one other alternative that I'd like to bring up before this ship sails.

This problem is of course solvable in normal functions, but I don't find it to be the best experience. Specifically, I find that having to declare all of my subcomponents before the final expression severely inhibits readability, because it is sort of the opposite of progressive disclosure: instead of getting to glance at the final result and look further down only if I'm unclear on the definition of one of the terms I see, I have to process the names and definitions of all the intermediate values first and then finally at the bottom I get to see the highest level expression.

Rather than making each branch of if/switch expressions basically like slightly differently flavored function bodies, it might be nice to provide a better solution to the problem of intermediate definitions that can be used in both contexts, but that doesn't require, for example, the introduction of a new return-adjacent keyword.

Inspired (again) by a post earlier in this thread by @esummers , here's a first draft of the idea:

let accessibleRepos: [Repo] =
    switch signedInEntity {
    case .companyMember (let employee, let company):
        employee
            .personalRepos
            .appending(company.publicRepos)
            .appending(
                isAdmin ? company.adminRepos : []
            ) where {
                var isAdmin: Bool {
                    company
                        .admins
                        .contains(employee.id)
                }
            }
    case .individual (let user):
        user.personalRepos
    }

The idea is more or less that expressions can be followed by where and then curly braces within which functions and computed properties can be added. The order of the declarations doesn't matter, and cyclical dependencies can be diagnosed the same as the unordered declarations that appear within types/extensions or at the global scope.

1 Like