`if` expression with opaque types and availability.

[zienag]

Description
SE-0360 introduced a possibility to return different types under #available condition. But I found that it doesn't work with if expressions introduced in SE-0380

Steps to reproduce

protocol P {}
struct S1: P {}
struct S2: P {}

// Compiles fine
func f1() -> some P {
  if #available(macOS 99, *) {
    return S1()
  } else {
    return S2()
  }
}

// error: Branches have mismatching types 'S1' and 'S2'
func f2() -> some P {
  if #available(macOS 99, *) {
    S1()
  } else {
    S2()
  }
}

Expected behavior
f2 compiles and behaves exactly as f1
Environment
swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang-5.9.0.128.108 clang-1500.0.40.1)
Xcode 15.0

[hamishknight]

I agree this does seem a little surprising from a user perspective. It should however be noted that:

func f2() -> some P {
  if #available(macOS 99, *) {
    S1()
  } else {
    S2()
  }
}

is implicitly:

func f2() -> some P {
  return if #available(macOS 99, *) {
    S1()
  } else {
    S2()
  }
}

not:

func f2() -> some P {
  if #available(macOS 99, *) {
    return S1()
  } else {
    return S2()
  }
}

i.e there's actually only a single return here

[ncgreene]

Hello, I'm interested in working on this issue. Is anyone else already working on this, or am I ok to continue?

[hamishknight]

I'm going to park this issue on myself for now as I'm not yet sure what we want to do about it. If we do decide to fix it, we need to decide whether it's something we should special case for function decl returns, or whether it's something we should support more broadly in e.g opaque bindings. It's possible this may need some Swift evolution discussion since as illustrated in my previous comment, the current behavior does align with what was proposed in both SE-0360 and SE-0380.

[zienag]

As I understand, #available is working now through some special runtime type, that lazily computes it's memory layout based on os version:

func f1() -> some P {
  if #available(macOS 99, *) {
    return (S1() as _f1_some_special_type)
  } else {
    return (S2() as _f1_some_special_type)
  }
}

Why not just to "cast" it in expressions too?

func f2() -> some P {
  return if #available(macOS 99, *) {
    (S1() as _f2_some_special_type)
  } else {
    (S2() as _f2_some_special_type)
  }
}

It's most likely not as simple as that, but there don't seem to be any fundamental complexities.

the current behavior does align with what was proposed in both SE-0360 and SE-0380.

Strictly speaking – yes, but from developer point of view it's very confusing. There are now three options what if can represent – simple old statement, function builder statement or expression. In two of them #available with some P is supported, but, for some obscure reason, not in expressions. Simple codestyle rule

functions with single if statement should be converted to expression form

becomes much more complex, and almost impossible to automate.