>> Mainly, because simply saying "release" or "released" is a bit ambiguous to
>> me.Are you saying it *has been* released, or are you saying it *needs to be*
>> released?
>
> But nobody proposed "released" as a method name. In what way is "release"
> ambiguous? It's an imperative verb.
I guess you're right that "release" is unambiguous, but as you mentioned, it's
also strange to release a value and then use it.
I think what I'm trying to get at here is that I prefer to think of the
operations on Unmanaged as "explain to ARC how it should handle this object",
rather than "do some manual operations so that ARC will do the right thing".
Maybe the current Unmanaged design has shown the limitations of that approach,
though.
> But you applied "take" to both of them? One of them is idempotent while the
> other is not.
The preferred way to use Unmanaged is that you immediately convert it to a
managed reference without ever storing it or using it in any other way. That
means you should immediately call either the retain-and-return operation or the
don't-retain-and-return operation. Both of these should only ever be called
once. You may instead choose to keep the reference Unmanaged and manually
retain, release, and access it, but best practices discourage that.
Now, one of the preferred, do-only-once operations *happens* to be safe to
apply more than once, but I view that as an implementation detail. Both of them
*happen* to be implemented in the same way as manual operations
(`manuallyRelease()` and `object`), but I view that as an implementation
detail, too.
Honestly, I might be happier splitting an UnsafeReference type out of Unmanaged
and putting the manual retain/release stuff into that:
// Unmanaged is a high-level type for moving object references in and
out of ARC's control.
struct Unmanaged<T: class> {
func created() -> T
func gotten() -> T
// Also would have stuff for passing, which I haven't even
thought about yet
}
// UnsafeReference is a low-level type for manually managing the retain
count of an object.
struct UnsafeReference<T: class> {
init(_ object: T)
init(_ unmanaged: Unmanaged<T>)
var object: T
// Some or all of these might return T
func retain()
func release()
func autorelease()
}
This puts the discouraged manual operations off in their own type where they'll
be available to those who know about them, but not sitting right there on every
unaudited call.
>> (I kind of want to suggest that retrieving an object through these calls
>> should destroy the reference so it can't be used again, but I don't think
>> that fits with Swift's mutation model without turning
>> `Unmanaged`/`UnsafeReference` into a reference type and adding lots of
>> overhead.)
>
> Yes, there's no way to reconcile that with the safety offered by the
> recommended usage patterns, since you can't mutate an rvalue.
I thought so. That's too bad. (I wonder if the compiler can emit warnings
instead, though.)
>> (One possibility would be to have a single call with an enum parameter, like
>> `bridge(.Create)` and `bridge(.Get)`. This would let you use the regular
>> form of the verb.)
>
> There's no "bridging" going on here, though. This is simply "turn this
> unsafe thing into a safe thing in one of two ways"
The "bridge" here comes from the Objective-C bridging casts, but I think there
it's meant to refer to toll-free bridging, which is not what's happening in
Swift.
If the type name remains `Unmanaged`, then perhaps `manage(_:)` would be
better? (I don't like `managing` here because that again implies it's
side-effect-free and safe to call more than once.)
> So far, my personal assessment of this direction is that it's no better than
> what I proposed, and has several weaknesses I'd like to avoid. In fact, it
> seems very similar to and roughly as understandable as the current Unmanaged
> design. I recognize that this is a highly subjective judgement, so if others
> disagree with me, I'd really like to hear about it. This is a tough design
> space and ultimately, what resonates best with the community is likely to be
> the best choice.
I understand. I'm obviously struggling with this too, as you can see from how
much I'm changing my design based on your replies, rather than defending the
design as suggested before.
Ultimately, Unmanaged is an API for handling an abstraction failure. That's
inherently going to be tricky and subjective.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
