[Closed] Pitch: Explicit marker for autoclosure parameters

Evolution Pitches
, ,
62

Operator short-circuiting could work without autoclosures. We have a similar precedent already established:

func += (lhs: inout Int, rhs: int) { ... }

This operator doesn't require (or allow) & sigil being written explicitly on the argument:

&x += y // 🛑 error
x += y  // ✅ ok

although obviously for normal functions & symbol is required on inout arguments:

addAssign(x, y)  // 🛑 error
addAssign(&x, y) // ✅ ok

Note, we didn't have to have some explicit "@auto-inout" to support this behaviour.

Ditto could be the ruling for closure parameters of operators:

func && (lhs: Bool, rhs: () -> Bool) -> Bool {
    !lhs ? false : rhs()
}

x && { y } // 🛑 error
x && y     // ✅ ok
63

As @Jumhyn has said, with the caveat that he and I haven't consulted others in the steering group, I can be quite confident that we would not contemplate the removal of @autoclosure from Swift. I know folks who visit these forums infrequently may have some consternation that an active thread such as this reflects an active direction of exploration, so this bears clarification.

This is a misunderstanding of these design guidelines, and it's happened often enough that I wonder if we should reword them for (natch) clarity.

At the time the guidelines were introduced, Swift was much newer, and it was (correctly) understood that many people who were adopting the language would be coming from the Objective-C tradition. Use sites in Swift read very differently from those in Objective-C; at first glance, one of the key differences is that Swift is terser. A natural conclusion one might make would be: "If I want to write a 'Swifty' API, I ought to make my APIs very terse."

This particular line you quote from the API guidelines (and the rest of the guidelines) helps to answer the question: How terse? Notably, it does not say, "Do not try to make your Swift APIs more terse than Objective-C APIs." Also notably, it does not claim that terse APIs will be less clear than verbose APIs. Indeed, implicit in the wording of the guidelines is that we reject these unsaid things. Rather, the overarching point being made is that the designers of Swift chose a terse style because they found that a certain degree of terseness can help to improve clarity at the use site. They did not opt to make it even terser because they determined that going further would hinder rather than help with that goal.

The Swift language offers a lot of expressivity precisely so that authors who exercise a "great deal of discipline" can get their APIs just right. Features such as @autoclosure, as well as trailing closure syntax, custom operators, property wrappers and result builders, are all designed around that principle. Put another way, these features exist because there are strong use cases for which they are the best known solution to maximize clarity, and the API design guidelines are there to help authors know when to use these features to their maximum benefit. Yes, it does mean that the language has—and will continue to gain—features which if used carelessly will result in worse (sometimes, markedly worse) APIs than if those features did not exist.

11 Likes
64

Based on feedback in this thread the pitch was unsuccessful.

Author's priorities:

  1. The threshold of removing existing feature is exactly the same as the threshold of adding a new feature
  2. The litmus test: "if we didn't have this feature before would we introduce it?" should be the main decision factor IRT removing existing features.
  3. The order in which language features were introduced doesn't have any influence upon future decisions
  4. Language complexity has an upper bound (e.g. LOC of compiler + standard library or some similar measure). At a certain, well defined point to add a feature you'd need to remove a feature.
  5. Consistency & clarity are paramount, next follow safety, performance, brevity, next follow source and binary compatibility.

do not match Swift language priorities as of 2023.

The pitch is withdrawn.

1 Like