I think as can be related to this topic as described in this PR.

I think we had a discussion where Herb talked about how he talked with the C# team and that there were issues with having the nullable support throughout the language, and that he didn't want to tackle that just yet. I tried searching for it but couldn't find it.

That's #27 (comment).

Thanks @JohelEGP!

I'm especially wary of the C# treatment of optional and null, because for years now I've been hearing from the C# design team that plumbing nullability through the C# language cost more than it was worth. We should learn from the experience of other languages, not only what they did but how it worked out for them and whether they would do it again. (I don't know if that experience about language support for nullability was the same as their language support for optionality.)

I can see "plumbing nullability through the C# language" as being very different than "syntactic sugar for dealing with null/optional". However, it does have some pitfalls that need to be dealt with as far as short circuiting and single execution that could be difficult to deal with in the conversion to C++1. I could also see wanting to combine nullability with the general concept of using as to determine "emptyness".

This issue comment is related to this topic.

So it seems C++2 will use is and as instead of ??, ?. and nullable types...

Some way to encourage people to use not_null smart pointers instead of regular nullable smart pointers. Maybe offer not_null_shared_ptr and optional_shared_ptr = std::optionalstd::shared_ptr

I would say that cpp2 could (or should) provide non-nullable smart pointers by default and have the user use the smart pointers in an optional otherwise. That way you could use the optional interface for null checking.
Also, if cpp2 has terser syntax for error handling other than try-catch blocks, maybe the same could be extended for null checking.
P2561 proposes a control flow operator which could be considered to compose with deterministic exceptions.

Modern languages like Typescript and Rust provide ways to really nicely work with optional types using different forms of null coalescing to values.

Typescript:

let x: string | undefined;
y = x! // throw if undefined. y must have type string
y = x ?? 'hello' // shorthand for x ? x : 'hello'. y must have type string
y = x?.endsWith('ello') // If x is undefined, return undefined. Etc

Saying "throw if undefined" and "return undefined" is probably a bit too casual. You're right that both Typescript and Rust offer sugar for dealing with optional-T types, but their semantics differ on whether the undefined/None case causes an implicit throw/return from the enclosing function. (I'd also be surprised if C++2's is and as would imply control flow like this).

• TypeScript example
• Rust example

I'll also note that, even though the OP mainly brought up TypeScript and its equivalent of C++'s std::optional<T>, Rust's ? operator can also apply to its Result equivalent of C++'s std::expected<T, E>.

I don't know of an idiomatic TypeScript equivalent of std::expected but, in Rust, its Option and Result types are ubiquitous.

Do we want C++2 to encourage std::expected use? @hsutter in #27 (comment) did say:

Do we have data that this is what we encourage C++ developers to do today by hand? I'm a fan of making default the things we already teach.

It's hard to measure what "we already teach" regarding std::expected since that only debuted in C++23. However:

• The Chromium web browser's C++ codebase defines RETURN_IF_ERROR and ASSIGN_OR_RETURN macros (with Rust-style "escape from the enclosing function if there's an error (and propagating that error)" semantics) for dealing with std::expected values. Chromium's base::expected is a C++17 compatible backport of C++23's std::expected.
• The STX library similarly defines TRY_OK(etc, result_expr) and TRY_SOME(etc, option_expr) macros that implicitly return on error/None.

As their capitalization suggests, RETURN_IF_ERROR and TRY_SOME are macros, because they need to be able to return. If C++2 doesn't have macros, then IIUC having equivalent ergonomics (when dealing with std::expected) would mean having to bake something (a ? operator or equivalent) into the language itself.

Do we want C++2 to encourage std::expected use?

While we don't want to encourage use of std::expected in cpp2, deterministic exceptions (error handling mechanisms in cpp2) is just expected built at a language level, so maybe we want to have something similar to rust's ? in cpp2. If we get that, then it'll be very easy to extend it to work with optional. Thats why I said,

Also, if cpp2 has terser syntax for error handling other than try-catch blocks, maybe the same could be extended for null checking.

Other than that, std::optional has a nice interface in cpp23 and cpp2 may want to capitalise on that.

Can you elaborate on why we don't? It seems weird to add std::expected to the latest-and-greatest C++ only to discourage its use

Because the intended error handling mechanism in cpp2 is supposed to be deterministic exceptions (or Herbceptions as many call them).
See Herb's P0709 for details.

Ah, I missed that you'd already mentioned P2561, "A control flow operator". That can't use a bare ? because of ambiguity with cpp1's ternary x?y:z, but cpp2 is less constrained.

I think I'm missing your point here but I'm not worried about syntax (as long as its short), more about if the feature has a place in cpp2 or not.

How about just using UFCS and monadic operations that are aware of the desired idiom?
This was inspired by the success of #741 (comment) while reading 2c03e41#diff-43ba71198da8225f205041c699dba495883d7d416c0b58916bf226aae97bafaeR4025-R4027:

 if (type.index() == a_function) {
 std::get<a_function>(type).get()->set_default_return_type_to_forward_wildcard();
 }

 (type as *function_typeid).and_then(:(inout x) = x.set_default_return_type_to_forward_wildcard());

• (type as *function_typeid) IIRC, std::optional is pointer-like, so as T is throwing and as *T fails with nullptr.
• .and_then(:(inout x) = This and_then works on pointers to std::optional, also acting as-if unengaged on nullptr.
• x.set_default_return_type_to_forward_wildcard()); We're given a reference to the object, so access it normally.