[Review] SE-0116: Import Objective-C id as Swift Any type


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager


(Charlie Monroe) #2

+1, but I'm not a big fan of the proposed Optional -> NSNull bridging which can cause various hard-to-debug issues with errors "NSNull doesn't respond to a selector -foo".

Most APIs that take "id" as an argument usually specify several types that the API accepts (e.g. arrays and dictionaries), but passing in NSNull is not acceptable. I believe this change would create confusion rather than eliminate it as is the goal of this proposal.

···

On Jul 5, 2016, at 5:45 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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


(Scott James Remnant) #3

+1

“AnyObject” has always seemed to me to be quite weird in Swift, since it considers classes to be special when compared to value types. Any move to lessen its use gets my vote.

A comment on Impact on existing code in the proposal: due to the nature of the bridging, it is still going to be very common in Swift to see this kind of construct:

  let mapOfThings: [String: AnyObject] = [ … ]

Since AnyObject conforms to Any, I don’t think this proposal will break that code, but should it suggest a fixit anyway since the author of the code is conforming to the interface, and not expressing an intent about AnyObjects here.

Scott


(David Rönnqvist) #4

   * What is your evaluation of the proposal?

+1. I find this to be a solid, well reasoned proposal.

I enjoyed seeing such a detailed Motivation and am looking forward to discussing the Related Proposals and Future Directions mentioned in this one.

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

Yes. Interoperability between Objective-C and Swift remains important and we don't want to be held back from creating the best possible Swift experience.

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

Yes.

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

I'm not familiar with (haven't used) libraries that bridge across languages without exposing the same types with the same naming and behaviors in both languages.

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

Read the proposal

- David

···

On 5 Jul 2016, at 17:45, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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


(Ben Langmuir) #5

Hey Joe,

I’m +1 on the overall direction, but I have some questions/concerns about the "Ambivalent dynamic casting from Any” section.

1) When you suggest that `x as String` succeeds but `x as NSString` fails, I assume this would only be true *after* SE-0083, since otherwise we’d be violating transitivity of `as` casts?

2) Have you considered the only allowing `as` casts to the bridged type (e.g. String) for values coming from `id` at the language level, but providing some guaranteed optimization that if you immediately convert to the ObjC class type (ie. NSString(x as! String)) we give zero-cost round-tripping? Would that be detectable? I think making `value as? NSFoo` fail or succeed depending on whether the value came from ObjC will be a source of subtle bugs. What if I have multiple sources of values - some from ObjC, some from Swift - and stuff them into an [Any].

Ben

···

On Jul 5, 2016, at 8:45 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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


(Joe Groff) #6

Thanks for the feedback, everyone. I revised the proposal a bit in light of design, implementation, and scheduling discussions we've had in the process of implementation:

https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md

  • Subset out conditional ambivalent dynamic casting from the proposal. We don't have time in Swift 3 to implement or evaluate this.
  • Move NSObjectProtocol and NSValue/NSNumber bridging to future directions. These can be done additively.

The original revision of the proposal is here:

https://github.com/apple/swift-evolution/blob/b9a0ab5f7db4d3806c7941a07acedc5f0fe36e55/proposals/0116-id-as-any.md

-Joe

···

On Jul 5, 2016, at 8:45 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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


(Joe Groff) #7

+1, but I'm not a big fan of the proposed Optional -> NSNull bridging which can cause various hard-to-debug issues with errors "NSNull doesn't respond to a selector -foo".

I'm not proposing that particular mapping as part of this proposal, only as a potential future direction. However, these issues should be avoided by dynamic casting type checks. An untyped NSArray that contains NSNulls would come into Swift as an [Any], and would fail to dynamically cast to [Foo]. You'd have to cast it to [Foo?], which would force you to handle the NSNulls as Swift nils.

-Joe

···

On Jul 5, 2016, at 9:06 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

Most APIs that take "id" as an argument usually specify several types that the API accepts (e.g. arrays and dictionaries), but passing in NSNull is not acceptable. I believe this change would create confusion rather than eliminate it as is the goal of this proposal.

On Jul 5, 2016, at 5:45 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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

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


(Charlie Monroe) #8

+1, but I'm not a big fan of the proposed Optional -> NSNull bridging which can cause various hard-to-debug issues with errors "NSNull doesn't respond to a selector -foo".

I'm not proposing that particular mapping as part of this proposal, only as a potential future direction. However, these issues should be avoided by dynamic casting type checks. An untyped NSArray that contains NSNulls would come into Swift as an [Any], and would fail to dynamically cast to [Foo]. You'd have to cast it to [Foo?], which would force you to handle the NSNulls as Swift nils.

Ok, though my bigger concern was the other way around - passing accidently array of [Foo?] to an ObjC class that takes id as an argument.

But other than this, the proposal will make the code Swiftier and it is definitely the correct direction for Swift in general!

···

On Jul 5, 2016, at 6:37 PM, Joe Groff <jgroff@apple.com> wrote:

On Jul 5, 2016, at 9:06 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

-Joe

Most APIs that take "id" as an argument usually specify several types that the API accepts (e.g. arrays and dictionaries), but passing in NSNull is not acceptable. I believe this change would create confusion rather than eliminate it as is the goal of this proposal.

On Jul 5, 2016, at 5:45 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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

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


(Joe Groff) #9

Hey Joe,

Sorry Ben, missed this when you sent it a couple weeks ago.

I’m +1 on the overall direction, but I have some questions/concerns about the "Ambivalent dynamic casting from Any” section.

1) When you suggest that `x as String` succeeds but `x as NSString` fails, I assume this would only be true *after* SE-0083, since otherwise we’d be violating transitivity of `as` casts?

Right. I think we'll have to subset this part out of the proposal altogether and leave casting as is, though, due to time constraints.

2) Have you considered the only allowing `as` casts to the bridged type (e.g. String) for values coming from `id` at the language level, but providing some guaranteed optimization that if you immediately convert to the ObjC class type (ie. NSString(x as! String)) we give zero-cost round-tripping? Would that be detectable? I think making `value as? NSFoo` fail or succeed depending on whether the value came from ObjC will be a source of subtle bugs. What if I have multiple sources of values - some from ObjC, some from Swift - and stuff them into an [Any].

Yeah, John's looking into that as a general peephole.

-Joe

···

On Jul 8, 2016, at 11:19 AM, Ben Langmuir <blangmuir@apple.com> wrote:


(Daniel Resnick) #10

What is your evaluation of the proposal?

+1

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

Swift?

Yes. Passing value types to Objective-C APIs taking AnyObject requires
creating wrapper classes that store the value types. This change would
eliminate that workaround and allow for more flexible and idiomatic code
when using Cocoa APIs.

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

Yes, now that certain Objective-C types are bridgeable to Swift as value
types, this feels like a natural next step.

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

Quick reading.

···

On Tue, Jul 5, 2016 at 10:45 AM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote:

> On Jul 5, 2016, at 6:37 PM, Joe Groff <jgroff@apple.com> wrote:
>
>>
>> On Jul 5, 2016, at 9:06 AM, Charlie Monroe via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> +1, but I'm not a big fan of the proposed Optional -> NSNull bridging
which can cause various hard-to-debug issues with errors "NSNull doesn't
respond to a selector -foo".
>
> I'm not proposing that particular mapping as part of this proposal, only
as a potential future direction. However, these issues should be avoided by
dynamic casting type checks. An untyped NSArray that contains NSNulls would
come into Swift as an [Any], and would fail to dynamically cast to [Foo].
You'd have to cast it to [Foo?], which would force you to handle the
NSNulls as Swift nils.

Ok, though my bigger concern was the other way around - passing accidently
array of [Foo?] to an ObjC class that takes id as an argument.

But other than this, the proposal will make the code Swiftier and it is
definitely the correct direction for Swift in general!

>
> -Joe
>
>>
>> Most APIs that take "id" as an argument usually specify several types
that the API accepts (e.g. arrays and dictionaries), but passing in NSNull
is not acceptable. I believe this change would create confusion rather than
eliminate it as is the goal of this proposal.
>>
>>> On Jul 5, 2016, at 5:45 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>> Hello Swift community,
>>>
>>> The review of "SE-0116: Import Objective-C id as Swift Any type"
begins now and runs through July 11. The proposal is available here:
>>>
>>>
https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.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.
>>>
>>> What goes into a review?
>>>
>>> The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to 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,
>>>
>>> -Chris Lattner
>>> Review Manager
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

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