4 ms·

But didn't some version of Objective-C use a GC? My understanding was that the reason it didn't work well was because of issues with the language and not the li

But didn't some version of Objective-C use a GC? My understanding was that the reason it didn't work well was because of issues with the language and not the libraries. So they could still have used a GC for Swift?

pjmlp 7y ago
The reason it did not work was indeed the language, given the underlying C semantics of Objective-C. However Objective-C ARC is basically the compiler taking care of Cocoa retain/release patterns. Swift needed to provide a seemless path forward to integrate with Objective-C libraries so reference counting was the easist way forward. Microsoft has chosen another way to interoperate with COM from .NET, which requires an additional layer. https://docs.microsoft.com/en-us/dotnet/standard/native-interop/runtime-callable-wrapper https://docs.microsoft.com/en-us/dotnet/standard/native-inte... https://docs.microsoft.com/en-us/dotnet/standard/native-interop/com-callable-wrapper https://docs.microsoft.com/en-us/dotnet/standard/native-inte... Although is is quite alright to use, it adds an additional complexity that most likely Apple wasn't willing to make use of.
- lokedhs 7y ago
  So if I understand it correctly, Apple decided to move that complexity to the language itself? I was reading up on the rules for references in Swift, and it looks like a lot of complexity and lots of opportunities for introducing errors leading to leaks.
  - pjmlp 7y ago
    That is the price to pay for reference counting as approach to automatic memory management. If you want to hide circular references from developers, then a cycle collector is required on the runtime. For example this was the approach taken by Mesa/Cedar, or for a more modern reference CPython. If you look into C++/CX or C++/WinRT, this issue is also surfaced to the programmer. Rust makes it even more explicit with its reference counting library types. At the end of the day, it depends on what Swift designers were optimising for. Which to me looks like the easiest and less performance impact to integrate with the Objective-C runtime and respective libraries. Swift's approach is still easier than doing the same from Objective-C, its target audience.

pjmlp 7y ago

The reason it did not work was indeed the language, given the underlying C semantics of Objective-C. However Objective-C ARC is basically the compiler taking care of Cocoa retain/release patterns. Swift needed to provide a seemless path forward to integrate with Objective-C libraries so reference counting was the easist way forward. Microsoft has chosen another way to interoperate with COM from .NET, which requires an additional layer. https://docs.microsoft.com/en-us/dotnet/standard/native-interop/runtime-callable-wrapper https://docs.microsoft.com/en-us/dotnet/standard/native-inte... https://docs.microsoft.com/en-us/dotnet/standard/native-interop/com-callable-wrapper https://docs.microsoft.com/en-us/dotnet/standard/native-inte... Although is is quite alright to use, it adds an additional complexity that most likely Apple wasn't willing to make use of.

lokedhs 7y ago
So if I understand it correctly, Apple decided to move that complexity to the language itself? I was reading up on the rules for references in Swift, and it looks like a lot of complexity and lots of opportunities for introducing errors leading to leaks.
- pjmlp 7y ago
  That is the price to pay for reference counting as approach to automatic memory management. If you want to hide circular references from developers, then a cycle collector is required on the runtime. For example this was the approach taken by Mesa/Cedar, or for a more modern reference CPython. If you look into C++/CX or C++/WinRT, this issue is also surfaced to the programmer. Rust makes it even more explicit with its reference counting library types. At the end of the day, it depends on what Swift designers were optimising for. Which to me looks like the easiest and less performance impact to integrate with the Objective-C runtime and respective libraries. Swift's approach is still easier than doing the same from Objective-C, its target audience.