[Review] SE-0064: Referencing the Objective-C selector of property getters and setters

Evolution Announcements
1

Hello Swift community,

The review of SE-0064 "Referencing the Objective-C selector of property getters and setters" begins now and runs through April 12, 2016. The proposal is available here:

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

Reply text

Other replies
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

Thank you,

Doug Gregor

Review Manager

2

What is your evaluation of the proposal?

Strong yes.

Is the problem being addressed significant enough to warrant a change to Swift?

At Delicious we wrote a huge ugly macro set to define properties in a special way so we could make key paths safely:

// Declares a safe-KVC-accessible property
// Use as: @property (opts) MyType KVC(*name);
// Use as: @property (opts) MyType KVC2(*firstName, *lastName);
#define KVC(a) \
    a; SAFE_KVC(a)

#define SAFE_KVC(NAME) \
    void NAME ## $DMSafeKVC(void)

#define K(x) \
    __builtin_choose_expr(sizeof(&x ## $DMSafeKVC), @#x, @"_NOT_A_KEY_")

So you could then use K(title) for example in your code and get what would now be #keyPath(title) in this proposal.

And we also had:

#define KeyPath(...) \
    DMMakeKeyPath(__VA_ARGS__, nil)

NSString *DMMakeKeyPath(NSString *firstKey, ...)
{
    NSMutableArray *keyArray = [NSMutableArray arrayWithObject:firstKey];
    va_list varargs;
    va_start(varargs, firstKey);
    NSString *nextKey = nil;
    while ((nextKey = va_arg(varargs, __unsafe_unretained NSString *)))
        [keyArray addObject:nextKey];
    va_end(varargs);
    return [keyArray componentsJoinedByString:@"."];
}

So we could make paths.

But this whole system was ugly as heck to read and required to you use ugly macros when defining properties AND when making key paths, so I wouldn’t use it again if I had to do it all again. I’d just like to demonstrate crazy lengths people have gone to to get SOME of this functionality.

···

—

I am curious how this proposal integrates with “KVO2.” Not that we’re talking about that here, but it’s something I imagine Apple is thinking about, so I’m not sure how much value my opinion is without knowing what’s coming.

(As an aside, gosh it’d be nice if other groups writing APIs had such a wonderful review process like the Swift group.)

Does this proposal fit well with the feel and direction of Swift?

I think so. Swift is about safety, and this make key paths much safer. And more readable as key paths instead of as strings.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The horrifying one we wrote was much inferior yet we shipped a hundred thousand lines or so on it.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading. I’m not sure if everything in it is actually implementable and I don’t really care what the syntax is, I just want a way to do this cleanly.

Your pal,
-Wil

3

What is your evaluation of the proposal?

+1

Is the problem being addressed significant enough to warrant a change to

Swift?

Yes, with reservations. The proposal itself mentions that this may be a
temporary solution, and while I believe temporary solutions tend to add
more complexity over the long-term, and tend to end up being
not-so-temporary, I think interfacing well with Objective-C in a type safe
manner is important.

Does this proposal fit well with the feel and direction of Swift?

Yes, I would consider this to be a natural extension of SE-0022. In fact, I
think SE-0022 isn't really complete without this.

If you have used other languages or libraries with a similar feature, how

do you feel that this proposal compares to those?

There are two ways to think of this feature: As a worse alternative to
lenses, and as a more type-safe mechanism for interoperating with
Objective-C.

The proposal already covers the first, acknowledging that lenses are
out-of-scope for Swift 3.

As for the second, I have used other languages with Objective-C bridges,
and all of them dealt with this problem by simply using foo for the getter,
and setFoo: for the setter. This approach has the advantage over SE-0064 of
not requiring any additional overloads, and I'm not quite sure why SE-0022
wasn't just implemented this way to begin with. Because it keeps the
language simpler, I probably would have advocated for this approach, but I
don't think the impact is particularly large, and since SE-0064 is already
at the proposal stage, it's probably just water under the bridge at this
point.

How much effort did you put into your review? A glance, a quick reading,

or an in-depth study?

I read through the proposal and the previous two threads, and thought about
it for a few minutes.

···

On Thu, Apr 7, 2016 at 1:57 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0064 "Referencing the Objective-C selector of property
getters and setters" begins now and runs through April 12, 2016. The
proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md

Reply text

Other replies

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

   - What is your evaluation of the proposal?
   - Is the problem being addressed significant enough to warrant a
   change to Swift?
   - Does this proposal fit well with the feel and direction of Swift?
   - If you have used other languages or libraries with a similar
   feature, how do you feel that this proposal compares to those?
   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

4

What is your evaluation of the proposal?

+1

Is the problem being addressed significant enough to warrant a change to Swift?

Yes. I agree with Michael Buckley that this feels more like an oversight in SE-0022 rather than a completely new thing.

Does this proposal fit well with the feel and direction of Swift?

Yes. I think it makes sense to use explicit getter/setter parameter names, as opposed to relying on the ObjC-based foo/setFoo: conventions. While the lines between property accessors and methods are blurry in ObjC, they are different things in Swift. I’m aware that this feature requires ObjC under the hood, but that’s not something you need to know when creating a selector.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Well, ObjC… I’ve explained the difference above.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve read the proposal and the previous review.