Version 2 of the proposal https://github.com/aschwaighofer/swift-evolution/blob/remove_nonobjectivecbase_2/proposals/0125-remove-nonobjectivecbase.md
Which proposes to: - Remove `NonObjectiveCBase` and `isUniquelyReferenced<T: NonObjectiveCBase>(_ object: T)`. - Rename `isUniquelyReferencedNonObjC` to `isKnownUniquelyReferenced`. - Cleanup the `ManagedBufferPointer` API by renaming `holdsUniqueReference` to `isUniqueReference` and removing `holdsUniqueOrPinnedReference`. > On Jul 20, 2016, at 10:24 AM, Arnold Schwaighofer via swift-evolution > <[email protected]> wrote: > >> >> On Jul 20, 2016, at 10:12 AM, Arnold Schwaighofer via swift-evolution >> <[email protected]> wrote: >> >>> >>> On Jul 20, 2016, at 9:54 AM, Andrew Trick <[email protected]> wrote: >>> >>> >>>> On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer <[email protected]> >>>> wrote: >>>> >>>> >>>> The question is are they relying on the non-@objc post-condition when the >>>> API returns true? If they were to implement something like array they >>>> might. >>> >>> The conservative thing to do is not make that promise for now and address >>> need later if it’s important. Conservative makes sense to me given the >>> current level of confusion. >> >>>>> >>>>> That said, something like “isUniquelyReferencedNativeSwift” would work >>>>> assuming that’s semantically correct (“native" Swfit objects do not >>>>> inherit from NSObject). “isKnownUniquelyReferenced” would be fine with a >>>>> warning in the doc comment that it may always return false for objc >>>>> objects. >>>> >>>> >>>> Native swift objects are the ones that use native swift reference counting >>>> and don’t alias Objc class instances. That is at least how we have defined >>>> it at the SIL (Builtin.NativeObject vs Builtin.UnknownObject) level: >>>> >>>> >>>> * A ``Builtin.NativeObject`` may alias any native Swift heap object, >>>> including a Swift class instance, a box allocated by ``alloc_box``, >>>> or a thick function's closure context. >>>> It may not alias natively Objective-C class instances. >>>> >>>> >>>> I think at the language/stdlib level the “native” concept is >>>> implementation detail that is not witnessed other than with the non-@objc >>>> requirement of ManageBufferPointer and isUniquelyReferencedNonObjC, i.e >>>> at the language/stdlib level we call “native” "non-@objc”. Which IMO is >>>> more descriptive. >>> >>> I totally agree, but people can’t have it both ways. You can’t avoid a >>> negative in the name and refuse to define the positive nomenclature. >>> >>>> I understand the desire to remove Objc’ness from API names that can be >>>> used on platforms without ObjC. >>> >>> Me too. >>> >>> +1 forisKnownUniquelyReferenced, with clarifying doc comments >> >> >> Do we continue promise that “isKnownUniquelyReferenced” returns false for >> non-@objc objects in the comments? > > I think the conservative answer is yes. Since there might be clients relying > on the behavior. > > _______________________________________________ > 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
