This feature would be helpful if it were integrated with byebug's tracevar, which currently supports only global variable tracing.

:iasgn (IASGN name from RubyVM::AbstractSyntaxTree::Node)
:casgn (CVASGN (or CASGN?) name from RubyVM::AbstractSyntaxTree::Node. I think class variables tracing is useful too.)

For me it's hard to understand what's :iasgn at a glance. Perhaps other TracePoint event names and Node's names have different naming conventions. Other TracePoint event names are like :thread_begin or :fiber_switch. So for :iasgn, I'd propose:

• :ivar_assign (close to original proposal)
• :instance_variable_set (same as official method name, maybe too long but "ivar" may not be friendly either)

I think class variables tracing is useful too.

Cloud you describe a use case? Your reasoning behind :iasgn is Rails controllers / views and that makes sense, but I don't think it applies to :casgn.

I suggest a feature "tracing instance variable assignment"

I love introspection. The old pickaxe had an example tracing global variables, and
it would seem nice if we could extend this to other/more variables, so I am +1 for
the suggestion. See also pry acting a bit like an introspection-debugger, e. g.
"cd object; ls" what the object has (at the least as an idea).

I should, however had, also admit that I do not use the trace-var functionality
for global variables, primarily because I try to avoid global variables (and thus
use them so rarely that I don't need to trace anything), but also partially because
I am not completely sure whether I personally need that functionality. But still I
think it would be nice to have, so I agree from this point of view with igaiga.

I agree that :iasgn is a strange name but I guess other/better names can be used;
may be good to ask ko1 what he thinks about tracing (and exposing this for ruby
users) in principle (and of course matz whether he wants to expose functionality
to ruby users, but I think since we can trace global vars, it may be a related
topic to be able to trace other variables too).

Thanks to comments.

:ivar_assign (close to original proposal)
:instance_variable_set (same as official method name, maybe too long but "ivar" may not be friendly either)

Looks good. I feel they are good to read, so better than my suggested :iasgn.

Cloud you describe a use case? ... but I don't think it applies to :casgn.

I've tried to describe the use cases, but I can't write use cases for class variables.

I thought following patterns that how to torigger their assign timings.

• global variable: Kernel#trace_var
• class variable: none
• instance variable: suggested by this issue
• local variable: none? (but we don't need)

So I thought class variable assignment trigger is useful for us. But cases to use class variables are not so often, so the trigger of :class_variable_set would be not so useful.

How about this naming convention:

• ivar_set
• cvar_set
• gvar_set

ivar, cvar, and gvar all match Ruby's internal glossary, and is quite commonly used in the community too (based on my personal experience).

I picked set because:

• It matches the *_variable_set method names
• It's one character shorter than asgn

And finally, if nobody else is looking at this, I'd like to give it a try 🙂

I think tracing ivar assignments would be prohibitively slow, and so probably not really usable in practice.

I think tracing ivar assignments would be prohibitively slow, and so probably not really usable in practice.

Since TracePoint is only recommended for debugging use, I think trading execution speed for more efficient debugging experience is a worth tradeoff for many people (myself included).

Currently, tools like debug watch events like call and return to inspect instance variable changes (example), or even line event like the description gives, which are all much slower than having a dedicated ivar set event.

Anyway, I made a PR to support it here: https://.com/ruby/ruby/pull/13369