Yes, dbg! macro looks really interesting!

Here’s my take on it: https://github.com/wojtekmach/elixir/commit/27d0019e1d21a3b2f7946a353c2439096df53612.

I think it needs to be in Kernel to be most usable because we need to require/import it to use it, and it’s gonna be annoying to do it every time.

I showed this to a few people and still collecting feedback before proposing this as a feature.

Well, don’t you mind to unite our efforts to provide even more useful solution than Rust out of the box? As you can see I’ve already implemented several additional features for this macro. I could transfer them to your branch. So we will have 2 commits in the proposal

I’m pretty happy with the limited feature set I’ve implemented but additional features you’ve added sound interesting too, I’ll definitely play with them. Feel free to argue for these additions when there’s a proposal or send the proposal yourself

Some feedback:

• show_vars: true looks interesting. I didn’t have a need for it yet, but will definitely keep it in mind.

  Special casing variables in just the first call seems somewhat arbitrary, it wouldn’t for example show y in Dbg.inspect(x |> max(y)) and that could be a bug or a feature, not sure! Perhaps it should show all variables used in an expression? You can get them using Kernel.binding.

• if the function is defined as inspect/2, there’s a clash with Kernel.inspect/2 so you wouldn’t be able to import it out of the box. One of my goals for this macro was to be available right away, but perhaps that’s no such a big deal, similarly how writing require IEx; IEx.pry() isn’t? I’ll definitely try this for a few days without this being in Kernel.

• Dbg is perhaps too similar with OTP’s :dbg module? That being said, I’m not super happy with Kernel.debug name either but couldn’t come up with neither better module nor function name.