[SR-2384] remove NSUniqueObject

[lhoward]

NSKeyedArchiver uses an internal struct, NSUniqueObject to box unhashable objects so they may be used as dictionary keys. AnyHashable, if my understanding is correct, obviates the need for this.

[phausler]

The one differential here is that NSUniqueObject did allow non hashable items to be stored whereas AnyHashable conversion will not store a non hashable item

[phausler]

@swift-ci Please test linux and merge

[phausler]

@swift-ci Please test and merge

[lhoward]

The one differential here is that NSUniqueObject did allow non hashable items to be stored whereas AnyHashable conversion will not store a non hashable item

Not since aa504dc though.

[lhoward]

A bigger issue is whether we can encode non-NSObjects. Trying to do so causes some crashes, Any not supporting AnyHashable by default is one of them but there are a few others. Investigating. (I guess we don’t have this on Darwin because as far as ObjC is concerned, everything is a NSObject?)

[lhoward]

On 19 Aug 2016, at 5:50 AM, Luke Howard [email protected] wrote:

The one differential here is that NSUniqueObject did allow non hashable items to be stored whereas AnyHashable conversion will not store a non hashable item

Not since aa504dc though.

@phausler, we can fix this regression by boxing with _SwiftValue – does this make sense? It is only useful in conjunction with some other (pending) fixes to support encoding of non-NSObjects.

[parkera]

We don't need to encode non-NSObjects (especially not structs). It's not something supported on Darwin, at least.

[lhoward]

Ah, I thought the Any API change implied Darwin supported it. Well, there’s a patch in PR 574, see which bits are useful – in any case, there could be better error reporting for encoding non-NSObjects (owing to a bug it crashes before reporting that non-NSObjects cannot be encoded). Also, should value types (e.g. UUID) be transparently bridged?

Best to continue this on aforementioned pull request or SR-2416.

On 19 Aug 2016, at 2:18 PM, Tony Parker [email protected] wrote:

We don't need to encode non-NSObjects (especially not structs). It's not something supported on Darwin, at least.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #563 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAhCN9mpZPcBuNTEcFDuYQxdp0JdDqfiks5qhS6ZgaJpZM4JnKdt.

www.lukehoward.com
soundcloud.com/lukehoward

[parkera]

What'll happen is that the internal _SwiftValue class will be given to the keyed archiver, which will then throw an exception (I think) because it doesn't implement -encodeWithCoder:. So you'll still be allowed at compile time to pass it in (as you were before, because we didn't actually check for NSCoding conformance), but it'll fail at runtime.

[parkera]

As for the value types, we probably have some work to do here to covert them into their object types when passed to keyed archiver. @phausler was making sure that the swift-corelibs-foundation _SwiftValue class had the right functionality to do this bridging, I think. The keyed archiver code which takes Any arguments may have to check the type and do the bridging automatically. That is what the compiler is doing for us on Darwin.

[lhoward]

On 19 Aug 2016, at 2:25 PM, Tony Parker [email protected] wrote:

What'll happen is that the internal _SwiftValue class will be given to the keyed archiver, which will then throw an exception (I think) because it doesn't implement -encodeWithCoder:. So you'll still be allowed at compile time to pass it in (as you were before, because we didn't actually check for NSCoding conformance), but it'll fail at runtime.

This is for value types, right? What happens if you encode, say, [1, 2, 3] on Darwin, will it work or crash?

In the case of classes that do not explicitly subclass NSObject (but implement NSCoding), presumably these work on Darwin by implicitly subclassing NSObject (because NSCoding is @objc)? So in order to have source compatibility where ObjC is not available, we’d want to support arbitrary classes implementing NSCoding.

[lhoward]

On 19 Aug 2016, at 2:27 PM, Tony Parker [email protected] wrote:

As for the value types, we probably have some work to do here to covert them into their object types when passed to keyed archiver. @phausler https://github.com/phausler was making sure that the swift-corelibs-foundation _SwiftValue class had the right functionality to do this bridging, I think. The keyed archiver code which takes Any arguments may have to check the type and do the bridging automatically. That is what the compiler is doing for us on Darwin.

Right, I was a little uncertain as to which things the compiler does implicitly (and on which platforms). The patch in #574 will do this.

[parkera]

If you encode [1,2,3] on Darwin, it will be bridged to NSArray holding three NSNumbers, which will then encode correctly.

I'm not super concerned about supporting a use case of not subclassing NSObject. I'm fairly certain it fails for an internal implementation reason (NSKeyedArchiver puts a category on NSObject and expects all things to respond to that).

[lhoward]

On Darwin, if you do:

class Foo : NSCoding {
}

it will be implicitly a subclass of NSObject, right, because NSCoding is @objc? Whereas without the ObjC runtime this wouldn't be the case. That was the use case I was referring to.

[lhoward]

In any case, if we don't want to support this use case I'll at least clean it up so that it fatalErrors in a useful place (indicating the problem at runtime).

[parkera]

Ah, I see. Yah I'm still ok with not supporting that. =)

[lhoward]

When you have a chance please review #574 and see which bits you want me to ditch :)