I agree the current behavior is inconsistent, and I am now inclined to simply remove the `ambiguous /` warning. The warning was intended to be helpful, but as this issue shows, it does not catch the genuinely confusing case (the synta...matz (Yukihiro Matsumoto)
Thank you for the proposal, and thank you @zverok for the detailed explanation. I agree with @zverok. The absence of `#dig` on `Data` is intentional. `Data` is designed as a base for composite value objects, not as a navigable contain...matz (Yukihiro Matsumoto)
The current behavior follows from lazy evaluation of rescue clauses, which is intentional. As @kddnewton noted in #note-7, the arguments are expressions and can't be classified statically, so an eager check means evaluating them all, wit...matz (Yukihiro Matsumoto)
Thanks for the proposal. Let me clarify my position. I am not opposed to introducing this API in principle. The use case is real, and I do not think `rb_str_new_static` + ivar is a proper substitute. They have different lifetime seman...matz (Yukihiro Matsumoto)
Agreed in principle. The current behavior was a workaround for #7107, not a design decision, and the follow-ups in #10885 and #15877 were patches on top of that. Keeping the original lexical scope is consistent with inheritance, mixins, ...matz (Yukihiro Matsumoto)
@shugo is right. The change in super's behavior in 2.7 was unintentional, so I'm in favor of fixing it to match the documentation. Matz.matz (Yukihiro Matsumoto)
Thank you for the proposal. Introducing a new method rather than extending `source_location` is the right direction, given the compatibility issues we hit. I approve the shape of this feature, including: - The class name `Ruby::Sou...matz (Yukihiro Matsumoto)
I'd like to suggest we settle the design before changing the permissions. Specifically: 1. The current policy around default/bundled/unbundled gems should be written down. `doc/maintainers.md` is outdated, and until it's updated, d...matz (Yukihiro Matsumoto)