Another typechecking concept would be "I'm assigning a value of the type I want to constrain this to, use that type".
This might be the right sense for the word TYPED.
>> x: typed 1020
== 1020
>> x: 304
== 304
>> x: "string"
** PANIC: X is typed [integer!], tried to assign ~{text!}~
And maybe CONSTRAIN is used for assignments. It might even be better to do it on the outside:
constrain [integer! tag!] x: 1000 + 20
So it would be arity-3, quote the SET-WORD and take its third parameter evaluatively, then do the dual assignment.
It could be variadic, like LET, and allow you to constrain without assigning.
constrain [integer! tag!] x
Maybe it should use a $ on that so you get a better idea of what's going on?
constrain [integer! tag!] $x
Though may be not. The reason LET doesn't do it is that let [$x y]: pack [1 2] means "don't create a new variable for X, only Y. So presumably let $x needs to be consistent with that.
(I doubt it would be very frequent you'd want to use the non-assigning form.)
So :: is available now, as a WORD! (just a weird one you can't put in CHAIN!s)
(As an aside, ~~ is no longer available, as it is a quasi-blank of two space characters. You can dialect it, but its evaluator behavior is fixed to produce its antiform...although RebindableSyntax for QUASIFORM! could change that...)
And I've described the possible backdoor mechanic for putting unlifted states in a PACK! and having that be the way to assign "duals".
checked: 0 :: [your! types! here!]
checked: [your! types! here!] :: 0
If this were to be done, I think I like it better when the types are after. It sort of follows that news-story writing principle that you don't want to mislead people who only read the first part.
There's a bit of an issue if the value is on the left, due to infix... but you can make the operator INFIX:POSTPONE and it should work.
Think I'm going to have to pan this notational concept, due to what it does to the logic of locals gathering. It makes it not as easy to spot things that need to be collected. Having a more complex rule is not desirable--we need to be able to spot the SET-WORD.
Also, it's more contentious with dialected function calls.
TYPED, CONSTRAIN and :: could probably cover most cases, and all authorable in usermode... with people able to create their own concepts.