6 ms·

Swift for C++ Practitioners, Part 1: Intro and Value Types

147 points by ksec 3y ago

airstrike 3y ago
Swift is a great language. I just wish I could seriously use it outside of iOS development
- _mlbt 3y ago
  It actually has pretty decent support on Linux. It’s in Fedora’s official repos and Apple provides official builds for several other popular distros. The biggest issue seems to be that much of the larger ecosystem assumes Apple platforms.
- JoeMattiello 3y ago
  I do all my swift CI/CD for non UI code in girthub actions on the Debian image for some time now due to lower cost and faster run times. I even use Swift on a ARM raspberry Pi docker cluster. Windows is officially supported for some time with networking and nearly all of foundation ported if that’s not complete yet. The only real issue you have is at the UI level. There are some web and even ncurses libraries using SwiftUI like DSLs Now with the new macro features you can get a lot more flexibility for cross platform builds. C++ interoperability is also possible with latest versions. It was a hidden flag for a couple years. I’ve wrapped many C++ emulators in Swift over the last year with Cmake to Xcode projects.
- timsneath 3y ago
  Thank you for the compliment! We're working on improving its support for other use cases, with work to better support embedded[1], server[2], and AI[3] use cases, along with Linux[4] and Windows[5] support. We're also putting a lot of energy into improving support for these scenarios in Visual Studio Code [6]. Would love to hear more about scenarios folk are looking at, as well as specific gaps that are blocking you adopting Swift for non-Apple platforms. We're building a roadmap now and would love to make sure our work items are comprehensive. [1] https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md https://github.com/apple/swift-evolution/blob/main/visions/e... [2] https://www.swift.org/blog/sswg-update-2024/ https://www.swift.org/blog/sswg-update-2024/ [3] https://www.swift.org/blog/mlx-swift/ https://www.swift.org/blog/mlx-swift/ [4] https://www.swift.org/blog/adwaita-swift/ https://www.swift.org/blog/adwaita-swift/ [5] https://www.swift.org/blog/swift-everywhere-windows-interop/ https://www.swift.org/blog/swift-everywhere-windows-interop/ [6] https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
  - airstrike 3y ago
    I think if you could honestly use Swift outside of Xcode it would already be a massive improvement. I know you "can", but you really can't. It's painful. The experience would have to be at least 1-to-1 in terms of developer experience. When I use cargo/rust-analyzer in vscode, I feel at home and empowered. When I try to write Swift in vscode, I feel handicapped SwiftUI is an incredibly powerful paradigm. It feels like the future compared to most GUI programming today. It is also possibly the most easily seen and best-known value of Swift today. Enabling and empowering the community to create similar abstractions outside of Mac OS/iOS would go a long way to making the language more commonly used, but I understand that's a responsibility that doesn't fall squarely on the Swift team. Case in point, the adwaita-swift and the swift-everywhere-windows-interop projects. The first looks fine (although it is just a "Counter" sample project) but the latter looks DOA/unviable. As a dev, I wouldn't even consider the latter and adwaita has the disadvantage of not being cross platform Look at the sheer number of tools, languages and frameworks trying to solve the modern day "write once, run anywhere" of declarative guis. Tauri/Dioxus, React Native, Flutter, iced-rs (my personal favorite)... the list goes on. There's a real need here that Swift could help solve without forcing people into JavaScript or Rust. The former being too browser-focused (for better or worse, but I argue worse) and the latter having too steep a learning curve I feel like a lot of the Swift-outside-of-Apple effort has been on server/embedded work, but in those domains, why wouldn't I choose Python/Node+JS or C/C++/Rust which already have a strong foothold, respectively? That's a much harder battle to fight from an adoption perspective IMHO
  - serial_dev 3y ago
    That's great and appreciated, and hopefully will have an impact in a couple of years. Today if I search for Swift jobs, it's a list of exclusively iOS app developer jobs.
  - terhechte 3y ago
    Something I'd love to see is being able to use the VSCode extension for iOS / macOS development. I wouldn't expect all the bells and whistles of Xcode obviously (e.g. previews, run integration). However I'd love to use VSCode because I prefer their tradeoffs to Xcodes. The advantage for Swift would be that potentially more developers use the VSCode extension which would hopefully improve the quality and incentivise more of them to maybe contribute to it. If it's already possible then maybe a section in the readme on how to achieve this? (e.g. how to open an iOS project folder and get completions for Apple's frameworks).
- glhaynes 3y ago
  It's popping up more and more because it's so flexible and great to work in. I've spent my weekend working on a Swift project for the Playdate (https://play.date https://play.date)!
- serial_dev 3y ago
  Yes, sometimes the languages are great and versatile, but when it comes to the job market, your options are much more limited. Do you like Swift? Good, you better also like iOS development. Dart? You better be happy with UI with Flutter. Even with Rust to a degree... If I'm looking for jobs where I could exclusively work with Rust, it's crypto blockchain. Web listings might include Rust but usually come with Python, JavaScript or Go. Even if you are lucky and you'll find one job that offers what you like, yourself painting into a corner and tie yourself to one employer.
  - pjmlp 3y ago
    This is the reason why on the employers I have worked for, usually the language choice goes on the opposite direction most language geeks would like. "Product/Platform we are targeting" => set of allowed languages as per their SDKs, official support documents. The approach "pick language" => "select problem" tends to only work at startup levels, or being very lucky with the IT department policies.
  - cageface 3y ago
    This is what's put me off getting deeper into Rust. I love the language but won't work on cryptocurrency stuff.
- neonsunset 3y ago
  C# would probably be the closest thing feature-wise (and, often, syntax-wise) if you need first-class Linux support, and a lot of knowledge is directly transferable. Not a Java copy people claim it to be but something more low-level :) With that said, Swift enjoys better FFI by virtue of using LLVM and lower base memory footprint since it does not need to maintain data structures used by GC. Performance however will vary case by case, ARC generally has way higher upfront cost than GC, especially in multi-threaded scenarios but lends itself to an overall more deterministic memory usage, which is important on memory-constrained systems.
jacobgorm 3y ago
Am I the only one who finds the term Practitioners both overused and offensive?
- y1n0 3y ago
  Offensive? Why?
  - jacobgorm 3y ago
    The way it often is used as a politically correct way of saying "grunt programmer", as opposed to PhD-wielding "expert". Why not just C++ "programmers" instead of C++ "practitioners" in the case of this article? I'm a PhD in CS who writes C++ all day long, and I think of myself neither as an "expert" or as a "practitioner", but as a programmer.
    - y1n0 3y ago
      Thanks for the reply. I had no idea people used practitioner in a derogatory way. If anything I thought it was a little hoity-toity , so that’s good to know :)
- tialaramex 3y ago
  To me the association is Nurse Practitioner, which in the UK is a Nurse upgrade. Nurse is a "normal" undergraduate degree, Nurse Practitioner requires a post-graduate Masters to top that up and grants Prescribing rights like you'd get if you were a Doctor. The Nurses end up with weaker Chemistry, but much stronger practical experience before being granted prescription rights. Their PGT does a bunch about how to read & understand research papers, so that they can stay on the cutting edge and contribute to their discipline.
jmaker 3y ago
I love Swift but had to stop every time before getting serious for several reasons. As a language it’s just amazing. But whenever it’s come to performance on the backend, it would be not enough by a large margin. Take JSON serialization for instance, even using a yyjson wrapper it’s been nowhere near the original C performance, slower than Jackson, nlohmann::json, Go’s stdlib, and serde of course. I tried several Swift libraries. Model definition for custom deserializers alone for the few common ISO timestamp representations is a bit cumbersome but bearable. With some other formats and protocols I use, Swift is similarly underwhelming. Logging takes a large toll in performance as well, regardless of what a library appears to suggest when speaking of “efficiency.” I just can’t seem to squeeze out enough performance out of Swift. Async Postgres IO was quite good until I ramped up the load. TechEmpower benchmarks place Vapor relatively low. I get much better performance from low-effort Spring on Kotlin, needless to mention more performant backend frameworks. Then the IDE story is very bleak. While I’m on Macs, Xcode just doesn’t cut it for me to be productive. Jetbrains discontinued their dedicated IDE and their Vscode pendent is still experimental. Vscode proper support for Swift is not really worth mentioning in my opinion. So I’m basically left with Xcode as an IDE for Swift. I so dearly wanted to introduce Swift on the backend at my company but that’s just unrealistic right now.
- jcelerier 3y ago
  > slower than [...] nlohmann::json considering that nlohmann::json not even a performance-oriented json library, generally benchmarking at 20% of the performance of RapidJSON (which itself is not even close to the fastest you can reach in C++) that's... scary
- pourred 3y ago
  I noticed the same thing. Either Swift performances are atrocious, or I'm missing something. Just the other day I was trying to sort a large array of strings in Swift and it was painfully slow. A 3 lines Python script managed to sort the same dataset _at least_ 10x faster.
  - _rend 3y ago
    I think it'd be curious to see the code, some example strings, and whether or not you compiled with optimizations enabled — if you're willing to share. There's no reason for this to have been the case.
pdpdpd 3y ago
Swift is an incredible language for thinking again. I dearly miss being able to write code in it on a daily basis. Although I will say, the compilation time is a killer. It would have been ideal if they had an interpreted mode for development.
mojuba 3y ago
Great article and I wish there were more of X for Y practitioners. In my "wanted" list: Kotlin for Swift practitioners, Rust for Swift practitioners.
turdprincess 3y ago
Id be interested in a C++ for Swift developers version.
- chunkyguy 3y ago
  Here you go https://whackylabs.com/swift/cpp/languages/2021/01/03/cpp-for-swift-devs/ https://whackylabs.com/swift/cpp/languages/2021/01/03/cpp-fo...
- _mlbt 3y ago
  Not exactly what you asked for, but in my humble opinion Stroustrup’s Tour of C++ is one of the best books for getting up to speed quickly with C++ if you know other languages… https://www.stroustrup.com/tour2.html https://www.stroustrup.com/tour2.html
  - richrichie 3y ago
    I own both versions of this book, the first one is almost one third the size of the latest. :)
    - pjmlp 3y ago
      That is sadly the thing with backwards compatibility, it is only additive. Nowadays on Java and .NET worlds, we live through our own versions of Python 2, thanks to Java 8 => 9 transition, and .NET Framework => .NET Core.
- bryzaguy 3y ago
  Have you read it? I felt like it goes both directions. As someone more in the Swift camp, I was learning about C++ too.
gilgoomesh 3y ago
If you're not aware, the author is Doug Gregor, one of the lead developers on the Swift team at Apple. Parts 1 to 5 in this series were all posted on the same day: https://mastodon.social/@dgregor79@sfba.social/112253040283087966 https://mastodon.social/@dgregor79@sfba.social/1122530402830...
- plorkyeran 3y ago
  And former lead developer on Clang at Apple.
  - gpderetta 3y ago
    And former Boost and C++ standard committee contributor. In particular he was one of the main authors of the classic C++0x Concept proposal (as opposed to the concept-lite that eventually made it into the standard).
    - pjmlp 3y ago
      Many of the Swift features for generic programing and protocols are based on the way C++0x Concept proposal went down, as mentioned by Dave Abrahams in some of his interviews.
MBCook 3y ago
I’ve been doing some swift for a while, it’s a great language. This is the first time I’ve heard you could do recursive enum cases. Very neat! I wonder if that’s recent or not.
- airspeedswift 3y ago
  Been there since 2.0. You can combine it with pattern matching to do some fun stuff: https://gist.github.com/airspeedswift/6e0c037ad5dd1b763d353f358791eef7#file-rbtree-swift-L43 https://gist.github.com/airspeedswift/6e0c037ad5dd1b763d353f...
cancerhacker 3y ago
Coming from a C (and derivative) background, this was a good article to help map idioms and introduce new patterns. I still mentally translate to C in my head though.
ankurdhama 3y ago
I wonder why Swift went with the approach of struct is a value type and class is a reference type. This approach means that when I am defining my type, I have to decide whether it will be used as value type or reference type whereas in C++ same type can be used as reference type (pass by reference) or value type (pass by value) in different situations.
- chromatin 3y ago
  This is exactly the approach taken by Walter Bright in Dlang, IIRC. https://dlang.org/spec/struct.html https://dlang.org/spec/struct.html
- mrtksn 3y ago
  I only guess but maybe because in Swift they encourage you to use value types whenever possible, so you have to make a conscious decision when you are steering away from the default. This way it emphasises a particular way of reasoning about the code. Also, it's pretty straightforward to create a reference type of a value type if you end up need it: Just create a new type that is a reference type and has the value type as a property. No?
- dwaite 3y ago
  Generally you don't use reference types until you encounter a need for something to be a reference type, such as being a reference to a particular resource, or for usage compatibility with an external system. For example, there are something like eight classes exposed in the minimal swift standard library, representing concepts like managed buffers, singletons like the MainActor, and for implementing concepts like task-local values. These are all examples of types which do not lend themselves to being value types. Once you start getting to file and network I/O, or interfacing with Objective-C, you start to see the percentage of reference types climb.
  - cageface 3y ago
    Unfortunately the new Observation framework in SwiftUI currently forces you to use classes to model your data. Hopefully they can find some way to make it work with value types.
saagarjha 3y ago
> As in C++, many Swift types are value types, including String, Array, and Dictionary, which are analogous to std::string, std::vector, and std::map Dictionary is probably more analogous to std::unordered_map, since it’s an associated hashed-key container. > The result is on the stack, not the heap, just like you'd expect in C++. Even though this is likely true I don’t think it’s guaranteed, and if it does happen to be the case I would be cautious to bring it up anyway. Swift leaks things into the heap quite eagerly in ways that might be surprising to C++ developers, where this typically requires more ceremony (or is an express train to UAF :P)
mgaunard 3y ago
If the value semantics aren't customizable, you can't really build abstractions. How would you even implement std::list? Ultimately Swift is dependent on having all significant abstractions be built as part of the language-enabled standard library.
- cobbal 3y ago
  enum List<T> { case empty; indirect case cons(T, List<T>) }
- saagarjha 3y ago
  std::list (that is, a linked list) is pretty easy to write. Whether you want it to be a reference type or copy-on-write or a Collection (probably very difficult) is up to you. There’s not much that’s special in the standard library.
  - mgaunard 3y ago
    std::list is a value type which copies the underlying elements on copy.
    - saagarjha 3y ago
      This is how most Swift Collections work as well
      - mgaunard 3y ago
        Yet not something that can be written in pure Swift.
        saagarjha 3y ago
        What makes you think this?
  - liuliu 3y ago
    The problem is you cannot implement a reference type without dropping to UnsafePointer or use class. But using class is so discourage nowadays people probably would be better served by adding an Arc / Ref type wrapper like Rust did.

147 points by ksec 3y ago

airstrike 3y ago

Swift is a great language. I just wish I could seriously use it outside of iOS development

_mlbt 3y ago
It actually has pretty decent support on Linux. It’s in Fedora’s official repos and Apple provides official builds for several other popular distros. The biggest issue seems to be that much of the larger ecosystem assumes Apple platforms.
JoeMattiello 3y ago
I do all my swift CI/CD for non UI code in girthub actions on the Debian image for some time now due to lower cost and faster run times. I even use Swift on a ARM raspberry Pi docker cluster. Windows is officially supported for some time with networking and nearly all of foundation ported if that’s not complete yet. The only real issue you have is at the UI level. There are some web and even ncurses libraries using SwiftUI like DSLs Now with the new macro features you can get a lot more flexibility for cross platform builds. C++ interoperability is also possible with latest versions. It was a hidden flag for a couple years. I’ve wrapped many C++ emulators in Swift over the last year with Cmake to Xcode projects.
timsneath 3y ago
Thank you for the compliment! We're working on improving its support for other use cases, with work to better support embedded[1], server[2], and AI[3] use cases, along with Linux[4] and Windows[5] support. We're also putting a lot of energy into improving support for these scenarios in Visual Studio Code [6]. Would love to hear more about scenarios folk are looking at, as well as specific gaps that are blocking you adopting Swift for non-Apple platforms. We're building a roadmap now and would love to make sure our work items are comprehensive. [1] https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md https://github.com/apple/swift-evolution/blob/main/visions/e... [2] https://www.swift.org/blog/sswg-update-2024/ https://www.swift.org/blog/sswg-update-2024/ [3] https://www.swift.org/blog/mlx-swift/ https://www.swift.org/blog/mlx-swift/ [4] https://www.swift.org/blog/adwaita-swift/ https://www.swift.org/blog/adwaita-swift/ [5] https://www.swift.org/blog/swift-everywhere-windows-interop/ https://www.swift.org/blog/swift-everywhere-windows-interop/ [6] https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
- airstrike 3y ago
  I think if you could honestly use Swift outside of Xcode it would already be a massive improvement. I know you "can", but you really can't. It's painful. The experience would have to be at least 1-to-1 in terms of developer experience. When I use cargo/rust-analyzer in vscode, I feel at home and empowered. When I try to write Swift in vscode, I feel handicapped SwiftUI is an incredibly powerful paradigm. It feels like the future compared to most GUI programming today. It is also possibly the most easily seen and best-known value of Swift today. Enabling and empowering the community to create similar abstractions outside of Mac OS/iOS would go a long way to making the language more commonly used, but I understand that's a responsibility that doesn't fall squarely on the Swift team. Case in point, the adwaita-swift and the swift-everywhere-windows-interop projects. The first looks fine (although it is just a "Counter" sample project) but the latter looks DOA/unviable. As a dev, I wouldn't even consider the latter and adwaita has the disadvantage of not being cross platform Look at the sheer number of tools, languages and frameworks trying to solve the modern day "write once, run anywhere" of declarative guis. Tauri/Dioxus, React Native, Flutter, iced-rs (my personal favorite)... the list goes on. There's a real need here that Swift could help solve without forcing people into JavaScript or Rust. The former being too browser-focused (for better or worse, but I argue worse) and the latter having too steep a learning curve I feel like a lot of the Swift-outside-of-Apple effort has been on server/embedded work, but in those domains, why wouldn't I choose Python/Node+JS or C/C++/Rust which already have a strong foothold, respectively? That's a much harder battle to fight from an adoption perspective IMHO
- serial_dev 3y ago
  That's great and appreciated, and hopefully will have an impact in a couple of years. Today if I search for Swift jobs, it's a list of exclusively iOS app developer jobs.
- terhechte 3y ago
  Something I'd love to see is being able to use the VSCode extension for iOS / macOS development. I wouldn't expect all the bells and whistles of Xcode obviously (e.g. previews, run integration). However I'd love to use VSCode because I prefer their tradeoffs to Xcodes. The advantage for Swift would be that potentially more developers use the VSCode extension which would hopefully improve the quality and incentivise more of them to maybe contribute to it. If it's already possible then maybe a section in the readme on how to achieve this? (e.g. how to open an iOS project folder and get completions for Apple's frameworks).
glhaynes 3y ago
It's popping up more and more because it's so flexible and great to work in. I've spent my weekend working on a Swift project for the Playdate (https://play.date https://play.date)!
serial_dev 3y ago
Yes, sometimes the languages are great and versatile, but when it comes to the job market, your options are much more limited. Do you like Swift? Good, you better also like iOS development. Dart? You better be happy with UI with Flutter. Even with Rust to a degree... If I'm looking for jobs where I could exclusively work with Rust, it's crypto blockchain. Web listings might include Rust but usually come with Python, JavaScript or Go. Even if you are lucky and you'll find one job that offers what you like, yourself painting into a corner and tie yourself to one employer.
- pjmlp 3y ago
  This is the reason why on the employers I have worked for, usually the language choice goes on the opposite direction most language geeks would like. "Product/Platform we are targeting" => set of allowed languages as per their SDKs, official support documents. The approach "pick language" => "select problem" tends to only work at startup levels, or being very lucky with the IT department policies.
- cageface 3y ago
  This is what's put me off getting deeper into Rust. I love the language but won't work on cryptocurrency stuff.
neonsunset 3y ago
C# would probably be the closest thing feature-wise (and, often, syntax-wise) if you need first-class Linux support, and a lot of knowledge is directly transferable. Not a Java copy people claim it to be but something more low-level :) With that said, Swift enjoys better FFI by virtue of using LLVM and lower base memory footprint since it does not need to maintain data structures used by GC. Performance however will vary case by case, ARC generally has way higher upfront cost than GC, especially in multi-threaded scenarios but lends itself to an overall more deterministic memory usage, which is important on memory-constrained systems.

jacobgorm 3y ago

Am I the only one who finds the term Practitioners both overused and offensive?

y1n0 3y ago
Offensive? Why?
- jacobgorm 3y ago
  The way it often is used as a politically correct way of saying "grunt programmer", as opposed to PhD-wielding "expert". Why not just C++ "programmers" instead of C++ "practitioners" in the case of this article? I'm a PhD in CS who writes C++ all day long, and I think of myself neither as an "expert" or as a "practitioner", but as a programmer.
  - y1n0 3y ago
    Thanks for the reply. I had no idea people used practitioner in a derogatory way. If anything I thought it was a little hoity-toity , so that’s good to know :)
tialaramex 3y ago
To me the association is Nurse Practitioner, which in the UK is a Nurse upgrade. Nurse is a "normal" undergraduate degree, Nurse Practitioner requires a post-graduate Masters to top that up and grants Prescribing rights like you'd get if you were a Doctor. The Nurses end up with weaker Chemistry, but much stronger practical experience before being granted prescription rights. Their PGT does a bunch about how to read & understand research papers, so that they can stay on the cutting edge and contribute to their discipline.

jmaker 3y ago

I love Swift but had to stop every time before getting serious for several reasons. As a language it’s just amazing. But whenever it’s come to performance on the backend, it would be not enough by a large margin. Take JSON serialization for instance, even using a yyjson wrapper it’s been nowhere near the original C performance, slower than Jackson, nlohmann::json, Go’s stdlib, and serde of course. I tried several Swift libraries. Model definition for custom deserializers alone for the few common ISO timestamp representations is a bit cumbersome but bearable. With some other formats and protocols I use, Swift is similarly underwhelming. Logging takes a large toll in performance as well, regardless of what a library appears to suggest when speaking of “efficiency.” I just can’t seem to squeeze out enough performance out of Swift. Async Postgres IO was quite good until I ramped up the load. TechEmpower benchmarks place Vapor relatively low. I get much better performance from low-effort Spring on Kotlin, needless to mention more performant backend frameworks. Then the IDE story is very bleak. While I’m on Macs, Xcode just doesn’t cut it for me to be productive. Jetbrains discontinued their dedicated IDE and their Vscode pendent is still experimental. Vscode proper support for Swift is not really worth mentioning in my opinion. So I’m basically left with Xcode as an IDE for Swift. I so dearly wanted to introduce Swift on the backend at my company but that’s just unrealistic right now.

jcelerier 3y ago
> slower than [...] nlohmann::json considering that nlohmann::json not even a performance-oriented json library, generally benchmarking at 20% of the performance of RapidJSON (which itself is not even close to the fastest you can reach in C++) that's... scary
pourred 3y ago
I noticed the same thing. Either Swift performances are atrocious, or I'm missing something. Just the other day I was trying to sort a large array of strings in Swift and it was painfully slow. A 3 lines Python script managed to sort the same dataset _at least_ 10x faster.
- _rend 3y ago
  I think it'd be curious to see the code, some example strings, and whether or not you compiled with optimizations enabled — if you're willing to share. There's no reason for this to have been the case.

pdpdpd 3y ago

Swift is an incredible language for thinking again. I dearly miss being able to write code in it on a daily basis. Although I will say, the compilation time is a killer. It would have been ideal if they had an interpreted mode for development.

mojuba 3y ago

Great article and I wish there were more of X for Y practitioners. In my "wanted" list: Kotlin for Swift practitioners, Rust for Swift practitioners.

turdprincess 3y ago

Id be interested in a C++ for Swift developers version.

chunkyguy 3y ago
Here you go https://whackylabs.com/swift/cpp/languages/2021/01/03/cpp-for-swift-devs/ https://whackylabs.com/swift/cpp/languages/2021/01/03/cpp-fo...
_mlbt 3y ago
Not exactly what you asked for, but in my humble opinion Stroustrup’s Tour of C++ is one of the best books for getting up to speed quickly with C++ if you know other languages… https://www.stroustrup.com/tour2.html https://www.stroustrup.com/tour2.html
- richrichie 3y ago
  I own both versions of this book, the first one is almost one third the size of the latest. :)
  - pjmlp 3y ago
    That is sadly the thing with backwards compatibility, it is only additive. Nowadays on Java and .NET worlds, we live through our own versions of Python 2, thanks to Java 8 => 9 transition, and .NET Framework => .NET Core.
bryzaguy 3y ago
Have you read it? I felt like it goes both directions. As someone more in the Swift camp, I was learning about C++ too.

gilgoomesh 3y ago

If you're not aware, the author is Doug Gregor, one of the lead developers on the Swift team at Apple. Parts 1 to 5 in this series were all posted on the same day: https://mastodon.social/@dgregor79@sfba.social/112253040283087966 https://mastodon.social/@dgregor79@sfba.social/1122530402830...

plorkyeran 3y ago
And former lead developer on Clang at Apple.
- gpderetta 3y ago
  And former Boost and C++ standard committee contributor. In particular he was one of the main authors of the classic C++0x Concept proposal (as opposed to the concept-lite that eventually made it into the standard).
  - pjmlp 3y ago
    Many of the Swift features for generic programing and protocols are based on the way C++0x Concept proposal went down, as mentioned by Dave Abrahams in some of his interviews.

MBCook 3y ago

I’ve been doing some swift for a while, it’s a great language. This is the first time I’ve heard you could do recursive enum cases. Very neat! I wonder if that’s recent or not.

airspeedswift 3y ago
Been there since 2.0. You can combine it with pattern matching to do some fun stuff: https://gist.github.com/airspeedswift/6e0c037ad5dd1b763d353f358791eef7#file-rbtree-swift-L43 https://gist.github.com/airspeedswift/6e0c037ad5dd1b763d353f...

cancerhacker 3y ago

Coming from a C (and derivative) background, this was a good article to help map idioms and introduce new patterns. I still mentally translate to C in my head though.

ankurdhama 3y ago

I wonder why Swift went with the approach of struct is a value type and class is a reference type. This approach means that when I am defining my type, I have to decide whether it will be used as value type or reference type whereas in C++ same type can be used as reference type (pass by reference) or value type (pass by value) in different situations.

chromatin 3y ago
This is exactly the approach taken by Walter Bright in Dlang, IIRC. https://dlang.org/spec/struct.html https://dlang.org/spec/struct.html
mrtksn 3y ago
I only guess but maybe because in Swift they encourage you to use value types whenever possible, so you have to make a conscious decision when you are steering away from the default. This way it emphasises a particular way of reasoning about the code. Also, it's pretty straightforward to create a reference type of a value type if you end up need it: Just create a new type that is a reference type and has the value type as a property. No?
dwaite 3y ago
Generally you don't use reference types until you encounter a need for something to be a reference type, such as being a reference to a particular resource, or for usage compatibility with an external system. For example, there are something like eight classes exposed in the minimal swift standard library, representing concepts like managed buffers, singletons like the MainActor, and for implementing concepts like task-local values. These are all examples of types which do not lend themselves to being value types. Once you start getting to file and network I/O, or interfacing with Objective-C, you start to see the percentage of reference types climb.
- cageface 3y ago
  Unfortunately the new Observation framework in SwiftUI currently forces you to use classes to model your data. Hopefully they can find some way to make it work with value types.

saagarjha 3y ago

> As in C++, many Swift types are value types, including String, Array, and Dictionary, which are analogous to std::string, std::vector, and std::map Dictionary is probably more analogous to std::unordered_map, since it’s an associated hashed-key container. > The result is on the stack, not the heap, just like you'd expect in C++. Even though this is likely true I don’t think it’s guaranteed, and if it does happen to be the case I would be cautious to bring it up anyway. Swift leaks things into the heap quite eagerly in ways that might be surprising to C++ developers, where this typically requires more ceremony (or is an express train to UAF :P)

mgaunard 3y ago

If the value semantics aren't customizable, you can't really build abstractions. How would you even implement std::list? Ultimately Swift is dependent on having all significant abstractions be built as part of the language-enabled standard library.

cobbal 3y ago
enum List<T> { case empty; indirect case cons(T, List<T>) }
saagarjha 3y ago
std::list (that is, a linked list) is pretty easy to write. Whether you want it to be a reference type or copy-on-write or a Collection (probably very difficult) is up to you. There’s not much that’s special in the standard library.
- mgaunard 3y ago
  std::list is a value type which copies the underlying elements on copy.
  - saagarjha 3y ago
    This is how most Swift Collections work as well
    - mgaunard 3y ago
      Yet not something that can be written in pure Swift.
      - saagarjha 3y ago
        What makes you think this?
- liuliu 3y ago
  The problem is you cannot implement a reference type without dropping to UnsafePointer or use class. But using class is so discourage nowadays people probably would be better served by adding an Arc / Ref type wrapper like Rust did.