Given your example, the respective types as reported by .WHICH are something like Str+{<anon|1>} and Str+{<anon|2>}. Because different types are generally not considered to be eqv the actual behavior is correct given these types.

Of course it would be nicer if in this case the type would be something like Str+{<Bool|0>}.

Given your example, the respective types as reported by .WHICH are something like Str+{<anon|1>} and Str+{<anon|2>}. Because different types are generally not considered to be eqv the actual behavior is correct given these types.

Yeah, it's correct, it's just not useful.

Of course it would be nicer if in this case the type would be something like Str+{<Bool|0>}.

Yeah, that would pretty much exactly by what I would hope for.

According to the documentation of infix but you can't actually mix-in an object. Instead, Raku creates an anonymous role with a method that returns the object.

Theoretically, Raku could memoize the anonymous roles it creates, but I doubt that is very practical. So I suggest using but to mix-in a named role, for example:

my role Irrelevant {
    method Bool(--> False) {}
}

my $a = "foo" but Irrelevant;
say $a.^name unless $a;          # OUTPUT: «Str+{Irrelevant}␤»
say $a eqv "foo" but Irrelevant; # OUTPUT: «True␤»

I think this can be closed now.

According to the documentation of infix but you can't actually mix-in an object. Instead, Raku creates an anonymous role with a method that returns the object.

The documentation can be explained to do either thing. Pointing at it isn't much of an argument to do the less helpful of the two options.

Theoretically, Raku could memoize the anonymous roles it creates, but I doubt that is very practical.

I'm pretty sure that mixing in booleans is 95% of all runtime mixins of a value. In particular, «$string but False» is a value that's generated by the core argument parsing --/foo. And «0 but True» was pretty much how the feature was invented. Even just special casing True and False would already be quite helpful (Str is probably the other 4%)

So I suggest using but to mix-in a named role, for example:

That is not a very helpful suggestion when raku itself gives me "string" but False values

This doesn't look like such a difficult issue. It's really just a matter of caching a parameterizable role per value type, or am I missing something? The only challenge I can see is that it probably has to happen in NQP.

Ultimately, if we want them to be eqv, then we need to make interning them part of the language spec. That feels reasonable to me. (Note that this needs doing carefully, using the VM-backed paramerizable stuff support, so that the interning happens across pre-compiled modules too.)