Hi JeanHeyd,

On 11/14/21 22:54, JeanHeyd Meneide via Std-Proposals wrote:
> On Sun, Nov 14, 2021 at 4:06 PM Alejandro Colomar (man-pages)
> <alx.manpages_at_[hidden]> wrote:
>> ...
>> No, it's not. There was a proposal (by Jens Gustedt),
>> but it wasn't accepted (and I'm happy it wasn't).
>
> That's strange, because it's still implied as part of our charter
> as something that can be done (#15,
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm), still used
> in quite a few functions as part of the upcoming C23 draft (latest
> draft N2731 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf),
> declarations from §7.12.16.1), and as far as I know I've been
> encouraged to do exactly that. Maybe we're not annotating everything,
> but we are moving in that direction as a whole, as I understand it.

Ahhh, sorry, my mistake.

There were two related things going on:

- Transform old prototypes into using '[static n]'
- New functions should use VLA syntax ('[static n]').

The former, was rejected. I forgot the latter, and answered for that one.

Since functions that accepted arrays had the size _after_ the array, as
Thiago pointed out, they couldn't use that syntax.
But functions accepting non-null pointers, were proposed to use '[static
1]', to mark them as arrays of size (at least) one. That is what would
be insane IMO, since it would be exactly the opposite of what would be
intuitive: arrays would be marked as pointers, and pointers would be
marked as arrays. Luckily, that change was not accepted.

The latter is going on well, as you proved. And it is an excellent idea.


>
> w.r.t. C headers working in C++: that's an implementation's
> business whether they want to have their C headers work seamlessly in
> C++. One way is to have C++ accept C's syntax here, or at the very
> least consume such syntax and ignore it. The other way is to employ
> all sorts of lovely macros, which is what I (and others) have been
> doing for some time. (Not that you even need to take a trip over to
> C++! MSVC's C mode still chokes on static pointer extents for
> arguments: https://godbolt.org/z/KTYxf7Wq1).

C's syntax is not perfect, although it's much better than C++.

Ideally,
I'd like to get C++ to have a syntax that is better than C,
and in many ways compatible to that of C,
and then get C to adapt to that syntax.

For C++:

- Accept [n]

For C:

- Deprecate static
- Make [n] mean (almost) the same as [static n]
   (except for the nonnull-ness)


Adding [[nonnull]] to both would allow deprecating static.

If C++ prefers to accept static,
that's fine,
but I'd mark it as deprecated from day 0,
and would give [n] the meaning it deserved from the beginning.

>
> I would prefer C++ just accept C's syntax since I legitimately
> cannot imagine a world where C++ has any use whatsoever for an
> argument of void f(T meow[static n]); meaning anything other than what
> C does, because I don't think C++ would ever use the word "static"
> there to begin with.

I see C's static as C's auto.
Something that has no meaning at all.

void f(T meow[n]);
void f(T meow[static n]);

Eventhough the first syntax is ignored by the standard,
I cannot imagine a world where each one means a different thing.
As a slight difference,
I'd make that [n] can be NULL,
but for rejecting NULL we can add [[nonnull]] as I suggested.
It's kind of 'auto int' and 'int'.
Let's forget C's 'auto' ever existed :)
And let's make it so that we can also forget C's 'static' ever existed.

>
>> ...
>> As I said, '[[nonnull]]' should be added to C & C++ (with the meaning of
>> '[[gnu::nonnull]]'), and it would make 'static' obsolete. If C++ ever
>> adds 'static' with that meaning, it would be marked as deprecated from
>> day 0, so I think we better keep it out, and let compilers ignore it as
>> needed.
>
> That would be nice too. And probably easy to get in. Maybe I
> should write Yet Another Paper™ and ask the C Committee for it. It
> doesn't seem like we ever proposed one. C++ probably never asked for
> one because they have references, but it'd likely be useful in C since
> 90% of the stdlib works on non-null pointers, to the point that
> implementations use it as an optimization point (much to people's
> deep, unending grief).

We're late for C2X, I think,
so it's probably going to be for C3X.
If you can make it into C2X it would be nice.
If not, I'd like to write the paper :-)

Cheers,
Alex