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:
Yeah, that's a valid concern, and there is no actual remedy to that. The worst thing is that _logically_ parser could've understood we mean the `_1` from the outer block (as the inner one has named args); but supporting this kind of "smartness" is usually rebuked by the core team with the considerations like "this would be too confusing".
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 }}
Yeah, that's a valid concern, and there is no actual remedy to that. The worst thing is that _logically_ parser could've understood we mean the `_1` from the outer block (as the inner one has named args); but supporting this kind of "smartness" is usually rebuked by the core team with the considerations like "this would be too confusing".