3 ms·

Well that’s a completely false statement. C++ is a first class language, and all C++ APIs and ABIs are stable. It is used extensively across macOS and iOS, and

by olliej 3y ago

Well that’s a completely false statement. C++ is a first class language, and all C++ APIs and ABIs are stable. It is used extensively across macOS and iOS, and has large amounts of support through out the apple provided dev tools. Significant improvements to the C++ UX were part of the motivation for clang. C++ is not used for the majority of platform APIs because of all the problems, difficulties, and costs of ensuring ABI stability. C++ ABIs are notoriously fragile, which is a problem objc does not have, and swift was designed specifically to reduce ABI issues (that’s part of the reason generics are implemented as they are)

jasode 3y ago
>Well that’s a completely false statement. C++ is a first class language, I understand your clarification but gp (jb1991) is just using a different meaning of "first class" than you and gp (bluetomcat). For some people, a "first class language status" would also include examples such as: - C++ would be a menu dropdown choice in Xcode project options. In Xcode's "choose options for your new project", the only language options for "Storyboard"/"XIB" are "Swift" and "Objective-C". - C++ would be the programming language and API for Apple's VR headset ARKit. Instead, it requires Swift and SwiftUI. - C++ language would be prominently featured as the code examples in Apple WWDC developer conferences and presentations. E.g. go to WWDC sessions page and compare Ctrl+F search hits count for "C++" vs "Swift": https://developer.apple.com/wwdc23/sessions/ https://developer.apple.com/wwdc23/sessions/ Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)." -- from https://github.com/apple/swift/blob/main/docs/tools/swift.pod#:~:text=Swift%20is%20intended%20as%20a%20replacement%20for%20C%2Dbased%20languages%20(C%2C%20C%2B%2B%2C%20and%20Objective%2DC) https://github.com/apple/swift/blob/main/docs/tools/swift.po.... Understandable that some don't include the above bullets but just pointing out that's what "1st class language" means to others. Maybe it's a sign that the term "first class" is too ambiguous and just invites disagreements.
- DerekL 3y ago
  Yes, it's not a first class language, but the parent explained why it can't be. If you tried to implement a dynamic library with a C++ interface, you can't add virtual functions to later versions of the library without breaking any clients that derive from those classes. You'd have to recompile all apps any time you made a change to the OS.
- olliej 3y ago
  You can create new projects in C++, you can't create new projects using UI Cocoa, UIKit, or SwiftUI in C++ because those APIs are not in C++, because C++ is generally bad as a language for APIs where ABI stability is important, but also seems to be particularly bad as a language for UI programming in general. The specific combination you get in Cocoa and UIKit is dynamic binding (requiring reflection) and developer subclassing of UI objects (causing aforementioned brittle ABI problems). But Xcode does not care about exactly what your project is, and those are just starting templates. Most projects I have ever worked on are combination C++ and (UI language). To me, you're using a very weird definition of what 1st class language support is. C++ is extremely heavily used, developed, and in invested in by Apple, and Xcode has extremely good and maintained support for it. It is not the language used for UI toolkits because C++ has proven to be bad at that task. Not applying the "everything is a nail" mentality to the C++ hammer is not "not a 1st class language" it's acknowledging one of the major deficiencies in the language. Your final 'Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)."' comment is certainly reflective of what I think some people want, but the fact that the article itself is on the topic of Apple working on interop between C++ and Swift should be a pretty good indication that C++ support is such high priority that swift is the only language working towards full interop with native C++. rust, go, etc all just say "write a C bridge", the MS story is managed C++, etc. Maybe in the future C++ won't be first class on the platform (probably good from safety PoV for all platforms), but that's not any time in the near future.
  - deleted 3y ago
    [deleted]
  - jb1991 3y ago
    > particularly bad as a language for UI programming in general. Interesting statement, considering how there are many popular and highly influential user interface frameworks in C++.
jb1991 3y ago
> Well that’s a completely false statement. There’s nothing false about whether you can write an app entirely in C++ or not. The only languages you can do this with are Swift and ObjC. You cannot get a window up, access platform features, interact with the frameworks with C++.
- olliej 3y ago
  You can write plenty of Mac and iOS programs - and much of the OS, and even XNU are - in C++. You can't use the UI toolkits, because time has shown again and again that C++ is particularly bad at UI toolkits, but also as my other longer answer said, idiomatic Cocoa and UIKit programming has significant subclassing of ui components, and even the most robustly and carefully designed C++ frameworks can't manage ABI stability well (if at all) in that case. It is pretty standard on apple platforms to have a ton of C++ doing things C++ is good at interacting with things in ObjC and Swift, and the fact the Apple is working to improve the c++/swift interop when every other new language has the response of "who cares about C++ interop? they can just write c interposition layers until they can replace an entire subset of the library all at once" demonstrates how important and well supported C++ is on the platform. Long term who knows. Despite the questionable equivocation about safety from Herb&Bjarne modern C++ is not safe, and new features that introduce lack of safety keep getting added while long term failings like the over reliance on UB for definable behaviour[1], and as long as that attitude remains my hopes for actually getting C++ to a place it can be used safely if it can ever be exposed to attacker control data remain low, and so the future would eventually see C and C++ being dropped everywhere. Looking forward to safe languages in the kernel: swift, rust, and the most popular safe language in the world: javascript!!!! :D [1] C++ has "unspecified behavior" and "implementation dependent behavior" that allow for different behaviour that people claim UB is needed for, without the "compiler can pretend this doesn't happen" nonsense

by olliej 3y ago

jasode 3y ago

>Well that’s a completely false statement. C++ is a first class language, I understand your clarification but gp (jb1991) is just using a different meaning of "first class" than you and gp (bluetomcat). For some people, a "first class language status" would also include examples such as: - C++ would be a menu dropdown choice in Xcode project options. In Xcode's "choose options for your new project", the only language options for "Storyboard"/"XIB" are "Swift" and "Objective-C". - C++ would be the programming language and API for Apple's VR headset ARKit. Instead, it requires Swift and SwiftUI. - C++ language would be prominently featured as the code examples in Apple WWDC developer conferences and presentations. E.g. go to WWDC sessions page and compare Ctrl+F search hits count for "C++" vs "Swift": https://developer.apple.com/wwdc23/sessions/ https://developer.apple.com/wwdc23/sessions/ Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)." -- from https://github.com/apple/swift/blob/main/docs/tools/swift.pod#:~:text=Swift%20is%20intended%20as%20a%20replacement%20for%20C%2Dbased%20languages%20(C%2C%20C%2B%2B%2C%20and%20Objective%2DC) https://github.com/apple/swift/blob/main/docs/tools/swift.po.... Understandable that some don't include the above bullets but just pointing out that's what "1st class language" means to others. Maybe it's a sign that the term "first class" is too ambiguous and just invites disagreements.

DerekL 3y ago
Yes, it's not a first class language, but the parent explained why it can't be. If you tried to implement a dynamic library with a C++ interface, you can't add virtual functions to later versions of the library without breaking any clients that derive from those classes. You'd have to recompile all apps any time you made a change to the OS.
olliej 3y ago
You can create new projects in C++, you can't create new projects using UI Cocoa, UIKit, or SwiftUI in C++ because those APIs are not in C++, because C++ is generally bad as a language for APIs where ABI stability is important, but also seems to be particularly bad as a language for UI programming in general. The specific combination you get in Cocoa and UIKit is dynamic binding (requiring reflection) and developer subclassing of UI objects (causing aforementioned brittle ABI problems). But Xcode does not care about exactly what your project is, and those are just starting templates. Most projects I have ever worked on are combination C++ and (UI language). To me, you're using a very weird definition of what 1st class language support is. C++ is extremely heavily used, developed, and in invested in by Apple, and Xcode has extremely good and maintained support for it. It is not the language used for UI toolkits because C++ has proven to be bad at that task. Not applying the "everything is a nail" mentality to the C++ hammer is not "not a 1st class language" it's acknowledging one of the major deficiencies in the language. Your final 'Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)."' comment is certainly reflective of what I think some people want, but the fact that the article itself is on the topic of Apple working on interop between C++ and Swift should be a pretty good indication that C++ support is such high priority that swift is the only language working towards full interop with native C++. rust, go, etc all just say "write a C bridge", the MS story is managed C++, etc. Maybe in the future C++ won't be first class on the platform (probably good from safety PoV for all platforms), but that's not any time in the near future.
- deleted 3y ago
  [deleted]
- jb1991 3y ago
  > particularly bad as a language for UI programming in general. Interesting statement, considering how there are many popular and highly influential user interface frameworks in C++.

jb1991 3y ago

> Well that’s a completely false statement. There’s nothing false about whether you can write an app entirely in C++ or not. The only languages you can do this with are Swift and ObjC. You cannot get a window up, access platform features, interact with the frameworks with C++.

olliej 3y ago
You can write plenty of Mac and iOS programs - and much of the OS, and even XNU are - in C++. You can't use the UI toolkits, because time has shown again and again that C++ is particularly bad at UI toolkits, but also as my other longer answer said, idiomatic Cocoa and UIKit programming has significant subclassing of ui components, and even the most robustly and carefully designed C++ frameworks can't manage ABI stability well (if at all) in that case. It is pretty standard on apple platforms to have a ton of C++ doing things C++ is good at interacting with things in ObjC and Swift, and the fact the Apple is working to improve the c++/swift interop when every other new language has the response of "who cares about C++ interop? they can just write c interposition layers until they can replace an entire subset of the library all at once" demonstrates how important and well supported C++ is on the platform. Long term who knows. Despite the questionable equivocation about safety from Herb&Bjarne modern C++ is not safe, and new features that introduce lack of safety keep getting added while long term failings like the over reliance on UB for definable behaviour[1], and as long as that attitude remains my hopes for actually getting C++ to a place it can be used safely if it can ever be exposed to attacker control data remain low, and so the future would eventually see C and C++ being dropped everywhere. Looking forward to safe languages in the kernel: swift, rust, and the most popular safe language in the world: javascript!!!! :D [1] C++ has "unspecified behavior" and "implementation dependent behavior" that allow for different behaviour that people claim UB is needed for, without the "compiler can pretend this doesn't happen" nonsense