> On Dec 18, 2015, at 6:18 PM, Janosch Hildebrand via swift-evolution > <[email protected]> wrote: > > I like `UnsafeReference` as the new name of the type and I think the basic > API is clearer than with `Unmanaged`. > The initializers are much better than the static methods and > `take(Un)RetainedValue()` were certainly less than ideal method names. > > >> On 18 Dec 2015, at 02:37, Dave Abrahams via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> The name of the release() method has been contentious. > > This is a hard one. I don't particularly like `release()` for this but I > can't really think of anything better either. > I think it's descriptive which is good but it will take some getting used to > as the "consuming" method although the documentation is pretty clear about > the semantics which is helpful. > > The `.releaseAndReturnObject` proposed by TJ feels a bit clearer but is also > a lot more verbose. > Also I don't think it would make anything clearer if I didn't already know > about the manual memory management terminology. > And something along these lines would also be bit more awkward to use if the > return values were then discarded, although the proposed `manuallyRelease()` > would take care of that...
I don't see any point in having "manuallyRelease()" if we already have "release()"; they'd do the same thing if you dropped the return value. >> We’re not sure about the terminology >> <https://github.com/dabrahams/swift/blob/6eb86b48d150342709da3f3be9c738df23382866/stdlib/public/core/UnsafeReference.swift#L27> >> (Unretained/Retained/Released) used to precisely describe the semantics of >> UnsafeReference. We’d like to know if these terms make sense to you or >> whether you have better ideas. > > Coming from Objective-C I find it makes sense. I also don't think the > terminology is a big issue here. If you know the concepts you're probably > able to map them to these terms and the documentation seems helpful in that > case. > > If, on the other hand, you are not familiar with manual reference counting > concepts I doubt this will be very helpful. > But I don't think that can be solved with different terminology but instead > requires more extensive documentation. > However I don't think the documentation for `UnsafeReference` is the place to > try to explain the whole concept and this is more of a topic for `The Swift > Programming Language` or a separate (advanced) tutorial or guide. > > I like that the documentation tries to lay out a clear path to follow if you > just want to get an object out of some un-annotated CF API but I can't really > personally judge how well that works for a novice. > > > One other approach to terminology that comes to mind would be to focus more > on the transfer of ownership into ARC as opposed to out of MRC. > Personally I often reason in that direction when thinking about the topic but > I can't see a way in which it would be helpful for the documentation or > method names... Yeah, doesn't give me any ideas for names, unfortunately. > >> We want to know whether the usage pattern recommended above works for you. > > For interacting with un-annotated CF APIs: Yes. > >> We want to know if the API is sufficiently broad or if there are things you >> currently get—and need—from Unmanaged that we’ve left out. > >> On 18 Dec 2015, at 03:05, Joe Groff via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> - `Unmanaged` has also been promoted as a solution for people who need to do >> manual reference counting, for performance or other reasons, so I think we >> might want to keep the 'retain()' method. Conveniently enough, >> `release()`-ing and dropping the return value would have the net effect of >> decrementing the refcount by one, though the admonitions about the >> `UnsafeReference` become invalid after that point wouldn't hold if you're >> using `release()` purely for that effect, so maybe >> `manuallyRetain()`/`manuallyRelease()` would be more appropriate for manual >> refcounting applications. > > As Joe mentioned, `Unmanaged` has a use for manual ref counting beyond > immediate transfer from un-annotated APIs. > > I have used it for performance reasons myself (~ twice) and while I think > it's a pretty small use case there isn't really any alternative. > If it would help I can also describe my use-cases in more detail. Yes please! > I don't think this use case even needs to be described in the documentation > for `UnsafeReference` and it's fine if its use is very much discouraged. > > Personally I prefer the proposed `manuallyRetain()`/`manuallyRelease()` over > plain `retain()`/`release()` as it clearly separates the returning and more > generally applicable `release()` from the MRC methods. `retain()` would > probably also have to return the object which would interfere with the max > safe usage pattern. I don't understand your last sentence; care to clarify? >> On 18 Dec 2015, at 03:05, Joe Groff via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> - The `bitPattern:` constructors should be between UnsafeReference and >> Unsafe[Mutable]Pointer<Void>, not COpaquePointer. Let COpaquePointer retire >> gracefully. > > Very much agreed. Please see my comment here <https://github.com/apple/swift-evolution/pull/44#issuecomment-165902471> Thanks again, -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
