[rosshemsley]

Features I wish C++20 had:

* An opinionated, modern packaging and dependency story (like go modules, Rust crates)

* built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

* the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

Features C++20 actually has:

* new fancy spaceship operator that I'll now have to learn and never use...

[lone_haxx0r]

> built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

That's completely out of scope for a programming language pretending to be taken seriously as a general purpose one (including e.g. systems programming).

Also, your list looks like a pretty arbitrary choice of protocols and formats, why don't we also add support for SSH, SMPT, IMAP, PNG?. In the end, everyone would want their niche protocol/format to be included in the standard.

> the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

Cross-compiling to what architectures specifically? The most used ones are proprietary and I think that disqualifies them from being included in a serious international standard, since you'd need to read the spec and implement it in order to be compliant (I'm not versed in ISO inclusion requirements, so this may be already happening, but it would still be wrong. (grepping "x86" in the offical C standard returns no results though.)).

[zelly]

> built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

There is a Boost library for each of those things.

> An opinionated, modern packaging and dependency story (like go modules, Rust crates)

> the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

You can use Conan or vcpkg. LLVM basically solves the cross-compiling issue since you can take the IR to any platform that has a LLVM target.

Neither of these are feasible to include in the International Standard because C++ runs on more than amd64 and would make a lot of obscure platforms no longer compliant with the standard. Rust crates are nice, but people building medical devices with C++ shouldn't need to worry about supporting an npm-like monstrosity in their builds.

[steveklabnik]

LLVM IR is not platform independent.

Rust compiles on far more platforms than amd64, and Cargo works just fine.

Nothing forces you to depend on any packages you don’t want to.

[zelly]

> Nothing forces you to depend on any packages you don’t want to.

Nothing stops you, either, which is a problem for everyone in the future who uses your code. The first reaction to any problem in JavaScript/webdev is to google for a library to import to solve the problem. This is acceptable behavior because the existence of a web browser implies powerful enough resources to accommodate bloat. But this mentality isn't acceptable on other systems and has even infected some basic functionality:

https://crates.io/crates/rand

The random number generator for Rust has 6 dependencies. In C++, it's only lib[std]c++. In Java, it's java.base.

[pornel]

Random number generation has trade-offs for speed, security, and thread safety.

Most other langues with a "simple" built-in are unfit in some of these aspects, so you may end up with a footgun and still have to find a replacement.

In Rust you can choose which algorithms are used and how. And because it's a regular package, it can be improved without breaking the language.

Note that number of dependencies doesn't mean anything. Some crates are split into tiny deps for each feature, so that you can reduce binary size and compile time if you disable optional features.

[zelly]

That's true for libc's naive rand() which is used by Python, JS, Ruby, PHP, etc.

But stock C++ has many options for the random number generation algorithm:

https://en.cppreference.com/w/cpp/header/random

As does Java and .NET. Without any dependencies and guaranteed to be portable.

> Note that number of dependencies doesn't mean anything. Some crates are split into tiny deps for each feature, so that you can reduce binary size and compile time if you disable optional features.

In theory I agree. It just seems like one of the persistent unsolved problems in software is dependency hell (spawning the whole containerization movement), so I'd like to avoid it if I could.

[cjhanks]

C++ has many audiences with disparate needs; ranging from firmware, to scientific computing, to application development.

Most of the industries using the language optimize their code for a target platform. And general non-optimized portable binaries are simply not cost effective, so standardizing installation has not been simple.

If you do care about portability, you functionally need to. - ensure you're not linking to anything but LIBC and the VDSO

- compile with no assembly language

- disable most optimizations, and select a sufficiently generic hardware target. For the most part, they succeed in features.

- directly compile all 3rd party source in your binary.

Then, your binary should last a long time.

That all said, I believe your needs are in the minority in the C++ community, and other languages likely better suit your needs.

[nice_byte]

i never understood the need for package managers. just check your dependencies in and build with the rest of your source code. this doesn't introduce extra moving parts into the system (why should i need an internet connection to build my stuff?), easy to patch and debug dependencies, gives you full control and doesn't restrict your toolchain (e.g. conan doesn't as of now support vs2019+llvm). what i _would_ like to see though is a standardized build system for c++ projects, although that will likely never happen.

[zelly]

This is what most companies do irl for security reasons. It's also the easiest, most obvious solution with the least moving parts.

There will never be a standard build system, but CMake is the de facto standard build generator and works well enough.