[__phantomderp]

Hi! Article author here. I have long, long since waxed poetic about how many bugs and problems this can solve (even just a poor man's library version):

https://twitter.com/__phantomderp/status/1381314735174524928

And, very recently, I have begun to scheme and agitate for a feature similar to what your article proposes:

https://twitter.com/__phantomderp/status/1424466518797135876

I am not sure people will go for `..`, and I would also like to find a way to enable composition and multi-dimensionality in an easier fashion (nesting arrays, for example, does not require that all of the memory is laid out perfectly flat. This is the case in both C and C++, and is taken advantage of by e.g. ASan and other memory-shadowing runtimes that add shadowing cushion around each array member).

As a Standards Committee person, I can't really just demand "and this will go into the standard"; our charter requires 2 existing C compilers/stdlibs to implement the thing (unless the thing is so dead-simple we can just shake hands and implement it because it's not contentious) and then, after that, requires consensus (which is its own roadblock to getting things done when someone doesn't like the syntax/way-you-are-doing-it/gets-in-the-way-of-their-implementation).

So, for example, if the C parser in D were to support this syntax, and someone else were to support some kind of syntax for this, and they all got together and wrote a paper for this idea, that would count as two implementations..........

Hint hint. Wink wink. Nudge nudge? 0:D

[WalterBright]

It is indeed dead simple :-)

The spec, the implementation, and using it. It's by far the simplest scheme I've ever seen proposed for C. You can see this from the article.

I suppose I could add it to D's ImportC:

https://dlang.org/spec/importc.html

even though ImportC's charter is to implement C11 as it stands and not fix anything.

But would the committee accept DasBetterC as an implementation?

https://dlang.org/spec/betterc.html

DasBetterC does implement the slices.

[__phantomderp]

We tend to accept anything that parses the C Standard - even only a part of it - as a viable implementation! For example, static analyzers are viable implementations of the standard, even if they don't produce code.

I think getting this feature into one other implementation and then writing a paper on it would help. Unfortunately, the cutoff for "new papers that must be submitted to be considered for C23" is October, so there's not a LOT of time, so we'd need to find a 2nd implementation quick-fast, and then write the proposal quick-fast too!

[setpatchaddress]

Does Apple have representation on the committee? Have they briefed anyone on this?

https://support.apple.com/guide/security/memory-safe-iboot-i...

[__phantomderp]

Apple made a big-huge list of their extensions and things they've done some years back, which included their Blocks extensions: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf

Apple (and others) have also very strongly informed us of the zeroing-things-out work they've done and how it saves them quite a bit of problems. There are folks on the Committee who value their already-existing users and implementations more, where indeterminate initialization provides them the performance and control they like. They also don't want to make those people have to change their code to init things. It's not a direction I agree with, but you have to remember that people like me have a much larger burden of proof. Indeterminate initialization is the status quo, and changing the status quo requires a paper, attending meetings, convincing others, and passing a vote. It's very much an uphill battle, and you have to bring a LOT of evidence to the table to fix it, and even after you bring that evidence you're required to prove it deserves to be in the standard. A lot of work!

For initialization, I am hoping to standardize "= {}" as a way to guarantee a proper static initialization. (Paper here, but needs some more work: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Consist...) Committee has received it favorably, and it should make C23.

For other things, you might need to lean on C23's attribute feature (e.g. "[[clang::must_initialize]]" and stuff) to provide some of that functionality. Not quite ideal, but attributes have standard placement and are infinitely extensible by implementations, so it gives vendors room to provide users what they need while the Standards Committee chews through proposal after proposal to get things done.

Hopefully this is a little helpful to you about the process!