> On 20 Jul 2016, at 11:13, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Jul 19, 2016, at 11:06 PM, Dmitri Gribenko via swift-evolution >> <[email protected]> wrote: >> >> - I find it a little strange to see a mention of Objective-C, and a >> negation in `isUniquelyReferencedNonObjC`. For example, if we get C++ >> import, would we need to rename it to >> `isUniquelyReferencedNonObjCAndNonCXX`? I think that is the issue >> with negation. If we want to emphasize that the API will work only >> with Swift types, we can do something >> `isUniquelyReferencedSwiftReference`. But I would probably suggest >> that we just go with just `isUniquelyReferenced` and mention the >> Swift-only requirement in the documentation. > > I agree. > > What is the reason that isUniquelyReferenced(_:) doesn't work with > Objective-C? It doesn't seem like it'd be difficult to implement—you'd either > call -retainCount, or get it from the Objective-C runtime somehow, and then > test it against 1—so I assume there's a reason we don't. > > I ask because knowing that may help us figure out how to name it. For > instance, if the issue is that we can't rely on Objective-C reference counts, > we might reverse the sense of the call and name it `mayBeShared(_:)` or > `mayHaveOtherReferences(_:)`.
I'm kind of undecided too; in fact it's never been clear to me why this is even a global function at all. In my mind the best solution would be some kind of ReferenceCounted class protocol with a .isUniquelyReferenced computed property, thus eliminating the global function entirely. The pure-Swift base type would conform to this protocol and provide the ability to test its uniqueness directly, though a static method could also be provided for testing unknown types as well (but I feel this is a relatively uncommon case), and the protocol conformance could be added to an Objective-C, C++ and so-on base-types whenever these are possible. It also strikes me as odd that we have to specify a NonObjectiveCBase in any form (extension or function, doesn't really matter); I would think that a pure Swift base should be the default in most cases, with a distinction having to be made only when declaring public classes in a module with Objective-C bridging headers. In other words it feels strange that non-Objective-C is the exception, when the goal should be trying to write pure Swift code wherever possible. I don't know about anyone else, but I mostly only use NonObjectiveCBase on private types implementing copy-on-write behaviour, so my only use-case for isUniquelyReferenced is private to the module anyway, so shouldn't really raise an issue of whether it's Objective-C compatible. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
