I'm simply saying that every time the desirability of the syntactic sugar of Lvalue subs comes up, in the vast majority of the responses, the inability to validate the assignment, is cited as the primary reasons people do not code their subs in that fashion. And that P5 reality should play some part in what becomes the P6 reality.
The technique of tieing the attributes in order to provide for verification has been muted over and over--and reject by most, over and over. In part because of the performance hit this entails. In part because applying that technique to every attribute of every class, either manually or through a generator module adds complexity that many feel outweights the advantage of the syntactic sugar.
I'm saying that the requirement to validate is so important (based on the overwelming strength of arguments here), that it should be codified into the language and provided by the language. If it can be done by the Perl programmer, it can be done by the code generator in a standardized manner that simplifies the life of every programmer writing classes--which in P6 is going to be nearly every programmer, nearly every time.
“Proxying” the sub (I think that's the wrong term) as you show is probably fine for trivial cases, but somehow it doesn't feel to me like you'll get far with that if the sub does anything even remotely complex.
Given the current design, the sub cannot do anything complex--only return an lvalue. Not even validate the value assigned to that lvalue.
Using a localised "stand-in" (proxy seems as accurate a term as any?), for the sub, means that the sub doesn't get called to do anything, unless the temporised value is finally 'realised' into becoming the permanent value.
Cheap, and efficient.
More efficient that calling the real sub in order to obtain a reference and localising that--especially if that sub does anything complex to obtain the value--like hitting the database with a long running query to retrieve the current value. Effort that would be entirely wasted if the value is going to be overwritten. Doubly so if the reference is going to be temporised and undone, and ultimately the value is never changed.
I'm saying that if the ability to temporise lvalue subs ,is the only reason for not allowing lvalue subs--by default, every mutator in every class in p6--to validate their assigments, then the mechanism I threw together above demonstrates that there is a simple, efficient alternative that could be transparently put in place by P6 itself that would negate that reason.
Better to temporise the sub transparently, on those (rare?) occasions where that is required, than force every programmer to tie every attribute of every class (whether through a module or not).
Let's face it. If we are forced to do the validation by employing a tie class, then we will rapidly get a Params::Validate::General...and a Params::Validate::Long...and a Params::Validate::(Short|Quick|Easy|Better|Formal|Clever) et al.
I'm saying that if the ability to temporise the lvalue is not the only reason for preventing classes from validating values assigned to their attributes, then whatever that other reason is--bring it out in the open and show us what has such a high priority that it overides the need to validate?
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.