New Standard library for cpp2?

[12345swordy]

Wouldn't it make sense to create a new standard cpp2 library to show what cpp2 is capable of when compare to the cpp1 standard library?

One of major criticisms that I have with regards to c++ is frequent use of std:: just to call the standard library function. That type of behavior in the cpp world has been normalized when it shouldn't, even in cases when you are just using the standard c++ library and nothing else!

• Alex

[AbhinavK00]

I have a question. Your criticisms don't align with your suggestion (for me). If cpp2 were to have a new standard library, it would still be under be some namespace (std2 for example) and instead of using "std::", we would use "std2::" or else. So this doesnt seem like the solution.

…

On Tue, 29 Aug 2023, 23:48 12345swordy, ***@***.***> wrote: Wouldn't it make sense to create a new standard cpp2 library to show what cpp2 is capable of when compare to the cpp1 standard library? One of major criticisms that I have with regards to c++ is frequent use of std:: just to call the standard library function. That type of behavior in the cpp world has been normalized when it shouldn't, even in cases when you are just using the standard c++ library and nothing else! - Alex — Reply to this email directly, view it on GitHub <#620>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2KJHTQEEONUNYJYJI763DTXXYW5TANCNFSM6AAAAAA4DLFAEY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JohelEGP]

Wouldn't it make sense to create a new standard cpp2 library to show what cpp2 is capable of when compare to the cpp1 standard library?

Creating a new standard library is out of scope for Cppfront, I believe.
Specially considering https://github.com/hsutter/cppfront#1-this-is-about-c2023--not-about-something-else.

Writing Cpp2 code is an improvement over Cpp1¹,
which is why you'd do it in the first place.
The C++ standard library is no special in this regard.

I think its more beneficial to write new extensions in Cpp2.
Like new range adaptors, and compare how simpler and safer it is.
The other day, I rewrote an API I've been rewriting forever.
I always improve on it, but this time it went much better than ever.
And I think the less mental burden when writing Cpp2 played a big part on it.

One of major criticisms that I have with regards to c++ is frequent use of std:: just to call the standard library function. That type of behavior in the cpp world has been normalized when it shouldn't, even in cases when you are just using the standard c++ library and nothing else!

Like Cppfront itself.
That's certainly permitted by SF.6.
But I always prefer explicit qualification, as it is the better practice over time.

---

¹: Except where Cpp2 or Cppfront can't meet your expectations yet.

[12345swordy]

Creating a new standard library is out of scope for Cppfront, I believe.
Specially considering https://github.com/hsutter/cppfront#1-this-is-about-c2023--not-about-something-else.

A standard library is just as important as the language itself. The Standard Template Library was a major selling point for C++ back then.

I think its more beneficial to write new extensions in Cpp2.

The last thing that Cpp2 needs is feature creep. Even more so when Cpp2 is in currently in experimentation mode and hasn't been "Officially" release for public use.

But I always prefer explicit qualification, as it is the better practice over time.

This is what I mean normalized behavior when it shouldn't. Even more so that we have modules.

[JohelEGP]

I think its more beneficial to write new extensions in Cpp2.

The last thing that Cpp2 needs is feature creep. Even more so when Cpp2 is in currently in experimentation mode and hasn't been "Officially" release for public use.

I literally meant writing new extension in Cpp2, not for Cpp2.
See the example that follows.
Writing a range adaptor in one's own library in Cpp2
doesn't affect the Cpp2 language, the Cppfront compiler, or the C++ standard, at all.

[hsutter]

@JohelEGP wrote:

The other day, I rewrote an API I've been rewriting forever.
I always improve on it, but this time it went much better than ever.
And I think the less mental burden when writing Cpp2 played a big part on it.

I'm very curious about this as I want to learn how it feels for others -- is there any chance you could make a short writeup about your experience with this, with a few code examples and your observations on things you noticed pro/con, as a blog post or even just a private email?

[JohelEGP]

Sure, I'll try to do that, using this Discussions category: https://github.com/hsutter/cppfront/discussions/categories/show-and-tell.

[JohelEGP]

Done: #658 (comment).

[YagaoDirac]

Hi. A brief question. What's gonna happen to all the std lib since c++14 if cpp2 is translating code into cpp11. Do we cpp2->cpp11, with std lib in cpp14/17/... and compile with cpp20/23? What about the auto completion? If the IDE dosen't recognise cpp14/17/... syntax.

[hsutter]

cppfront tracks the Standard. It currently requires a reasonably conforming C++20 compiler, and translates Cpp2 code to C++20, and supports (without requiring) most C++23 features. The entire C++ standard library is always available, including the latest C++23 features (if available on your system, checked by the standard feature tests).

[YagaoDirac]

Cool. Thanks.

[hsutter]

The entire C++ standard library is available. A few parts still require contortions to use (e.g., I haven't written declaring function types yet for std::function so you write an extra line as a workaround) but they are all intended to be available.

Using the C++ standard library, and other libraries, is intended to be "fully supported from Cpp2, but better when used from Cpp2." In particular, by default bounds checking is enabled, so using subscripting on any sequence container from Cpp2 code automatically does bounds checking (without any change to the library code, the check is injected at the Cpp2 call site).

For a few particularly dangerous C++ standard library features that we already teach people to avoid, I'm considering making them deliberately harder (e.g., require prefixing their names with unsafe_) or impossible to use from Cpp2. But I mostly haven't done that yet.

I do plan to continue adding things in cpp2util.h that the standard library doesn't yet have, when they improve safety or usability.

[SebastianTroy]

Oh that is interesting, I need to go look up what is considered unsafe and avoidable in the std library! On 3 December 2023 19:23:42 Herb Sutter ***@***.***> wrote: The entire C++ standard library is available. A few parts still require contortions to use (e.g., I haven't written declaring function types yet for std::function so you write an extra line as a workaround) but they are all intended to be available. Using the C++ standard library, and other libraries, is intended to be "fully supported from Cpp2, but better when used from Cpp2." In particular, by default bounds checking is enabled, so using subscripting on any sequence container from Cpp2 code automatically does bounds checking (without any change to the library code, the check is injected at the Cpp2 call site). For a few particularly dangerous C++ standard library features that we already teach people to avoid, I'm considering making them deliberately harder (e.g., require prefixing their names with unsafe_) or impossible to use from Cpp2. But I mostly haven't done that yet. I do plan to continue adding things in cpp2util.h that the standard library doesn't yet have, when they improve safety or usability. — Reply to this email directly, view it on GitHub<#620 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQK72KBHTEF7FTDLOQDYHTGTXAVCNFSM6AAAAAA4DLFAE2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONBVGY4TA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JohelEGP]

I also got interested, and searched the C++ Core Guidelines for "standard library".
This is what I found with regards to dangerous stuff:

• P.6: What cannot be checked at compile time should be checkable at run time

  Example, bad

  The standard library resource management pointers fail to pass the size when they point to an object:

  // separately compiled, possibly dynamically loaded
  // NB: this assumes the calling code is ABI-compatible, using a
  // compatible C++ compiler and the same stdlib implementation
  extern void f3(unique_ptr<int[]>, int n);
  
  void g3(int n)
  {
      f3(make_unique<int[]>(n), m);    // bad: pass ownership and size separately
  }
  

• ES.100-ES.102 and ES.107 on the use of signed and unsigned integer types.
  • ES.100: Don't mix signed and unsigned arithmetic

    Note

    Unfortunately, C++ uses signed integers for array subscripts and the standard library uses unsigned integers for container subscripts.
    This precludes consistency. Use gsl::index for subscripts; see ES.107.

  • ES.101: Use unsigned types for bit manipulation

    Enforcement

    • Just about impossible in general because of the use of unsigned subscripts in the standard library

  • ES.102: Use signed types for arithmetic

    Example

    The standard library uses unsigned types for subscripts.
    The built-in array uses signed types for subscripts.
    This makes surprises (and bugs) inevitable.

  • ES.107: Don't use unsigned for subscripts, prefer gsl::index
• The stub SL.4: Use the standard library in a type-safe manner
• SL.con.3: Avoid bounds errors (doesn't apply to Cpp2 code that is bounds-checked by default)

  If code is using an unmodified standard library, then there are still workarounds that enable use of std::array and std::vector in a bounds-safe manner. Code can call the .at() member function on each class, which will result in an std::out_of_range exception being thrown. Alternatively, code can call the at() free function, which will result in fail-fast (or a customized action) on a bounds violation.

• SL.con.4: don't use memset or memcpy for arguments that are not trivially-copyable
  Here, cpp2::mem𝘧𝘶𝘯 could be a constrained version.
  Possibly std::-qualified memset and memcpy can be rejected in Cpp2 code,
  and required to be accessed as cpp2::unsafe_mem𝘧𝘶𝘯,
  or explicitly qualified mem𝘧𝘶𝘯 if it doesn't actually resolve to the C++ standard library function.
• SL.C.1: Don't use setjmp/longjmp, same as above.