Hi there, I've been influencing the design of the currently proposed feature a lot during the pitch and review threads and it's my fault that
value property was renamed to
wrappedValue. I don't want to revise this change and strongly remain in favor of it. However I pointed out in the previous pitch thread that
wrapperValue should have a little impact on anything, but I meant this for the last design of
wrapperValue. Like @anandabits said, there is again a new surprise from @Douglas_Gregor in this iteration. It reminds me of the very first
delegateValue introduction during last review where that feature was not discussed during the original pitch.
$$ approach and access level
In general I like the proposal and the proposed feature, but I don't think I'd say the same about the new
$$ approach. I'm strongly against the solutions pitched in this review thread regarding the access control issues as well. The access level as proposed will be
private by default, while others in the thread would like to see an alignment of the access level with the wrapped computed property. I think non of these solution is ideal, because it again requires new rules we have to learn about access control behavior. Just remember the radioactive threads about access control on extensions and global members.
Making the stored property having the same access level as the wrapped property would be fatal as it means that one will almost always write explicitly the access level for the stored property.
public private(wrapper) var property: Value
This also would add more accidental exposures of the stored properties if the user forgets to properly configure it.
That said I think the default should remain
internal. This is the sweat-spot in Swift today and property wrappers should be no different. As soon as
access_level(wrapper) is implemented everyone who want the wrapper to be hidden can do so. This is just a matter of time and should not increase the cognitive load on the user, as the access control is already confusing to some community members.
In this section I started describing my concerns regarding
$$ approach but then discussed the future direction of the access level. That was intentional, because with
access_level(wrapper) we wanted to change the access of the stored property. However now we have two new properties, one prefixed with
$ and the other with
$$. We're in an unlucky situation now, because it's not clear anymore what
access_level(wrapper) will do and how to control the exposure of both properties. Therefore I would revise this surprising change and use the previous design where the whole stored property becomes unaccessible if a special member is present that shadows its access.
As I said above already, I'm the one responsible for the renaming of
wrappedValue. I still think this was a good move because it does indeed avoid conflicts with
@dynamicMemberLookup types, especially if those are also property wrapper types.
value is too generic and is used widely, so the collisions will definitely happen a lot if we don't call the property differently. (Since SwiftUI has a property wrapper called
State that returns another type that uses
@dynamicMemberLookup, the collision with
value in view models is nearly inevitable.)
wrappedValue on the other hand describes well its semantics and also signals to the user that it's likely to be related to
@propertyWrapper attribute. Therefore I strongly think we should keep that property name here.
wrapperValue however was just a rename that happened during the transition from property delegates to property wrappers. A previously called
delegateValue property was simply aligned to
wrapperValue. I mentioned that I had little to no concerns about the name difference which was okay with the previous design without
$$. However right now I also think that the difference in the naming is too small and very hard to spot. I read the previous posts and there is only one name that caught my attention. @gwendal.roue pitched
My personal opinion on
associatedValue is that it's a little too magical as it does not describe it's purpose on a property wrapper type. You can ask yourself: "The property wrapper has an associated value, but what for?"
However the naming scheme was almost perfect from my point of view. As @Chris_Lattner3 pointed out above, we could require a more "lexically different" name for that feature that will standout but also remain describing well the semantics, just like
I propose to revise
R) and rename it to
Mistakes in the proposal
As noted by @hartbit the current proposal has some oversights. I pushed a PR to fix them.
What is your evaluation of the proposal?
I support the proposal.
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
Even though Swift tends to fit a lot of value into attributes these days I think this particular feature is worth it, but we should be careful in the future with other features to not to overflow the attribute syntax too much.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I participated in every pitch and review thread of the proposal and influenced the design of the feature.