Conversion to IPR breaks down a simple-declaration, such as:
int i, j, k;
into a three IPR declarations:
i: int;
j: int;
k: int;
Most of the time, during analysis we don't really care that they came from the same simple-declaration. In the case when the type is auto, the tool using the IPR may want to know that.
Consider:
auto i = 1, j = sizeof(1), k = 1.2;
A compiler may want to emit a single diagnostics, highlighting all the deduced types in that simple-declaration, something like:
error C3538: in a 'auto' must always deduce to the same type
note: could be 'int'
note: or 'double'
note: or 'size_t'
An IPR does have an implicit grouping by virtue of all three declarations referring to the same instance of auto type, however, this information is not available in the form readily available (or constructible in a reasonable time from an IPR itself).
This issue poses a question, is there a need for an IPR construct grouping a set of declarations that was split out from a single simple-declaration that justifies grouping them together?
Conversion to IPR breaks down a
simple-declaration, such as:into a three IPR declarations:
Most of the time, during analysis we don't really care that they came from the same simple-declaration. In the case when the type is
auto, the tool using the IPR may want to know that.Consider:
A compiler may want to emit a single diagnostics, highlighting all the deduced types in that
simple-declaration, something like:An IPR does have an implicit grouping by virtue of all three declarations referring to the same instance of
autotype, however, this information is not available in the form readily available (or constructible in a reasonable time from an IPR itself).This issue poses a question, is there a need for an IPR construct grouping a set of declarations that was split out from a single
simple-declarationthat justifies grouping them together?