[gumby]

> Rust's standard library is not a spec, it's just code.

I consider this profound weakness, not a strength.

Don’t get me wrong: I recognize the benefits in the short term! But really long lived languages like FORTRAN, Lisp, C++ have benefited hugely from a spec-based standards approach adopted from other engineering practice. They have also benefited from cross-fertilization from different implementations which influenced later standard and thus each other.

This is why standards from building codes to electrical systems, to ships, manufacturing QC sampling, TCP/IP (and all the internet RFCs) and basically the entire corpus of ISO standards are spec based.

If you want to build long-lived engineered systems it’s worth learning from people who figured out a lot of the metaprocesses the hard way, some of them for more than a century ago.

[forrestthewoods]

We may just have to disagree on this one.

The fact that some things benefit from a spec does not mean that all do things do. Almost everything defined by the C++ committee since 2014 is awful. The specs, once published, are unable to evolve due to ABI.

The Rust standard library is soooooooo much better than C++’s. By leaps and bounds. And it continues to improve with time. C++ is far worse and far more stagnant. That’s lose/lose!

I don’t see how you could possibly claim that std::map and std::deque being a spec is a profound strength.

The fact that you celebrate non-spec implementations such as Abseil and Folly seem to me to be evidence supporting implementations over specs!

To be clear I’m talking about the standard library, not the core language syntax.

[kazinator]

Computer programs that other computer programs use all require a detailed functional spec.

Entertainment software, not so much.

In between, you need varying amounts of spec.

[forrestthewoods]

> Computer programs that other computer programs use all require a detailed functional spec.

And yet most programs that are used by other programs do not provide a detailed functional spec! How curious.

Most computer programs do not a formal, detailed, functional spec. They simply are what they are. Furthermore, the type of specs we are talking about are incomplete and purposefully leave a lot of room open to implementers to make different choices. Their choices are unspecified but fully relied upon.

Hyrum's Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

std::deque has an underdefined spec such that the MSVC implementation meets the spec but is utterly worthless. And it can't be fixed because that would break the ABI.

In this thread I'm specifically talking about the C++ standard library specification and implementations. Whether other software benefits from a detailed spec or not is outside the scope of this conversation. I maintain that the C++ standards committee should provide a std::deque implementation and not a spec. Thus far no one has even attempted to argue why it's better as a spec. Womp womp.