Jonathan Worthington

Some reasonable (in that I can argue for each of them) options that come to mind: 1. Deprecate `is required` and defaults on attribute values in 6.e, on the basis...

> I assume ^^^ was a typo for "on natively typed attribute values"? Yes, everything suggested is only about natively typed attributes. > On that assumption, I can see merits...

S03 has this (highlight mine): > Dispatches to the infix: multi most appropriate to the operand types, **returning a value of the same type**. Not coercive, so fails on differing...

There's a wide variety of suggested additions here. I'm in principle not opposed to adding things to `CORE.setting`, but there should be a good argument for those we do add,...

Removing my assignment as I believe both @ugexe and @niner are far better placed to answer this than I am.

A couple of thoughts: 1. `Routine` objects are already big enough. Not only are we paying the cost of their storage in compiled output, but also every closure clone of...

> If Routine objects are basically too fat for their own good, would it make sense to combine $!rw, $!yada and $!onlystar into a single bitmap, thereby reducing each Routine...

An update on this: I'm currently doing some early R&D on macro implementation, which along the way will involve giving us a spec'd DOM for Raku code. I expect that...

I think having `List.Capture` automatically promote any `Pair` in the list into a named argument was probably a mistake (one of mine too, maybe I need to borrow rule 2...

Ah, and I hereby delegate the research to find out which of 1 or 2 we have to do, to somebody enthusiastic about it. :-)