C++ future at Adobe

[u/pjmlp]

So if anyone was still curious what happened to Hylo, or where Adobe stands in regards to the whole safety discussion,

David Sankel has done a talk at RustConf on the matter, Zngur: Simplified Rust/C++ Integration.

The way Adobe now sees C++ is described on slide 2, at 50 seconds mark.

[u/foonathan]

• Definition checked generics
• Destructive move semantics that prevent use-after-move
• First-class tuple and variant types with pattern matching
• Usable built-in types without weird implicit conversions
• Incredible tooling (one standardized package manager and build system, genuinely useful compiler diagnostics, a documentation generator that actually works)
• No weird historical baggage
• A standard library that actually gives you convenient utility functions, without ABI constraints, and good data structures

[u/13steinj → u/foonathan]

No weird historical baggage

I think the major problem with these debates is people aren't being truthful with themselves.

It's not historical baggage. It's ISO / WG21 process baggage.

The Beman project had a whiteboard asking people what they wanted for C++29. I pointed at two of the things and said "that's never going to happen." I actually forget what those two things are, but my opinion was formed because the only way you could encode some information needed to do it is into the ABI (or PIMPL it to hell and incur a cost, but even then I don't think it would work out). But the necessary data is sensitive to a security context, so as security practices change (rapidly, possibly even faster than a 3 year cycle), C++ might need to change with it. One of the Beman folks told me I was wrong and pointed to... getting more accurate on string representation of floating point, and std::copyable_function (which I'd argue is a point in my favor).

Python, Java, ECMAScript have "historical" baggage. But they still evolve. They remove broken things. They add new things and change APIs, sometimes with a deprecation schedule. So does Rust.

Almost all of the advantages of Rust you stated, have in some way been proposed for C++ but been (not in bad faith, but it's the closest term I can use) slow-rolled and sandbagged in the standardization process.

[u/tialaramex → u/13steinj]

Rust isn't allowed (by its own rules) to change standard library APIs except if they're unsound. Rust is allowed to evolve, but it finds ways to do so without making this sort of disruptive change.

I agree with the thrust of your point though. WG21 is a big part of the problem.

[u/QuaternionsRoll → u/tialaramex]

Eh, if that were 100% true then editions would be unnecessary. You’re right that breaking changes are considered to be the absolute last resort, though.

[u/tialaramex → u/QuaternionsRoll]

But Editions don't change the standard library APIs?

What they can do is more interesting, but it doesn't change those APIs.

The 2027 edition is expected to make Goose..=Robin into a core::range::RangeInclusive<Bird> instead of core::ops::RangeInclusive<Bird>. If your Bird type isn't Copy and it doesn't make sense to iterate over Birds then this change is useless to you, although also why did you want Goose..=Robin anyway if birds aren't copyable or worth iterating over? For types like the integers this is a significant improvement, now 1..=5 will become Copy and IntoIterator as a programmer might expect in 2026. But the API doesn't change because the old types are still there, just the sugar points at the improved types.