The current Ren-C does not have them.
(The %types.r table still has things like ANY-UTF8! mentioned in it, but that's just because I haven't gotten around to changing it...it's used to make the ANY-UTF8? function.)
Let me patiently again mention my conviction that not only do I use them (and intend to continue to use them) but I am not budging on being able to do this:
>> parse [x: $y z "a" <b> %c] [
words: collect [some keep &any-word?]
numbers: collect [some keep &any-string?]
]
>> words
== [x: $y z]
>> numbers
== ["a" <b> %c]
If the functions I wanted to be able to use as constraints were members of objects, I would need &obj.my-constraint?
If the function had a refinement I was interested in, I would need &my-constraint?/refinement
We do not assume that just any arbitrary function looked up by WORD! reference in a dialect (at least, in PARSE) is meant to be used as a type constraint.
>> parse [x: $y z "a" <b> %c] [
words: collect [some keep any-word?]
numbers: collect [some keep any-string?]
]
Even if we could do that (by some categorization system that said a function returned a boolean and took a single value and was a plausible type constraint) I don't know that I'd want to. Applying a test to the current value of the input is different than what's suggested by any-value? xxx inline in the parse...which makes it seem like you're testing the product of the next rule. I prefer at the source level having this called out, and having the inertness overture let you know that it's not taking the ensuing thing as an argument.
The only undecorated functions that I'd want to dispatch would be those that fit the format of a combinator.
Due to the large amount of flux right now, I'm focusing on lining up parts more than I am on making sure the error handling is good. So there's a lot of stuff that asserts vs. errors.
Of course this is clearly something that should just be an error, as putting undefined things in type spec blocks is an ordinary usermode problem.