Control flow expressions

Hi everyone,

Sorry if this isn't the correct place for this. I couldn't make a new thread in the Evolution category so this seemed like the next-best choice.

One language feature I'd really like to see come to Swift are control flow expressions, particularly switch expressions. I find that I routinely wind up in the following situation:

var priceOfItem: Int
switch colorOfItem {
    case .red: priceOfItem = 10
    case .green: priceOfItem = 12
    ...
}

This doesn't feel very Swift-y, does it? Java has recently introduced switch expressions which allow you to define a variable and initialize it via said expression, e.g.:

var priceOfItem: Int = switch colorOfItem {
    case .red: 10
    case .green: 12
    ...
}

You don't have to initialize the var with a dummy value anymore, or check for a value with a guard statement, etc.

I did see there was a thread that discussed this way back in 2015, but it didn't gain much traction. Control Flow Expressions

I'm wondering if there's more support for this now, five years later.

16 Likes

Unless I missed something more recent, I believe the last extensive discussion on this issue was Pitch: if/else expressions raised by @dabrahams last year. I'd recommend reading through that thread and summarizing any relevant aspects of the discussion here to make it easy to pick up where we left off!

Crud! I swear I searched before posting this. I was surprised to only see one discussion from five years ago and figured there had to be a more recent one but I couldn't find anything. The nifty New Topic tool that suggests similar threads didn't pick it up either. I also didn't realize this was on the commonly proposed ideas list... my fault entirely. I'll be more diligent in the future.

In the meantime I will take your suggestion and read through that pitch. Thank you for the link!

1 Like

I think that last year's thread demonstrated that there was significant interest in the feature despite its inclusion on the "Commonly Rejected" list. Also, before features are accepted there are generally several different tentative names that people use to refer to the feature, so it can be quite difficult to find all relevant discussions before posting—don't let that hold you back. I call that thread out specifically because there was extensive engagement from the community, as well as a good exploration of the existing alternatives and a decent case made for why the "commonly rejected" rationale may not be sufficient.

Just from a quick skim over the thread, I'm interested to know how recent language advancements (such as multiple trailing closures and improvements in closure type checking) affect the viability of some of the alternatives proposed in-thread (such as emulating control flow with a special function or wrapping if statements in an immediately-called closure, respective to the features mentioned earlier).

1 Like

I'm concerned about how function builder would affect (or be affected by) this feature.


I'm still -1 on this, but that's another story.

1 Like

I like this idea because I love being able to reduce duplicate or repetitive code. A switch where every case ends in a return always grates on me a little.

C# recently added switch expressions, except with a rather different syntax than a regular switch, which to me seems needlessly complicated.

1 Like

@Lantua, could you elaborate on your concerns re: function builder?

The current function builder transforms expressions and if-else blocks with separate mechanisms.

We’d have to transform if-else expressions with expression builders, and if-else statements with an if-else builders. I’m not sure if the implicated complexity will bring headaches to API authors and/or users. Especially now that you have fine-grain control over each path in if-else statement, but not in if-else expression.

A claim could be made that per-path transform is only needed because if path and else path have different type, which is not the case in if-else expression, and maybe some claim(s) should be made.

If anything, the important part is to keep in mind that the syntax is not only for imperative programming, but also declarative programming.