Playing with Nil and nonsense type smiley values

[2colours]

This is a very open-ended experiment that probably no diehard Perlist would care about: what happens when you deliberately try to abuse values that perhaps shouldn't even exist in the language. Most of the issues have no real significance but they are very unnecessary regardless.

There are a lot of possible issues, it's a multi-dimensional thing, I would just lay the dimensions down and highlight a select few that may have a visible impact.

• using a Type:D value (you read it right - this can be used as a value, not sure for what benefit) or a Type:U value as the target object
• using Nil and its derivatives as target object
• comparing type objects and these smiley'd type objects against each other using various comparisons and smartmatches
• calling methods available on their supposed type
• trying to assign them to constrained variables with various constraints
• trying to instantiate them

It seems, for example, that Str:D can be stored in a my Str $foo kind of variable, and although it produces varnings, it can be coerced into various values and it can fall back (also with a warning) to a string value. However, if you did the same with Int and Int:D, the numeric coercion would fail, for example. Binding or assigning to Str:D will fail - so will trying to create an instance directly using these values (eg. Str:D.new) - actually, that's the direct error when trying to coerce Int:D to a number...

One can also see that Nil:D.new and Nil:U.new actually does work for whatever reason, and they produce Nil (which is, just like for other types, ~~ Nil:U but not === Nil:U)

These are rather theoretical, annoying, evergreen issues that are never going to get fixed realistically. I have no idea what the point of having these type smiley versions as "proper values" even is. They also use a different meta-object so eg. .^mro won't even work on them. Ideas about when would you ever want them as proper values, are very, very much welcome. It seems to me their only valid use would be the smartmatch; I don't think that justifies them being stored in some loosely typed variable.

---

However, the totally random behavior of Nil in different methods is actually concerning. Since Failures are derived from Nil, they might be worth checking, too. Also, it seems that Nil will always just silently return Nil whenever a non-existent method is called on it - which would perhaps be a bad idea in itself but given that it actually throws warnings (maybe errors even, sometimes) for the methods that it does have, it is guaranteed to be unexpected one way or another.

For good old type objects:
This tricky behavior is about type objects that might pop up in random user code: rakudo/rakudo#5254
And good news - this issue about inconsistency across type objects got fixed by lizmat in the meantime: rakudo/rakudo#5256