Date: Tue, 20 Dec 2022 18:55:58 +0100
On Tue, 20 Dec 2022 at 15:29, Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Hi,
>
> On 20 December 2022 13:25:48 GMT, Timur Doumler via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> >
> >
> >> On 19 Dec 2022, at 12:11, Bo Persson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >> At least originally, there was a basic idea that ignoring an attribute
> should not affect the validity of a program. Like [[nodiscard]] and
> [[maybe_unused]] would affect warnings, but not the generated code.
> >>
> >> Adding ABI-modifying attributes seems to be totally contrary to this.
> >
> >That basic idea has been thrown out of the window a while ago. We now
> have multiple potentially-ABI-modifying attributes in the standard.
> >
> >[[no_unique_address]] modifies ABI: its purpose is to literally change
> the class layout.
> >
> >[[assume]] can also modify ABI in one particular edge case (
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2552r1.pdf, see
> last code example on page 5).
> >
> >Cheers,
> >Timur
>
> Are the precedences confirm that it is a good idea though?
> [[no_unique_address]] had to be "backported" to earlier -std options in
> clang and gcc. The ABI mismatch exists between old and new versions of the
> compilers on older standards.
>
> MSVC just continues to ignore the attribute, AFAIK at least partly to
> avoid ABI issues.
>
> I think the ABI issues could have been side-stepped, if it was introduced
> by a non-ignorable syntax. Unfortunately there is no similarly convenient
> way to introduce those.
>
At least if an attribute is introduced alongside a new feature, there is no
issue of it being ignored by older compilers.
Another place where introducing an ABI-affecting attribute is more or less
safe is if it replaces (standardizes) a non-standard attribute, since one
assumes that the user will know how to fall back to the pre-standard
version.
I did not know about [[assume]].
>
> Cheers,
> Lénárd
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> Hi,
>
> On 20 December 2022 13:25:48 GMT, Timur Doumler via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> >
> >
> >> On 19 Dec 2022, at 12:11, Bo Persson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >> At least originally, there was a basic idea that ignoring an attribute
> should not affect the validity of a program. Like [[nodiscard]] and
> [[maybe_unused]] would affect warnings, but not the generated code.
> >>
> >> Adding ABI-modifying attributes seems to be totally contrary to this.
> >
> >That basic idea has been thrown out of the window a while ago. We now
> have multiple potentially-ABI-modifying attributes in the standard.
> >
> >[[no_unique_address]] modifies ABI: its purpose is to literally change
> the class layout.
> >
> >[[assume]] can also modify ABI in one particular edge case (
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2552r1.pdf, see
> last code example on page 5).
> >
> >Cheers,
> >Timur
>
> Are the precedences confirm that it is a good idea though?
> [[no_unique_address]] had to be "backported" to earlier -std options in
> clang and gcc. The ABI mismatch exists between old and new versions of the
> compilers on older standards.
>
> MSVC just continues to ignore the attribute, AFAIK at least partly to
> avoid ABI issues.
>
> I think the ABI issues could have been side-stepped, if it was introduced
> by a non-ignorable syntax. Unfortunately there is no similarly convenient
> way to introduce those.
>
At least if an attribute is introduced alongside a new feature, there is no
issue of it being ignored by older compilers.
Another place where introducing an ABI-affecting attribute is more or less
safe is if it replaces (standardizes) a non-standard attribute, since one
assumes that the user will know how to fall back to the pre-standard
version.
I did not know about [[assume]].
>
> Cheers,
> Lénárd
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2022-12-20 17:56:11