Hi Larry, I have a follow up question based on your May 31 email that I'm hoping you may be able to answer. In that email, you wrote:
> In my opinion, the most consistent approach is to disallow any > autothreading of the argument to .ACCEPTS, such that > 3.ACCEPTS(any(3,4)) simply returns False.… I think treating the > unrecognized $other as a raw Mu returning False (rather than a > threadable Any returning a junction) is the most consistent, if not > always in line with everyone's expections, which are not consistent. > :) I did some digging into why 3.ACCEPTS(any(3)) currently returns True, and it turns out that it does so because you spec'd and implemented it that way. The Roast test is at github.com/Raku/roast/commit/53f468 and the implementation is at github.com/rakudo/rakudo/commit/28a769 – and that commit has the message > This is probably how most people will expect smartmatching to work. Of course, you're free to change your mind – some rules never change :) But I'd like to understand if this _is_ a deliberate change in your thinking and, if so, what changed your mind. From where I stand, the logic from 2015-Larry is pretty convincing, but is sounds like you no longer agree with that guy> I'd be very interested to know what convinced you. Thank you in advance, Daniel
