Item — HN Reader

> I understand that people can have many things to say about C++, and I do as well, but `std::span` should have been there decades ago (...)

Decades is kind of a stretch. C++11 introduced smart pointers, and finally getting C++0x out of the door was already a major victory. Given the history of C++, it would be unrealistic to introduce something like std::span before C++17.

Meantime, some organizations are still struggling to migrate to something like C++14.

2 comments

It could have been there since the beginning, given that open arrays (aka spans) already existed in other languages, and there was even a failed proposal from Denis Ritchie regarding C.

The C++ span proposal came from Microsoft,

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p01...

> already existed in other languages

This argument is moot. The issue with spans is not that they require cutting edge technology to deliver.

Before commenting, perhaps you should research why even Denis Ritchie himself could not sell his idea to C.

It's funny how every single idea that's rejected is blindly lauded as brilliant but silenced due to some kind of conspiracy, and only the ideas that emerged are somehow bad, unacceptable, or late. Is the point to feel outraged?

Easy, even one of the author's could not change WG14 mind towards security.

Governments,related cybersecurity agencies, and companies are the ones getting outraged when looking at money spent in cyber attacks due to memory corruption issues.

WG14 adopted variably modified types, a kind of dependent type. From a security standpoint it offers all the same qualities. It also in principle was easier to integrate from a backwards compatibility standpoint, with the exception of struct member analogs (which we now have but aren't yet standardized).

Maybe we would have been better off with Ritchie's counter proposal. But neither proposal was chiefly concerned with security, thus no proposals for, e.g., automatic bounds checking.

Just to be clear, I often think we would have been better off with Ritchie's proposal, assuming it would have seen at least as much adoption in implementations and usage as variably modified types, which sadly remained poor for many years after C99, and arguably still poor. But being better off doesn't mean being in a drastically better situation than we are today from a security perspective. The proposed alternatives were prerequisites for substantively improving security, but far from sufficient. And the delay in adopting and refining variably-modified types has cost much more than whatever marginal benefit Ritchie's proposal offered. Ditto for other gaps, like better facilities for handling arithmetic, e.g. overflow and mixed type comparisons. The first step in addressing overflow only came with C23 (overflow checking routines), and the latter only in the forthcoming C2y (typesafe, mixed-signedness min/max, etc).

The support for variably modified types is excellent, if you discount MSVC which is lacking support for modern C anyway (it seems to catch up a bit though).

Real-world usage certainly remains poor. Using pointers to VM types remains annoying, and I wish the committee would settle on a solution to the ordering of VM parameters. But, yeah, the VM types are solid in GCC and clang and should be used more.

> Easy, even one of the author's could not change WG14 mind towards security.

Your comment conveys a hefty dose of ignorance on the topic. I recommend you read the proposal's arguments, including how it required breaking the ABI.

Are you asserting that WG14 never had the necessary skills among all the members to help improve this proposal, or dare to bring another one during the last 40 years?

This has not much to do with skill. Standardization does not work like this, and I told you this before.

Yeah, I keep missing the existing practice in secure C compilers that is supposed to land on a WG14 paper.

You can tell me the times you wish for, I will keep playing my trumpet until I see something in C that resembles to Modula-2 was offering in safety, nowadays brought back by Zig.

> Are you asserting that (...)

No, I called out your opinionated ignorance on the topic.

> WG14 never had the necessary skills among all the members to help improve this proposal (...)

Frankly I don't think you even understand what you're arguing. I mean, to start off, if an idea is feasible then do you think it needs a full blown committee joining forces to magically fix all the problems?

> (...) or dare to bring another one during the last 40 years?

Again, you are showing a hefty dose of ignorance in the topic. Do you even understand that anyone can put together a proposal? That's how the process works. If you feel so strongly about it, where is yours? What have you been doing for the past 40 years?

Who is more ignorant here, you repeating calling me that, or WG14 not doing anything to improve security since the Morris worm in 1988?

Afaik std::span does not need anything that was not in C++98 already, or am I missing something?

> Afaik std::span does not need anything that was not in C++98 already, or am I missing something?

You're missing the fact that following C++98 it took around 13 years to get the next version of the standard published delivered.