On Thu, Apr 20, 2023 at 6:25 PM Larry Garfield <la...@garfieldtech.com> wrote:
> ## The options > > There's three ways we've come up with that this design could be > implemented. In concept they're not mutually exclusive, so we could do > one, two, or three of these. Figuring out which approach would get the > most support is the purpose of this thread. > My initial feelings based on the options laid out is that anything which can't support FCCs in the manner of strlen(...) is probably a non-starter in terms of language design. Changes like this are fundamentally about making things simpler, more concise and more convenient for users, not drip-feeding a stream of "and here's yet another way of working with..." features across releases. Structural typing option seems like the easiest to implement in the engine (correct me if I'm wrong?) and probably the best syntax for the user within the interface approach. But then do we really want to introduce new runtime checks and complexity when the general trend of the language has been in the opposite direction? I imagine probably not. So out of the three, I lean towards adding castTo() to Closure and it maybe raises a to-be-determined Throwable if the closure is already bound? It's not as friendly for the user as the other options but it seems like the most workable, it delivers value and it most closely fits within the existing way of working with all types of closure today. -Dave
