SE-0362: Piecemeal adoption of future language improvements

Evolution Proposal Reviews
32

As I mentioned previously, I am very much in favor of the proposal overall, but with some feedback and suggestions on the exact details.

I don't think that the 'has' prefix in #if hasFeature() makes the condition more clear and if additional conditions are added with the has prefix as pitched, the prefix makes these conditions more difficult to read.

All but one of the existing compilation conditions essentially omit the verb ‘is’:
#if compiler(>=5.7)
#if os(macOS)
#if arch(arm64)
#if swift(>=4.2)
#if targetEnvironment(simulator)

The one remaining condition is difficult to express without the verb ‘can’ because it is difficult to come up with a single word to indicate importability:
#if canImport(UIKit)

The use of ‘can’ avoids having to use an awkward and less clear construction such as #if importable(UIKit).

For me, this proposed new condition is much closer to the first set of existing conditions above. I think that just as an ‘is’ prefix hasn't been required to clarify the existing conditions, a ‘has’ prefix doesn't add clarity to the proposed condition,

Since the existing conditions have not proved to be confusing:
#if os(macOS)

I don't believe omitting the prefix makes the code less clear or that including it would make the code more clear:

#if feature(ImplicitOpenExistentials)
  f(aCollectionOfInts)
#else
  f(AnyCollection<Int>(aCollectionOfInts))
#endif

Although not part of this proposal, the proposed naming convention is also used in a current pitch to conditionally compile based on attribute availability. For me, the following code is very clear without the prefix:

#if attribute(preconcurrency)
@preconcurrency
#endif
protocol P: Sendable { 
    func f()
    func g()
}

In addition to not seeming to add much additional clarity, if multiple conditions begin with 'has', the prefix becomes visual noise that must always be scanned through to get to the actual thing being conditionalized.

1 Like