One unaesthetic aspect of the numeric blockargs is that they are still not extensible.
Like the &:meth syntax is not extensible in the sense that if meth should take arguments, that's not possible to express this syntax. So a refactor that brings in such a call convention will have to forcibly depart from this syntax.
The same applies to numeric blockargs. I bring up an example from interactive use. One could do this:
Great as usual. TY for taking the time to write this, Victor! Stay safe!
One unaesthetic aspect of the numeric blockargs is that they are still not extensible.
Like the &:meth syntax is not extensible in the sense that if meth should take arguments, that's not possible to express this syntax. So a refactor that brings in such a call convention will have to forcibly depart from this syntax.
The same applies to numeric blockargs. I bring up an example from interactive use. One could do this:
> puts code_that_produces_a_nicely_formatted_string()
However, since the advent of #then/#tap, it's more convenient to write it like this:
> code_that_produces_a_nicely_formatted_string().tap { puts _1 }
as printing is the last step logically; this way line input is aligned with logical formation.
However, say I now want to write out the string to a file!
> code_that_produces_a_nicely_formatted_string().tap { open("foo.txt", ?w) {lfl f.puts _1 }}
does not work as the extra inner block changes the scope of _1; this refactor forces us to give up on this sugar, and we have to resort to:
> code_that_produces_a_nicely_formatted_string().tap { lbl open("foo.txt", ?w) {lfl f.puts b }}