For what it’s worth, I agree with Dmitri on the naming of this function. I think we should find a way to give it a name without “NonObjC” in it.
- Tony > On Jul 20, 2016, at 8:15 AM, Arnold via swift-evolution > <[email protected]> wrote: > > > > Sent from my iPhone > >> On Jul 20, 2016, at 6:50 AM, Dave Abrahams <[email protected]> wrote: >> >> >>> on Tue Jul 19 2016, Dmitri Gribenko <gribozavr-AT-gmail.com> wrote: >>> >>>> On Tue, Jul 19, 2016 at 10:51 PM, Chris Lattner <[email protected]> wrote: >>>> The review of "SE-0125: Remove NonObjectiveCBase and >>>> isUniquelyReferenced" begins now and runs through July 22. The >>>> proposal is available here: >>>> >>>> >>>> https://github.com/apple/swift-evolution/blob/master/proposals/0125-remove-nonobjectivecbase.md >>> >>> I like the API simplification. A few thoughts that I have after >>> reading the proposal that could take the simplification it even >>> further: >>> >>> - 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`? >> >> Only if we were unable to determine that CXX imports were >> uniquely-referenced. >> >>> 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`. >> >> That's not really the point. The point is to find out whether it's >> *known* to be a unique reference. False negatives are part of the >> game. >> >> isKnownUniquelyReferenced >> >> would work. > > > This would be a change to the semantics of the API. Currently, you can rely > on -- and is documented as -- that if it returns true you can assume the > reference points to a non-@objc instance. > > Users may be relying on this behavior. > > Do we want to add an isNativeSwiftReference API? > > >> >>> But I would probably suggest that we just go with just >>> `isUniquelyReferenced` and mention the Swift-only requirement in the >>> documentation. >> >> It's not a requirement, as in “precondition.” The point of having >> `NonObjC` in this API is actually that it *does* work on ObjC >> references, by returning false. >> >>> - I find the use of different names in `isUniquelyReferenced()` and >>> `ManagedBufferPointer.holdsUniqueReference()` to be strange. Why not >>> call the latter `ManagedBufferPointer. isUniquelyReferenced()`? It is >>> true that we are not checking that pointer is not uniquely referenced, >>> if we want to emphasize that, maybe something like >>> `ManagedBufferPointer.isBufferUniquelyReferenced()` or >>> `isPointeeUniquelyReferenced()` will work? >> >> isUniqueReference >> >> would work for ManagedBufferPointer. >> >>> The reason why I'm suggesting this is that `isUniquelyReferenced` and >>> `holdsUniqueReference` don't immediately strike me as performing the >>> same operation, the immediate impression I get is that these >>> operations are related, but subtly different, and it is not obvious >>> what the difference is (but after reading the docs I figure out that >>> there is no difference... until I need to use these APIs again). >>> >>> - We have `ManagedBufferPointer.holdsUniqueOrPinnedReference()`, but >>> don't have an equivalent free function `isUniquelyReferencedOrPinned` >>> (we actually have one, but it is internal). Do we need a public one? >>> If we do, we could as well add it as a part of this proposal, while we >>> are cleaning up this library subsystem. >> >> Maybe, but it's not crucial. >> >> -- >> Dave > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
