3 ms·

I certainly don't disagree that there's too much C++ in Swift (the Swift architects write C++ for a living, not ObjC, so it's hardly surprising) but it's not du

I certainly don't disagree that there's too much C++ in Swift (the Swift architects write C++ for a living, not ObjC, so it's hardly surprising) but it's not due to trendiness. Most of the features you mention derive from direct experience with Objective-C. Function arguments, property accessors (get/set/didSet), extensions (categories), etc. Every one of these things solves a real problem in the field. I don't understand your comment about reference counting being intrusive. Apple's implementation, ARC, used in Swift and modern ObjC, is essentially invisible to you if you're using native objects.

geophile 7y ago
I don't agree that get/set/didSet solve actual problems. Languages without property accessors do just fine, but then they don't overload the getting and setting of variables. I would much rather right thing.setField(123), and have setField do whatever actions need to accompany the assignment; than write thing.field = 123, and then have the actions be hidden. What is so f'ing special about x = thing.field and thing.field = x syntax? Why is it so important to stuff additional semantics into that syntax? As for reference counting: I'm referring to capture lists, and the "unowned self" hack needed with closures. E.g. https://www.raywenderlich.com/966538-arc-and-memory-management-in-swift#toc-anchor-011 https://www.raywenderlich.com/966538-arc-and-memory-manageme.... And it gets more complicated with @escaping. I sure don't view all these subtle interactions of closures and ARC to be invisible. This stuff is subtle. Get it wrong and you have leaks.
- fauigerzigerk 7y ago
  I agree. Here's an article that has really opened my eyes on how subtle reference cycles can be: http://marksands.github.io/2018/05/15/an-exhaustive-look-at-memory-management-in-swift.html http://marksands.github.io/2018/05/15/an-exhaustive-look-at-... I have pasted the most egregious example here: https://news.ycombinator.com/item?id=21919728 https://news.ycombinator.com/item?id=21919728
fauigerzigerk 7y ago
>I don't understand your comment about reference counting being intrusive. It's intrusive because you can never really stop thinking about it if you want to write correct code. Here's an example from a very interesting article by Mark Sands [1]: How quickly can you tell whether or not this piece of code has a reference cycle? class ServiceLayer { // ... private var task: URLSessionDataTask? func foo(url: URL) { task = URLSession.shared.dataTask(with: url) { data, response, error in let result = // process data DispatchQueue.main.async { [weak self] in self?.handleResult(result) } } task?.resume() } deinit { task?.cancel() } } In my view, reference counting does not combine very well with heavy use of closures. [1] This is an interesting read: http://marksands.github.io/2018/05/15/an-exhaustive-look-at-memory-management-in-swift.html http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...
- Matthias247 7y ago
  > How quickly can you tell whether or not this piece of code has a reference cycle? I'm curious. Does it? I would have guessed the "weak self" would have prevented it. > In my view, reference counting does not combine very well with heavy use of closures. It's one of the area where one has to be careful for sure! C++ with smart pointers and callbacks exhibits the same problem. And GC based languages make the pattern easier for sure. However I think this is not even the most critical error source in callback based designs. I think threading issues due to callbacks being executed on different threads cause the most trouble. Therefore I think languages like Javascript and Dart - which only offer a single thread AND GC - are the the easiest to use for callback based designs.
  - fauigerzigerk 7y ago
    Yes, there's still a reference cycle because the outer closure implicitly captures self as well. The article explains it in greater detail. I agree that threading is another big gotcha, arguably a bigger one. Rust has some mitigations against that sort of thing.

geophile 7y ago

I don't agree that get/set/didSet solve actual problems. Languages without property accessors do just fine, but then they don't overload the getting and setting of variables. I would much rather right thing.setField(123), and have setField do whatever actions need to accompany the assignment; than write thing.field = 123, and then have the actions be hidden. What is so f'ing special about x = thing.field and thing.field = x syntax? Why is it so important to stuff additional semantics into that syntax? As for reference counting: I'm referring to capture lists, and the "unowned self" hack needed with closures. E.g. https://www.raywenderlich.com/966538-arc-and-memory-management-in-swift#toc-anchor-011 https://www.raywenderlich.com/966538-arc-and-memory-manageme.... And it gets more complicated with @escaping. I sure don't view all these subtle interactions of closures and ARC to be invisible. This stuff is subtle. Get it wrong and you have leaks.

fauigerzigerk 7y ago
I agree. Here's an article that has really opened my eyes on how subtle reference cycles can be: http://marksands.github.io/2018/05/15/an-exhaustive-look-at-memory-management-in-swift.html http://marksands.github.io/2018/05/15/an-exhaustive-look-at-... I have pasted the most egregious example here: https://news.ycombinator.com/item?id=21919728 https://news.ycombinator.com/item?id=21919728

fauigerzigerk 7y ago

>I don't understand your comment about reference counting being intrusive. It's intrusive because you can never really stop thinking about it if you want to write correct code. Here's an example from a very interesting article by Mark Sands [1]: How quickly can you tell whether or not this piece of code has a reference cycle? class ServiceLayer { // ... private var task: URLSessionDataTask? func foo(url: URL) { task = URLSession.shared.dataTask(with: url) { data, response, error in let result = // process data DispatchQueue.main.async { [weak self] in self?.handleResult(result) } } task?.resume() } deinit { task?.cancel() } } In my view, reference counting does not combine very well with heavy use of closures. [1] This is an interesting read: http://marksands.github.io/2018/05/15/an-exhaustive-look-at-memory-management-in-swift.html http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

Matthias247 7y ago
> How quickly can you tell whether or not this piece of code has a reference cycle? I'm curious. Does it? I would have guessed the "weak self" would have prevented it. > In my view, reference counting does not combine very well with heavy use of closures. It's one of the area where one has to be careful for sure! C++ with smart pointers and callbacks exhibits the same problem. And GC based languages make the pattern easier for sure. However I think this is not even the most critical error source in callback based designs. I think threading issues due to callbacks being executed on different threads cause the most trouble. Therefore I think languages like Javascript and Dart - which only offer a single thread AND GC - are the the easiest to use for callback based designs.
- fauigerzigerk 7y ago
  Yes, there's still a reference cycle because the outer closure implicitly captures self as well. The article explains it in greater detail. I agree that threading is another big gotcha, arguably a bigger one. Rust has some mitigations against that sort of thing.