Re: constexpr keyword is unnecessary

On 2024-10-29, Thiago Adams <thiago.adams@gmail.com> wrote:

On 29/10/2024 02:04, Kaz Kylheku wrote:

On 2024-10-28, Thiago Adams <thiago.adams@gmail.com> wrote:

I believe warnings in code should be treated as alarms that require
acknowledgment.
>
For instance,
>
const unsigned char ch = 1234;
>
GCC:
warning: unsigned conversion from 'int' to 'unsigned char' changes value
from '1234' to '210' [-Woverflow]
>
The programmer might intend this behavior; in that case, the "alarm"
should be acknowledged.
>
I would like a portable (standardized) way to achieve this.

 
For conversion warnings, that portable way should ideally be a cast.
 
Any half-decent compiler should shut up if the conversion is
explicitly requested:
 
   const unsigned char ch = (unsigned char) 1234;
 
If not, complain to the compiler developer.
 
It works this way for conversions that are constraint violations,
like between unlike pointers. Assign a pointer to a variable of
the wrong type, and there is a required diagnostic. With a cast,
the diagnostic is not required, and it would be irksome if there
still were one.
 

>
>
>
Yes, in this case, using a cast is the way to go with current compilers.
>
But, the concept of "alarm acknowledgment" removes a specific warning
that must exist. It can be a safer alternative.
>
(I intend to show a general idea. There are likely better examples.)
>
Consider this function:
>
>
void f(int i) {
     ...
     const unsigned char c = (unsigned char)i;
}
>
>
If someone changes the type of `i` to `unsigned char`, then the cast
becomes unnecessary:
>
>
void f(unsigned char ch) {
     ...
     const unsigned char c = (unsigned char)ch;
}
>
>
With the "alarm acknowledgment" idea (I'll just invent a syntax
`[[!truncation]]`), we would get a warning if there is no actual
truncation to acknowledge. For example:
>
>
void f(unsigned char ch) {
     ...
     const unsigned char c = (unsigned char)ch; [[!truncation]];
     // Warning: there is no truncation to acknowledge.
}

"I think truncation does not happen" is here logically equivalent to
the specific condition that ch is in the range 0 to UCHAR_MAX.

That can be asserted:

  assert (0 <= ch && ch <= UCHAR_MAX);

If ch has the type unsigned char, then this condition is always
true.

We can think about a warning like that "controlling expression of assert
unconditionally true due to range of types", but it serves no purpose.
There is nothing wrong with asserting something that is always true.

When assertions are enabled, the compiler can use their predicates
to reason about the code and not warn about conditions that are
precluded by assertions being true.

You will find that this already happens in today's compilers,
and not due to assert being treated specially. The assertion
translates into something like

  if (!(0 <= ch && ch <= UCHAR_MAX)) do {
    __assert_fail("0 <= ch && ch <= UCHAR_MAX", "foo.c", 42);
  } while (0)

where __assert_fail is annotated a function which does not return. From
the non-returning property of the function, the compiler can infer that
0 <= ch and ch <= UCHAR_MAX must be true after that statement.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca