October 10, 2022

On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

>

I guess you did something wrong, :)

Didn't work in clang for me… but good to know that it is supposed to work.

As it stands, you shouldn't rely on clang for anything beyond C++17, it is hit and miss with newer revisions until some big shot takes over Apple and Google's role on frontend development.

October 10, 2022

On Monday, 10 October 2022 at 16:59:56 UTC, Quirin Schroll wrote:

>

On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

>

I guess you did something wrong, :)

#include <string>
#include <iostream>

constexpr std::string hello() {
    return std::string("hello world");
}

int main() {
    static constexpr auto greeting = hello();

    std::cout << greeting << std::endl;
}

This only works because you initialize the std::string with a literal. It fails on this:

     return std::string("hello ") + "world";

Because that was what I was replying to in first place.

As for your example, I have to cross check it on VC++ 2022 latest and its current support for upcoming ISO C++23, and what ISO says about it.

October 11, 2022

On Monday, 10 October 2022 at 18:23:42 UTC, Paulo Pinto wrote:

>

On Monday, 10 October 2022 at 16:59:56 UTC, Quirin Schroll wrote:

>

On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

>

I guess you did something wrong, :)

#include <string>
#include <iostream>

constexpr std::string hello() {
    return std::string("hello world");
}

int main() {
    static constexpr auto greeting = hello();

    std::cout << greeting << std::endl;
}

This only works because you initialize the std::string with a literal. It fails on this:

     return std::string("hello ") + "world";

Because that was what I was replying to in first place.

As for your example, I have to cross check it on VC++ 2022 latest and its current support for upcoming ISO C++23, and what ISO says about it.

And the conclusion is, when using C++ latest compliance to C++23, VC++ 2022 19.33 complains about it, while VC++ 2022 latest is more than happy to handle it,

VS 2022 19.33 => https://godbolt.org/z/ofes3a78z

VS 2022 latest => https://godbolt.org/z/v1Y8Ec65W

In C++23 most string related operations are now constexpr.

https://eel.is/c++draft/string.classes

October 11, 2022

On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

>

As it stands, you shouldn't rely on clang for anything beyond C++17, it is hit and miss with newer revisions until some big shot takes over Apple and Google's role on frontend development.

I am good. You can to some extent test and provide fall-backs if you want to write portable open source code that is based on C++20 features:

https://en.cppreference.com/w/cpp/feature_test
open source code that is based on C++20.

October 11, 2022

On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

>

On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

>

I guess you did something wrong, :)

Didn't work in clang for me… but good to know that it is supposed to work.

As it stands, you shouldn't rely on clang for anything beyond C++17, it is hit and miss with newer revisions until some big shot takes over Apple and Google's role on frontend development.

Why is Apple not willing to develop clang nowadays? Haven't seen them express interest in Carbon or anything other than Swift

October 11, 2022

On Tuesday, 11 October 2022 at 14:49:44 UTC, Tejas wrote:

>

On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

>

On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

>

I guess you did something wrong, :)

Didn't work in clang for me… but good to know that it is supposed to work.

As it stands, you shouldn't rely on clang for anything beyond C++17, it is hit and miss with newer revisions until some big shot takes over Apple and Google's role on frontend development.

Why is Apple not willing to develop clang nowadays? Haven't seen them express interest in Carbon or anything other than Swift

Swift is a much better language than C++, why would they invest in a buggy, ugly, messy and bloated language?

Apple main audience is system/app developers, they have taste and want to enable people to do tasteful things, C++ is ugly

Have you tried SwiftUI? give it a try, you'll understand why

October 11, 2022

On Tuesday, 11 October 2022 at 14:49:44 UTC, Tejas wrote:

>

On Monday, 10 October 2022 at 18:19:29 UTC, Paulo Pinto wrote:

>

On Monday, 10 October 2022 at 16:27:11 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 10 October 2022 at 14:18:52 UTC, Paulo Pinto wrote:

>

I guess you did something wrong, :)

Didn't work in clang for me… but good to know that it is supposed to work.

As it stands, you shouldn't rely on clang for anything beyond C++17, it is hit and miss with newer revisions until some big shot takes over Apple and Google's role on frontend development.

Why is Apple not willing to develop clang nowadays? Haven't seen them express interest in Carbon or anything other than Swift

clang is good enough for their purposes, Metal Shading Language is a C++14 dialect, IO Kit uses a Embedded C++ dialect and C++17 is good enough for DriverKit and is the current baseline for LLVM contributions.

Swift is explicitly developed as the replacement for C, C++ and Objective-C on Apple platforms, this goal is even mentioned on its documentation and they made the point to re-assert it on this year's WWDC.

The analysis of iOS 16 binaries apparently shows that "Swift adoption continues its exponential climb and surpassed C++ this year".

https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/

Note that while Apple has released a header only library for using Metal APIs from C++, not only it is a very bare bones experience when compared with Objective-C and Swift, it actually depends on the Objective-C runtime, by creating wrapper classes around objc_msgSend.

October 11, 2022

On Tuesday, 11 October 2022 at 15:56:11 UTC, Paulo Pinto wrote:

>

Swift is explicitly developed as the replacement for C, C++ and Objective-C on Apple platforms, this goal is even mentioned on its documentation and they made the point to re-assert it on this year's WWDC.

The analysis of iOS 16 binaries apparently shows that "Swift adoption continues its exponential climb and surpassed C++ this year".

C++ is starting to become EOL and languages like Swift will take over more and more. Swift is cross platform and available on Linux and Windows.

SwiftUI is currently Apple only but if they decide to make it open source so that others can adapt it for Linux GUIs and Windows then it becomes even more interesting, it's basically a Qt or C# MAUI competitor.

Currently Swift is not bootstrapped and there is a lot of C++ in the compiler itself. Right now there is a lot of work to make Swift work together with C++. Similar to D this is step to gradually rewrite the Swift compiler in Swift. Swift will just as D have the same C++ FFI advantage.

There is currently very little reason to choose C++ over any other modern alternative today for a new project. We will clearly see that as big companies contributions for C++ will wane. Will there even be enough interest to implement C++23?

October 11, 2022
On Monday, 10 October 2022 at 07:30:38 UTC, Kagamin wrote:
>>In contrast, C++ code attempting to call non-constexpr functions (i.e. functions only accessible at run time) in a constexpr context (i.e. functions which are available both at compile time and run time) will give an error at the call site.
>
> Eh? So can C++ support an allocator that works both at compile time and at run time? I use such allocator in my D code so it's ctfeable.

Yes, it does, but it has limits https://www.cppstories.com/2021/constexpr-new-cpp20/

As for the comment about C++ code attemping to call non-constexpr functions. Careful with not marking functions constexpr. I used to think it was a hell of thing. But if you think of it, constexpr is part of the user contract. You could make a function non-ctfe by accident in D and break user code. C++ is explicit about it.
October 11, 2022

On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

>

Currently Swift is not bootstrapped and there is a lot of C++ in the compiler itself. Right now there is a lot of work to make Swift work together with C++.

That's almost certain that the Swift language developpers need that interop to bootstrap the language since they use the LLVM C++ API.