Fix incorrect fmt::Pointer
implementations attempt two
#381
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #328
Requires #377
Requires #380
Synopsis
Debug
andDisplay
derives allow referring fields via short syntax (_0
for unnamed fields andname
for named fields):The way this works is by introducing a local binding in the macro expansion:
This, however, introduces double pointer indirection. For most of the
fmt
traits, this is totally OK. However, thefmt::Pointer
is sensitive to that:Solution
Pass all local bindings also as named parameters and dereference them there.
This allows
"{_0:p}"
to work as expected. Positional arguments and expressionsstill have the previous behaviour. This seems okay IMHO, as we can explain
that in expressions these local bindings are references and that you need
to dereference when needed, such as for
Pointer
.A downside of the current implementation is that users cannot use the names of our named parameters as names for their own named parameters, because we already use them. With some additional code this is fixable, but it doesn't seem important enough to fix. People can simply use a different name when creating their own named parameters, which is a good idea anyway because it will be less confusing to any reader of the code. If it turns out to be important to support this after all, we can still start to support it in a backwards compatible way (because now it causes a compilation failure).
Checklist