# \[Returned for revision\] SE-0376 (second review): Function back deployment

**URL:** <https://forums.swift.org/t/returned-for-revision-se-0376-second-review-function-back-deployment/62374>\
**Category:** Announcements\
**Created:** [January 4, 2023, 1:26am UTC](https://forums.swift.org/t/returned-for-revision-se-0376-second-review-function-back-deployment/62374 "2023-01-04T01:26:52Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [January 19, 2023, 8:52pm UTC](https://forums.swift.org/t/returned-for-revision-se-0376-second-review-function-back-deployment/62374/14 "2023-01-19T20:52:11Z")

</div>

I'll repost my [views from the previous review](https://forums.swift.org/t/se-0376-second-review-function-back-deployment/61671/13), which haven't changed:

I happened to be working with this attribute today [when I posted this last year :] and wanted to register the feedback that only really occurred to me whilst I was doing so, which is that I think the original choice of `@backdeploy(before:)` was pretty clearly better than the newly proposed `upTo:`.

I understand the analogy with `PartialRangeUpTo`, but it seems irrelevant to the naming of this property. `PartialRangeUpTo` never appears to users and is really an implementation detail of the range expression infrastructure – a mechanic of how we make the `..<` prefix operator work. It is not a type to name other more visible parts of the language after.

The decision should instead be made based on what will be most obvious to readers wanting to understand the availability of a function, and in this case `before:` seems the better choice as it represents more natural English language usage for when the back-deployment functionality applies.

> [@SE-0376 (second review): Function back deployment](https://forums.swift.org/t/se-0376-second-review-function-back-deployment/61671/12):
>
> We already have visible parts of the language that use this terminology:
> 
> - [`prefix(upTo:)`](https://developer.apple.com/documentation/swift/array/prefix(upto:)) and `prefix(through:)`
> - [`stride(from:to:by:)`](https://developer.apple.com/documentation/swift/stride(from:to:by:)) and `stride(from:through:by:)`

This helped solidify my feeling that `upTo:` is a poor choice.

- `upTo:` is not a single consistent term used throughout the language, as demonstrated by `stride`
- it’s striking how much uglier the compound camel-cased word is when comparing it to `stride`’s `to:`
- there is a clear driver here that matters specifically for these two examples: the need to distinguish between “to” and “through”, that requires a matching pair of argument labels That does _not_ apply to the availability usage.

But more important than all of these is that “the function is back deployed up to iOS 13” is an unnatural phrasing. You just wouldn’t say it in normal use. Whereas “the function is back deployed before iOS 13” is entirely natural. This isn’t just hypothetical – someone I spoke to, looking at this for the first time yesterday, was confused by what it mean until I explained it. I believe this wouldn’t have been as likely with `before:`.

So it seems that we are sacrificing readability for consistency (and, given the comparison with `stride`, mixed consistency at best), which is the wrong way around.

---

_[View the full topic](https://forums.swift.org/t/returned-for-revision-se-0376-second-review-function-back-deployment/62374)._