That's not better than a myriad validator routines all slightly different?

No. The validation is applied only to the value, and only where required.

If I defined a 'string-that-can-only-contain-uppercase' type and a 'string-that-can-only-contain-decimal-digits' type and then later want to join my userids with their respective phone numbers for display, I have a type clash.

This is conflating type validation with value validation.

Traits

How do traits validate an lvalue assignment to a partital field.

eg. substr( $x, $start, $length ) = $str;

tieing

How does STORE gain access to the lvalue selection criteria from the lvalue sub call?

Same example. How do I know at STORE time, what part of the string is affected?

If I defined a 'string-that-can-only-contain-uppercase' type and a 'string-that-can-only-contain-decimal-digits' type and then later want to join my userids with their respective phone numbers for display, I have a type clash.

Only if one assumes that the various types don't have a stringify operator that will return a useful value. A bad assumption in Perl, I would think.

Personally, I think that an optional type system that allows as much granularity as I want is a great thing. Enforcing it everywhere an assignment is made is also a great thing. As such, it's one tool in my toolbox. It's certainly not going to be the only validation tool I provide.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

STORE is part of a class and called on an instance of that class. The criteria would be part of of the instance, stored when the lvalue sub instantiates the class. Where's the problem?

Traits by my latest understanding could be used to add hooks to a property.

conflating type validation with value validation

They are not separate in the first place, any more than compiled languages are separate from interpreted ones or hardware is from software. Read WhatAreTypes and ThereAreNoTypes and watch the tail-chasing.

Makeshifts last the longest.

Having you been reading what I've written? Or just picking out random phrases and responding to those. You have stopped trying to address the issues...and I am tired of repeating myself.

Lvalue subs as defined in P5 have--by the overwelming judgement of the opinions expressed on this site--fundemental issues with validation.

Type validation is no answer. You cannot replace everything you can do with:

die 'Bad value!'
    unless substr( $attr, $_[1], $_[2] ) =~ $regex;
[download]

with a type definition. Nor with a tie, because those parameters will not be available to it. Nor with a trait for the same reasons.

The only mechanism offered to correct this in P6 does not adaquately address those issues. Without some change to the muted solutions, the same problems will become enshrined forever in the trap of backwards compatibility.

They could be addressed now, before that comes to pass. But, if everyone buries their head in the sand saying "Larry's always right"--then they are ignoring history.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.