[Closed] Pitch: Explicit marker for autoclosure parameters

ksluder · 2023-05-21T13:18:15.963Z

The question is still, “Why?” @autoclosure exists to give API designers the power to defer evaluation of argument expressions. What is gained by giving clients the ability to spell these expressions as closures, and why is that gain worth introducing the ambiguity of whether the client-provided closure itself is then wrapped in an automatic closure?

tera · 2023-05-21T19:17:59.912Z

michelf:

D has the same concept (lazy parameters ) and it's likely that it was the inspiration for Swift because it works exactly the same.

Interestingly they used "lazy" even if "lazy argument can be executed 0 or more times".

GreatApe:

What you are suggesting is like first adding @autoinout

It's about consistency and established precedents. I'm applying the same line of reasoning used to defend @autoclosure feature existence in its current form ("brevity matters more than clarity at the point of use", "it requires discipline, but it is powerful", "let's not punish good users because of a few abusers", "if we didn't have this feature by now we'd introduce it now" to the similar features @autoinout and @autobinding. If the line of reasoning good for the former it should be as good for the latter, right?

ksluder:

@autoclosure exists to give API designers the power to defer evaluation of argument expressions.

Not autoclosures - that's what closures do by themselves. @autoclosures merely allow to disguise the call site by not having the { } symbols that we'd have to put otherwise:

precondition(denominator != 0, "Can't divide \(numerator) by zero")
logger.info("Starting division of \(numerator) by \(denominator)…")

vs

precondition { denominator != 0 } message: { "Can't divide \(numerator) by zero" }
logger.info { "Starting division of \(numerator) by \(denominator)…" }

GreatApe · 2023-05-21T19:47:14.256Z

@autoclosures merely allow to disguise the call site by not having the { } symbols that we'd have to put otherwise

Precisely. That's why it makes no sense to keep autoclosure if you require the call site to be annotated.

tera · 2023-05-21T19:52:48.121Z

I am not disagreeing with that, and suggesting that in alternatives #2 and #3.

michelf · 2023-05-21T20:15:39.665Z

tera:

Interestingly they used "lazy" even if "lazy argument can be executed 0 or more times".

It shouldn't be that surprising: lazy has an existing meaning in Swift where the initializer is run once on demand the first time the value is requested while D is a different language unencumbered by this precedent. Given lazy in D is older than Swift itself, it's likely Swift designers knew about it but found having two different meanings for lazy would be confusing and went for @autoclosure instead.

anon9791410 · 2023-05-22T04:15:44.045Z

ksluder:

“Why?”

@autoclosure should be a parameter wrapper. It's just a representation of a get accessor (with additional complexity from rethrows that I'm not going to address here). If it were used like this…

@propertyWrapper public struct Get<Value> {
  public var wrappedValue: Value { projectedValue() }
  public var projectedValue: () -> Value

  public init(wrappedValue: @autoclosure @escaping () -> Value) {
    projectedValue = wrappedValue
  }

  public init(projectedValue: @escaping () -> Value) {
    self.projectedValue = projectedValue
  }
}

func and(_ bool0: Bool, @Get _ bool1: Bool) -> Bool {
  bool0 && bool1
}

…then we would have the ability to choose how to utilize the get/value duality, which @autoclosure does not allow:

func expensive() -> Bool { .init() }
_ = and(true, expensive())
_ = and(true, $_: expensive)

However "projected parameter syntax" (or whatever that's called) cannot be used with operators (yet), and init(wrappedValue:) still requires the @autoclosure we have.

ensan-hcl · 2023-05-22T06:44:35.783Z

Considering the reasoning for explicit marker for @autoclosure parameters, in @tera's opinion, @Wrapper parameters should also be explicitly marked, right?

tera · 2023-05-22T20:13:00.719Z

The more I think about it the more alternative #2 is appealing ("Prohibit autoclosure parameters altogether"). Operators aside (which, btw, do not need @autoclosure feature as well, which I can expand later on), consider these examples:

precondition(denom != 0)
precondition{denom != 0}

precondition(denom != 0, "Can't divide \(num) by zero")
precondition { denom != 0 } message: { "Can't divide \(num) by zero" }

logger.info("Starting division of \(num) by \(denom)…")
logger.info{"Starting division of \(num) by \(denom)…"}

c.horizontalSizeClassValue(regular: foo(), compact: bar(), otherwise: baz())
c.horizontalSizeClassValue { foo() } compact: { bar() } otherwise: { baz() }

All we are gaining by having auto closures here is that we write the first lines instead of the second, and numerous of drawbacks mentioned above (lack of clarity at the point of use, potential for abuse, extra complexity in the compiler, etc). Doesn't look a win overall.

Avi · 2023-05-23T11:50:55.845Z

The declaration for precondition() is

public func precondition(_ condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = String(), file: StaticString = #file, line: UInt = #line)

Note that the last two parameters are not autoclosures, nor is there any reason for them to be, since no one should ever be passing them.

tera · 2023-05-24T12:56:53.717Z

Avi:

The declaration for precondition() is

public func precondition(_ condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = String(), file: StaticString = #file, line: UInt = #line)

Yep. I changed "message" parameter to be named, otherwise it's less obvious:

precondition { denom != 0 } _: { "Can't divide \(num) by zero" }

IRT file / line being last parameters I don't think there's a problem: this still works:

precondition { denom != 0 } message: { "Can't divide \(num) by zero" }

and if file needs to be parametrised explicitly (as you rightly mentioned rarely needed), then either this will do:

precondition({ denom != 0 }, message: { "Can't divide \(num) by zero" }, file: "file")

or we change parameters order, putting file / line before the closure parameters:

precondition(file: "file") { denom != 0 } message: { "Can't divide \(num) by zero" }

rvenable · 2023-05-24T23:13:02.394Z

tera:

Question: is foo(42) being actually called here or not? If called - how many times?

As of now - we don't know the answer and that's a problem.

I think you should just code defensively and assume every parameter could be autoclosure.

So any time you rely on knowing how many times foo(42) is being called (which is probably not often), then assign it to a variable before passing it as a parameter. Then you know it will be called no matter what the underlying api uses.

austintatious · 2023-05-24T23:50:15.861Z

There are already major lacks of clarity at the use site in Swift that were accepted. Trailing closures, eliding return, property wrappers, inout to name a very few, ResultBuilders!

This thread is ultimately debating a (major?) source breaking change that would result in no major improvement to the language.

As with all of these lacks-of-clarity is serves its purpose and is resolved when simply reading the API.

anon9791410 · 2023-05-25T03:47:32.731Z

austintatious:

I think you should just code defensively and assume every parameter could be autoclosure.

I think this is the equivalent mindset involved with "implementation-detail property wrappers".

Because of that, I think the motivation behind this thread isn't in-line with language evolution. Instead, the main problem is that we don't have access to autoclosures as "API-level".

tera · 2023-05-25T12:37:56.638Z

austintatious:

There are already major lacks of clarity at the use site in Swift that were accepted. Trailing closures, eliding return, property wrappers, inout to name a very few, ResultBuilders!

Most of the mentioned examples do not contradict clarity over brevity rule (IMHO). If some feature does - we can and should fix it - ††. One feature at a time.

austintatious:

This thread is ultimately debating a (major?) source breaking change that would result in no major improvement to the language.

So this would be an improvement? At least someone agrees :)

And if we were consistent we would not see this as an improvement:

colour.getRed(red, green: green, blue: blue, alpha: alpha)

over the current:

colour.getRed(&red, green: &green, blue: &blue, alpha: &alpha)

or would we?

What makes us tolerate & in (1) and not tolerate { } in (2) in the following:

1. colour.getRed(&red, green: &green, blue: &blue, alpha: &alpha)
2. precondition { condition } message: { "message" }

As for the breaking change - we have precedents doing that, typically by deprecating the thing in question first over a few releases.

Swift API Design Guidelines clearly state as the very first two rules:

Clarity at the point of use is your most important goal.
Clarity is more important than brevity.

There are no exceptions here, such as "yes, but if the feature is so powerful-† and if we ask API designers to use it consciously with a great deal of discipline then these rules could be disregarded"-††.

† - which in case of autoclosure is not the case.

†† - Unless we change the API guidelines, basically removing the top two bullet points about clarity over brevity.

Granted, this is the API design, but having the core language feature that directly contradicts this API design rule is not wise still. About the only way to strictly adhere to the above API design rules IRT @autoclosure is not using autoclosure at all, and then autoclosure is as good as being removed from the language.

GreatApe · 2023-05-25T13:37:15.378Z

Let’s say that for some reason swift 6 introduced autoinout, which would let us write:

colour.getRed(red, green: green, blue: blue, alpha: alpha)

If i then proposed that we should require the callsite for autinout to add a decorator like %, would you say that this makes sense at all?

colour.getRed(%red, green: %green, blue: %blue, alpha: %alpha)

Or would you say that this completely defeats the purpose of autoinout, and that it would make no sense at all?

tera · 2023-05-25T13:52:44.985Z

This thread convinced me that the pitch alternative #2 (remove/deprecate autoclosure) is the way to go.

If we value brevity over clarity at the point of use, then:
- we introduce "auto-inout"
- we leave autoclosure as it is
- we remove the first two bullet points from the API design document (or change them to their opposite)
If we value clarity over brevity at the point of use, then:
- we deprecate "auto-inout" (if we had it)
- we deprecate autoclosure
- the first two bullet points in the API design document are left as they are

Otherwise we are inconsistent and must admit that we do as we please in one language area compared to another.

Jumhyn · 2023-05-25T14:43:43.632Z

IMO the cited examples so far of operator short-circuiting and assert-style functions are excellent examples of adhering to the API design guidelines while using @autoclosure.

Also, based on the responses in this thread so far from members of the Language Steering Group I don't really expect there to be any appetite for a source-breaking change in this area, and certainly not one as wide-reaching as "deprecate @autoclosure."

Even considering the possibility for API author abuse IMO it doesn't nearly fulfill the "active harm" standard we've generally held source breaks to.

Matt_McLaughlin · 2023-05-25T14:50:58.680Z

tera:

Otherwise we are inconsistent

Clarity, brevity and consistency are all things to balance - they’re design guidelines not design shackles. I’d find it disappointing if we dropped autoclosures for the sake of consistency when they’re extremely useful in a number of situations and harmful in an IMHO inconsequential number of situations.

Personally I’m not bothered by these sorts of inconsistencies in language design philosophy and rarely find arguments for consistency compelling in their own right.

tera · 2023-05-25T15:08:49.978Z

Jumhyn:

the cited examples so far of operator short-circuiting

Strictly speaking auto-closures are not required for operator short-circuiting behaviour.

Matt_McLaughlin:

when they’re extremely useful

I invite you to provide some killers examples when auto closures are extremely useful. So far we've seen just one non assert-like example in this thread, which doesn't seem to be too convincing or losing too much when written without auto-closures:

let value = collection.valueForHorizontalSizeClass(
    regular: foo(),
    compact: bar(),
    otherwise: baz()
)

vs

let value = collection.valueForHorizontalSizeClass {
    foo()
} compact: {
    bar()
} otherwise: {
    baz()
}

Ditto for the assert-like calls.

Personally I don't think this reaches a bar of introducing a new feature ("if we didn't have auto-closures would we introduce them now" test) especially combined with the "clarity wins over brevity" rule violation.

jayton · 2023-05-25T15:17:53.411Z

tera:

Personally I don't think this reaches a bar of introducing a new feature ("if we didn't have auto-closures would we introduce them now" test) especially combined with the "clarity wins over brevity" rule violation.

I’m mildly inclined to agree with this, but the criteria for removing a language feature are not the same as the criteria for rejecting a new feature, so the point is moot.