Date: Fri, 13 Oct 2023 15:02:11 +0300
I am totally agreeing what Giuseppe said before. If we were having much
*strong* `[[nodiscard]]` that can't be suppressed by compiler defined
flags, and sure `(void)`, then `[[discard]]` probably make sense. Also,
repeating the same thing sorry for that: while discarding something that's
never gonna be used, we are actually using it with `std::discard`, looks
weird in my opinion.
13 Eki 2023 Cum 13:36 tarihinde Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> şunu yazdı:
> On 12/10/2023 19:26, Thiago Macieira via Std-Proposals wrote:
> > On Thursday, 12 October 2023 06:57:09 PDT Sebastian Wittmeier via Std-
> > Proposals wrote:
> >> As Arthur wrote, you probably do not want to have [[maybe_unused]]
> active
> >> for SOME_PLATFORM, too.
> > Indeed.
> >
> > I don't want "maybe unused". I want a "definitely unused" attribute in
> my code,
> > instead. "Maybe unused" is useful if you don't care either way, but if I
> want
> > to be sure which way it was, it doesn't work.
>
> IMHO this is now steering off-topic -- I don't see
> [[discard]]/std::discard/... as a tool to signal that some automatic
> variables are "definitely unused". It almost sounds as a contradiction,
> as you would be using them (in the discarding "facility")?
>
> void f(int i) {
> discard(i); // wait, `i` is used here...?
> }
>
>
> This kind of use case calls for another attribute/syntax, or some clever
> macro usage, or similar. E.g.
>
> #ifdef SOME_PLATFORM
> #define SOME_PLATFORM_PARAM(x) (x)
> #else
> #define SOME_PLATFORM_PARAM(x)
> #endif
>
> void f(int SOME_PLATFORM_PARAM(i)) {
> #ifdef SOME_PLATFORM
> // use i or get an unused warning
> #else
> // don't have i at all, can't use it
> #endif
> }
>
> --
>
> Having said that, my complaints with a std::discard variadic function
> stay the same:
>
> * it can't discard *all* sorts of expressions (void, bitfields, etc.)
> * calling it with more than 1 argument is dangerous because you lose
> sequencing
> * it's a library solution for a language problem
> * it's not compatible with C
> * it doesn't have a reason
>
> Thanks,
> --
> Giuseppe D'Angelo
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
*strong* `[[nodiscard]]` that can't be suppressed by compiler defined
flags, and sure `(void)`, then `[[discard]]` probably make sense. Also,
repeating the same thing sorry for that: while discarding something that's
never gonna be used, we are actually using it with `std::discard`, looks
weird in my opinion.
13 Eki 2023 Cum 13:36 tarihinde Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> şunu yazdı:
> On 12/10/2023 19:26, Thiago Macieira via Std-Proposals wrote:
> > On Thursday, 12 October 2023 06:57:09 PDT Sebastian Wittmeier via Std-
> > Proposals wrote:
> >> As Arthur wrote, you probably do not want to have [[maybe_unused]]
> active
> >> for SOME_PLATFORM, too.
> > Indeed.
> >
> > I don't want "maybe unused". I want a "definitely unused" attribute in
> my code,
> > instead. "Maybe unused" is useful if you don't care either way, but if I
> want
> > to be sure which way it was, it doesn't work.
>
> IMHO this is now steering off-topic -- I don't see
> [[discard]]/std::discard/... as a tool to signal that some automatic
> variables are "definitely unused". It almost sounds as a contradiction,
> as you would be using them (in the discarding "facility")?
>
> void f(int i) {
> discard(i); // wait, `i` is used here...?
> }
>
>
> This kind of use case calls for another attribute/syntax, or some clever
> macro usage, or similar. E.g.
>
> #ifdef SOME_PLATFORM
> #define SOME_PLATFORM_PARAM(x) (x)
> #else
> #define SOME_PLATFORM_PARAM(x)
> #endif
>
> void f(int SOME_PLATFORM_PARAM(i)) {
> #ifdef SOME_PLATFORM
> // use i or get an unused warning
> #else
> // don't have i at all, can't use it
> #endif
> }
>
> --
>
> Having said that, my complaints with a std::discard variadic function
> stay the same:
>
> * it can't discard *all* sorts of expressions (void, bitfields, etc.)
> * calling it with more than 1 argument is dangerous because you lose
> sequencing
> * it's a library solution for a language problem
> * it's not compatible with C
> * it doesn't have a reason
>
> Thanks,
> --
> Giuseppe D'Angelo
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-10-13 12:02:25