Consider specializing `self.` in macros

[LucioFranco]

Currently, in the tracing macros to set a field that lives on self I need to do something like this:

let error = self.error;
error!(%error);

but ideally, I'd like to do:

error!(%self.error);

and these two should be equivalent. Currently this is not the case and we will get an output like: self.error = "...". I would like to propose that if the macros see self. we remove the self. part and just use the post fix value.

[hawkw]

Currently, in the tracing macros to set a field that lives on self I need to do something like this:

let error = self.error;
error!(%error);

Note that you can also write

error!(error = %self.error);

[hawkw]

I've been thinking about this a bit. It's definitely possible to do this. I'm not totally sure if we should. Some potential considerations:

• Currently, all field names are exactly what the user typed in the macro invocation. This would change that. We should weigh the costs of making the behavior less consistent versus the benefits of adding this special-case.
• It would add additional complexity to the already quite complex field parsing macros. It might be worth saving this for an eventual proc-macro rewrite, if we decide to move forward with that...
• If we special-case field names beginning with self. to strip self., there would then be no way for users who want field names beginning with self. to write them. We could add special-casing like r#self or something to opt-in, but that adds even more complexity...
• How would we handle fields where the entire name is self? We probably don't want those to be named "".

Another thought that's kinda related is that it might be nice to allow function calls in field name shorthand, stripping off the parameters. So that you could say

trace!(self.len());

and get a field named self.len
instead of having to do

trace!(self.len = self.len());

If we're special-casing things in the field name parser, it might be nice to do that as well...but again, it adds complexity to the already absurd parsing macros...

[LucioFranco]

How would we handle fields where the entire name is self? We probably don't want those to be named "".

Shouldn't we special case just self. not self?

I also really like your proposal!

[hawkw]

How would we handle fields where the entire name is self? We probably don't want those to be named "".

Shouldn't we special case just self. not self?

Probably, yeah. Since we're doing this in the dotted field name parser, that should be possible.

[hawkw]

After further consideration, I think we probably shouldn't do this. Special-casing self. would mean that users cannot create fields with names beginning with self..

There might be valid use-cases for such field names. For example, consider a method that takes a self argument of a type that has a field named my_field, and another argument of the same type. In that case, you might want to be able to write:

fn do_something(&self, other: Self) {
    tracing::trace!(self.my_field, other.my_field);
}

but, if self. is special-cased, it's impossible to do this.

Since we can currently drop the self. by not using local variable shorthand, as in

tracing::trace!(my_field = self.my_field);

I'm not sure if this is worth making it impossible to represent fields with names beginning in self..

[LucioFranco]

That is a fair point, I guess how often does that situation arise versus the one I brought up? Imo, it makes sense for a user to handle that specific case with r#self.my_field = self.my_field?