mikeash.com pyblog/friday-qa-2014-06-20-interesting-swift-features.html commentshttp://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsmikeash.com Recent CommentsFri, 29 Mar 2024 11:04:41 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssPAOK - 2017-11-27 04:45:46http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsBolches yarboclos, Batman! <br /> <br />At last I understood this optionals stuff. <br />a28e6204790b3a7f24d46c57efbb4d6eMon, 27 Nov 2017 04:45:46 GMTSuraj Pawar - 2016-01-19 07:06:22http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsNice Article .4d30f0fafacf38e8ac9ce6bac184b36dTue, 19 Jan 2016 07:06:22 GMTJulian - 2015-12-07 13:17:25http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsJust a quick note: <br />we don't do if(ptr) free(ptr); because we are afraid it might be NULL and break something; Usually AFTER freeing an element you set it to NULL so you don't free it again by mistake later on. The issue is not freeing a NULL pointer but double-freeing a valid one. Objects alleviate this immensely. b44cf898e445fe2afbab7538a019f06bMon, 07 Dec 2015 13:17:25 GMTAnand Mishra - 2015-04-29 10:16:25http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsGreat Post . I think this is one of best post i ever read for swift. <br /> <br />Nicely explain new feature like optional, multi value. <br /> <br />i would like if you share more article about swift. b4e31178825a8177b15ef6793dc5b96bWed, 29 Apr 2015 10:16:25 GMTJosh Smith - 2014-08-26 18:37:59http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsGreat post, as always, Mike. I'm curious to hear your thoughts on a thread marshaling operator I invented, if you have a moment. <br /> <br /><a href="http://ijoshsmith.com/2014/07/05/custom-threading-operator-in-swift/">http://ijoshsmith.com/2014/07/05/custom-threading-operator-in-swift/</a> <br /> <br />Thanks!1b260d8504216f345497a1654ab37f9bTue, 26 Aug 2014 18:37:59 GMTMatthew Purland - 2014-07-17 18:34:06http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>Rainer Brockerhoff</b>: Thanks for the snippet. This also seems to work for synchronized to return a value and synchronized closures that accept object as input and a return value. <br /><code> <br />func synchronized&lt;T&gt;(object: AnyObject, closure: () -&gt; T) -&gt; T { <br />&nbsp;&nbsp;&nbsp;&nbsp;objc_sync_enter(object) <br />&nbsp;&nbsp;&nbsp;&nbsp;let val: T = closure() <br />&nbsp;&nbsp;&nbsp;&nbsp;objc_sync_exit(object) <br />&nbsp;&nbsp;&nbsp;&nbsp;return val <br />} <br /> <br />func synchronizedWith&lt;A: AnyObject, T&gt;(object: A, closure: (value: A) -&gt; T) -&gt; T { <br />&nbsp;&nbsp;&nbsp;&nbsp;objc_sync_enter(object) <br />&nbsp;&nbsp;&nbsp;&nbsp;let val: T = closure(value: object) <br />&nbsp;&nbsp;&nbsp;&nbsp;objc_sync_exit(object) <br />&nbsp;&nbsp;&nbsp;&nbsp;return val <br />} <br /></code>0e66eb2731a4eb391991034a0fe7a627Thu, 17 Jul 2014 18:34:06 GMTmikeash - 2014-07-05 05:24:32http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>Jorge:</b> Enums are indeed odd. I think it's a naming thing more than anything. For those of us coming from C, we should probably think of them as two separate cases. Plain enums which just list a bunch of constants are just like C. Enums with associated values are more like a collection of subclasses, and share nothing in common with C enums except the name. It just happens that Swift lets you do both with the same language construct. It will take some time to get used to the idea of using <code>enum</code> for more than just defining integer constants, and how best to use them.ca9a738693b69a2b02f4f56981814cceSat, 05 Jul 2014 05:24:32 GMTJorge - 2014-07-04 21:49:22http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>Russ Bishop</b>: WordPress rocks. <br /> <br /><b>Mike</b> thanks for the article, much appreciated. I'm struggling with the concept of... enums with methods. Sounds very, very odd.b24f7176bf3d643fadeb8c4d8ca3dbe1Fri, 04 Jul 2014 21:49:22 GMTmikeash - 2014-06-30 18:33:41http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>Russ Bishop:</b> That's why I wrote my own. But it still sucks.a9b6cde61f56c315b80e699105f6983bMon, 30 Jun 2014 18:33:41 GMTRuss Bishop - 2014-06-30 14:38:08http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsI'm starting to think I have to move platforms; I don't have access to the stylesheets or much else. I originally went with Silvrback because I could get a blog running instantly and my previous experience with Wordpress left me a broken shell of a human being... It's great for being able to just click and start writing, with auto-save, and live previewing of the results but I can't fix the stylesheets, I can't include HTML or any custom markup, etc. <br /> <br />Why do all blog platforms suck?a41f51b3530de115514ca93f4cb210bdMon, 30 Jun 2014 14:38:08 GMTmikeash - 2014-06-30 14:05:27http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>Russ Bishop:</b> Nice posts. If I may make a brief off-topic comment, I'd suggest getting rid of the border from your syntax highlighting stylesheet's "err" class, as it's getting annoyed at your @. I ran into the same thing here, once upon a time.a1c3e91b8cb85b6955ff4ca1eb268707Mon, 30 Jun 2014 14:05:27 GMTRuss Bishop - 2014-06-30 06:13:05http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>austinz</b>: You can use @auto_closure for a sort of call by name, which I covered here: <a href="http://www.russbishop.net/swift-call-by-name">http://www.russbishop.net/swift-call-by-name</a> <br /> <br /> <br /><b>mike</b>: I've been trying to blog some about interop with C (the docs are extremely thin on that), see below. Perhaps an overview of the various CMutableVoidPointer/COpaquePointer/UnsafePointer/etc would be good? <br /> <br /><a href="http://www.russbishop.net/swift-manual-retain-release">http://www.russbishop.net/swift-manual-retain-release</a> <br /><a href="http://www.russbishop.net/swift-withunsafepointertoelements">http://www.russbishop.net/swift-withunsafepointertoelements</a> <br /><a href="http://www.russbishop.net/swift-pointers-everywhere">http://www.russbishop.net/swift-pointers-everywhere</a> <br /> <br />bd5245c22ff7a1c2693511c20ec842d1Mon, 30 Jun 2014 06:13:05 GMTmikeash - 2014-06-29 03:03:24http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>Chris Lattner:</b> I'm really glad to hear that, and it sounds like a lot of other people are too. <br /> <br /><b>Clemens Gruber:</b> There are really two different kinds of "call Obj-C++ from Swift": 1) accessing Objective-C classes, extern "C" functions, constants, etc. that just happen to live within an Objective-C++ file, and 2) accessing C++ classes, functions, templates, etc. <br /> <br />Taking the second one first, the C++ object model is so complex that it's impractical to automatically bridge. Objective-C++ has a ton of dark corner cases because of C++, and this comes from bolting on an extremely simple set of extensions to the language and otherwise leveraging the existing compiler. Getting Swift to deal with it would be a huge task, tantamount to implementing a C++ compiler within the Swift compiler. For a concrete example, consider <code>std::vector</code>, which is implemented entirely in the header file because it's a templated class and templated classes in C++ are often frightening like this. In order to instantiate a <code>std::vector</code>, you have to parse all of its code, specialize it for the type you want it to contain, then turn that all into machine code. Which is to say, you need a C++ compiler. Compare with something like instantiating an <code>NSArray</code>, which exists entirely in a library with a simple interface, so it's just a few calls to <code>objc_msgSend</code> with some obvious parameters. You could skip over anything with header implementations and only allow bridging to C++ classes with prototypes in the headers, but given how common these header-implementations are in C++, you'd severely limit your universe in strange and confusing ways, like not being able to call any function that takes a <code>std::vector</code> or any other STL container. <br /> <br />For the first one, bridging to stuff with C linkage compiled in Objective-C++ files... I actually expect that works now, as long as your headers are compatible with plain Objective-C. Swift shouldn't care about where your implementation lives or how it's built, it'll only care about the headers. It won't be able to deal with C++ constructs in the headers, because that opens the whole can of worms above, but as long as you can present a clean Objective-C interface, an Objective-C++ implementation should be fine. If it doesn't work now for some reason, I would expect it to be made to work before too long, as there shouldn't be any fundamental obstacle.a016e94ea8ba947abb428d4ff5588debSun, 29 Jun 2014 03:03:24 GMTClemens Gruber - 2014-06-28 14:08:38http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsHi, nice article. <br /> <br />I am curious why we can't call Obj-C++ from Swift, is there a technical reason against it? <br />Will this be added/fixed later on? <br /> <br />(Sure we can write wrappers, but I'd really like to know why it is not supported)137350eb340994a5b79347fbf01e60b3Sat, 28 Jun 2014 14:08:38 GMTJens Jakob Jensen - 2014-06-26 22:29:06http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>macshome:</b> Until Mike Ash completes his articles about Swift, I've written a quick intro for ObjC programmers, including some non-obvious goodies, which should kick-start your Swift skills :-) Please have a look.3e9f26f48033c347c29f380ecf941713Thu, 26 Jun 2014 22:29:06 GMTKim - 2014-06-26 19:41:41http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments@Bruce: you could get around the closure not used problem with <br /><code> <br />&nbsp;{ <br />&nbsp;&nbsp;&nbsp;&nbsp;... <br />&nbsp;}() <br /></code>1a408e802dcfa2bec9f50e81d51bfd67Thu, 26 Jun 2014 19:41:41 GMTFarley Caesar - 2014-06-26 19:37:32http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments.@Chris: That's fantastic news. Having truly immutable Swift Arrays will be awesome. Thanks. b579f88d3baf47055dfec23992ff6140Thu, 26 Jun 2014 19:37:32 GMTBruce Hoult - 2014-06-26 02:50:39http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsThere's a big problem with using trailing closures to implement unless() or synchronized() or the like, as if they were syntax in the langauge. <br /> <br />While you can access most things from the surrounding lexical environment inside the closure, you can't access loop or labeled loops to use "break" or "continue". In the closure body you are not in a loop. <br /> <br />There is another gotcha from using the same syntax for syntax as for closures. Unlike in C/C++/ObjC you can't just casually write a set of braces to delimit a scope for a temporary variable, or just to make code clearer: <br /> <br /><code> <br />let t = ... <br />... <br />foo() <br />... <br />{ <br />&nbsp;&nbsp;let x = t + 10 <br />&nbsp;&nbsp;if x &lt; 100 { <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;... <br />&nbsp;&nbsp;} <br />} <br /></code> <br /> <br />If you do this in Swift you get something like "closure not used". <br /> <br />But if you do something like... <br /> <br /><code> <br />do { <br />&nbsp;&nbsp;let x = t + 10 <br />&nbsp;&nbsp;if x &lt; 100 { <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;... <br />&nbsp;&nbsp;} <br />} while false <br /></code> <br /> <br />.. then it is happy with you. Because *those* { } are just syntax, not a closure. <br />fd367256b0bf5ae60ea06c59195d2474Thu, 26 Jun 2014 02:50:39 GMTChris Lattner - 2014-06-25 21:32:49http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsI can confirm that array semantics are going to change significantly in later seeds, to be more similar to dictionary and strings. <br />2ba71511053a8017a556bc4ef9c091faWed, 25 Jun 2014 21:32:49 GMTmikeash - 2014-06-25 01:22:50http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsArray/dictionary mutability in general seems sensible. It was initially weird to me that it's tied to <code>let</code> and <code>var</code>, but that made sense once I understood that they were <code>struct</code>s and what that entailed. <br /> <br />The business where constant arrays still have mutable elements is crazy. Fortunately, I'm pretty sure I heard somewhere that this will be changed.6cce7fd6770e0a264f39288427f1f967Wed, 25 Jun 2014 01:22:50 GMTJim k - 2014-06-24 19:29:58http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsI'd love to hear your thoughts on the mutability of arrays and dictionaries, specifically how you cannot change the length of a constant array, but you can swap out individual objects. <br /> <br />Documentation says that this is for performance reasons, but there's already some overhead inherent in a Swift array, I don't see how putting restrictions on setting elements would cause significant additional overhead.2aa40c9bbc50c463cd8777304adf9385Tue, 24 Jun 2014 19:29:58 GMTRobert Payne - 2014-06-23 03:33:26http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsAs far as Ruby goes &lt;&lt; works well because bit shifting is extremely rare and adding to the end is extremely common. <br /> <br />In Ruby "&lt;&lt;" always means add to the end unless contextually it looks like numbers are being bit shifted. <br /> <br />Also in Ruby "&lt;&lt;" isn't an operator, it's just a method that quite a few classes implement.a28709223d08e7a08d9deeb60fc8b0d6Mon, 23 Jun 2014 03:33:26 GMTmikeash - 2014-06-23 01:24:04http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsI'm not actually referring to the ternary operator there, but rather to a binary operator that's defined as <code>x ?: y</code> being the same as <code>x ? x : y</code> except that <code>x</code> is only evaluated once.46158669f06582302c00e6d6f4dc297dMon, 23 Jun 2014 01:24:04 GMTDennis - 2014-06-22 19:37:30http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments&lt;I&gt;(Let's ignore for a moment the nonstandard ?: operator which provides this exact behavior.)&lt;I&gt; <br /> <br />Did you mean nonstandard here? The ternary operator has been a standard part of C for as long as I remember. It's even in the 2nd edition of the K&amp;R book. 0cffcab2ea8b401037d59b8a13041049Sun, 22 Jun 2014 19:37:30 GMTaustinz - 2014-06-22 04:12:29http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsLast suggestion: I think it would be great to see a discussion of @lazy and @auto-closure, especially because there are some interesting call-by-name semantics you can implement using the latter (if I'm understanding those two annotations correctly).4bf0810cd2b364ee03b8dc1123c2e073Sun, 22 Jun 2014 04:12:29 GMTmikeash - 2014-06-21 21:59:20http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>John Whitlock:</b> Good point on the more natural Python version. I think I just meant that if you wrote the multiple return style in Python, you'd leave out the ugly underscores and redundant <code>None</code> parameter and such. But yes, it's still not entirely natural. And no, Swift does not force you to unpack multiple return items. You'll get the exact same thing in Swift as you do in Python with your example, with the slight improvement that it should be caught at compile time and the error message might (might) help you realize what's gone wrong. <br /> <br /><b>Preston:</b> I don't doubt we'll see plenty of abuse in random third party libraries, but I'm hoping it won't become common in the popular ones, and that it will generally be understood as something to avoid. Think of macro abuse and such in Objective-C now: people do it, sometimes because it's needed, sometimes for no good reason, but it's generally understood as something to avoid if you can.1b8d6db230a69371c35ec97b800f3990Sat, 21 Jun 2014 21:59:20 GMTPreston - 2014-06-21 18:28:30http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsOperator overloading will be convenient for some of my model objects. However, I'm not looking forward to homegrown regex literals and other stuff we'll see all over Github.3fe2963d654832f0e14f7aee95ac829cSat, 21 Jun 2014 18:28:30 GMTJohn Whitlock - 2014-06-21 17:41:11http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsMike, great article as usual. <br /> <br />You mentioned the Python with PyObjC code for multiple returns looks like: <br /><code> <br />&nbsp;&nbsp;&nbsp;&nbsp;data, error = NSData.dataWithContentsOfFile_options_error_(file, 0, None) <br />&nbsp;&nbsp;&nbsp;&nbsp;if not data: <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# handle error <br /></code> <br />with the native Python version looking like: <br /><code> <br />&nbsp;&nbsp;&nbsp;&nbsp;data, error = Data.dataWithContentsOfFile(file, 0) <br /></code> <br />I'd expect the Python version to be: <br /><code> <br />&nbsp;&nbsp;try: <br />&nbsp;&nbsp;&nbsp;&nbsp;data = Data.dataWithContentsOfFile(file, 0) <br />&nbsp;&nbsp;except IOError as error: <br />&nbsp;&nbsp;&nbsp;&nbsp;# Handle the error <br /></code> <br />Python took the C++/Java path of class-based exceptions, and Objective-C took the C path of error codes and string errors. It looks like that will be continued with Swift, unless the libraries start diverging. <br /> <br />A more Pythonic example of multi-return is the Django ORM function to get an existing item or create a new one: <br /><code> <br />&nbsp;&nbsp;&nbsp;obj, was_created = Blog.objects.get_or_create(title='Arguing about Error Handling') <br /></code> <br />This can trip up developers, who first write it as: <br /><code> <br />&nbsp;&nbsp;&nbsp;obj = Blog.objects.get_or_create(title='Arguing about Error Handling') <br />&nbsp;&nbsp;&nbsp;# obj is now a tuple (Blog object, boolean) <br /></code> <br />Does the Swift compiler force you to unpack multiple return items? <br />48542b9d5aacff0065bc854c621f1ae6Sat, 21 Jun 2014 17:41:11 GMTJason - 2014-06-21 17:14:34http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsAll these features allow the language to be pretty lightweight and rely on libraries to do the heavy lifting, which affords a lot of flexibility and utility (for better or worse).. On one end of that spectrum, trailing closures allow for new control flow "keywords" like Perl's <code>unless</code>: <br /> <br /><code>func unless&lt;T: LogicValue&gt;(test: T, clause: () -&gt; ()) { <br />&nbsp;&nbsp;&nbsp;&nbsp;if (!test) { clause() } <br />} <br /> <br />unless (false) { <br />&nbsp;&nbsp;&nbsp;&nbsp;println("success!") <br />}</code> <br />130bcab50d3c8e7f2e9bef8798de6a2cSat, 21 Jun 2014 17:14:34 GMTRainer Brockerhoff - 2014-06-21 16:31:09http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsApparently you can implement <i>synchronized</i> as above like this: <br />func synchronized(object: AnyObject, closure: () -&gt; ()) { <br />&nbsp;&nbsp;&nbsp;&nbsp;objc_sync_enter(object) <br />&nbsp;&nbsp;&nbsp;&nbsp;closure() <br />&nbsp;&nbsp;&nbsp;&nbsp;objc_sync_exit(object) <br />} <br /> <br />Looking forward to posts about the Swift implementation details, Mike! Thanks.72b61efe9a44c09ca2f74ee40bce4fe9Sat, 21 Jun 2014 16:31:09 GMTmikeash - 2014-06-21 15:30:33http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>bavarious:</b> Awesome, I didn't realize <code>autoreleasepool</code> was already in there. I was thinking I'd have to build it. <br /> <br /><b>Jake Smith:</b> Interesting! In C++, the two complaints (at least for me) are that the operators already had a long history doing something unrelated, and they have the wrong precedence for IO, meaning that code like <code>cout &lt;&lt; x &amp; y</code> needs unfortunate parentheses. Perhaps that's not the case in Ruby? Or, again, a different language culture.77625e9085ebcbf0c7994cb5f5a511c1Sat, 21 Jun 2014 15:30:33 GMTmacshome - 2014-06-21 15:28:47http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsThanks for the most sensible explanation of Swift I've found so far. As an Obj-C guy a lot of stuff was pretty baffling to me, but now things like the optionals and generics make more sense. I've been working my way through the Swift book and some simple test projects and this post really helps. <br /> <br />I do have one nitpick though. (This is the internet after all.) Your example of how a lack of generics can break dot syntax in Obj-C doesn't really work as <code>- uppercaseString</code> is a instance method on NSString and not a synthesized property or accessor method. c2c737d89d958ed1d47a928a0e199a75Sat, 21 Jun 2014 15:28:47 GMTJake Smith - 2014-06-21 14:01:09http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsComing from Ruby, the bit shift operator is used extensively for adding something to the end of something, and is often referred to as the shovel operator. I had no idea this was considered pathological, I wonder if Rubyists who use Swift will accidentally introduce it as a pattern/anti-pattern.f3aefbb56344ae42b3559bb93f3a4af6Sat, 21 Jun 2014 14:01:09 GMTbavarious - 2014-06-21 05:35:32http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsA nice example of function with trailing closure as statement is autoreleasepool(code: () -&gt; ()), which is Swift’s ObjectiveC module equivalent to Objective-C’s @autoreleasepool: <br /> <br /><code>autoreleasepool { <br />&nbsp;&nbsp;&nbsp;&nbsp;// code <br />}</code>a4bb688112c1dfa4ccdc5d385da30c11Sat, 21 Jun 2014 05:35:32 GMTmikeash - 2014-06-21 02:54:30http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsAren't &lt;&lt; and &gt;&gt; still used all over the place for IO in C++? That's enough for "pervasive" and "common" for me.192dff74d89e8763a71d7551500a95daSat, 21 Jun 2014 02:54:30 GMTCogwheel - 2014-06-21 01:50:36http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsI guess it depends on what you mean by "it remains pervasive" or "so common in C++". I know C++ is a slow-moving behemoth, but things do change over time. <br /> <br />The "OVERLOAD ALL THE THINGS!!" attitude programmers had early on in C++ no longer remains pervasive. Bad uses of operator overloading are only "so common in C++" in the sense that the C++ language and old (but still heavily used) libraries enshrined them long ago. It's not newly overloaded operators that are the problem, it's the fact that people still use old code (again, back to the backwards compatibility issue). <br /> <br />I really don't think it's fair to assert that the C++ community is still somehow in conflict over this. Yes, there are people who are scarred for life, but life has moved on since then. <br /> <br />Sorry for obsessing on this, but it really bothers me to see questionable generalizations trotted out as self-evident truths. I'll leave it alone now :)595321fca7ac0191a16510f05fd4c36cSat, 21 Jun 2014 01:50:36 GMTmikeash - 2014-06-21 00:15:20http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>Cowheel:</b> Regardless of who thinks it's a good idea anymore, as far as I know it remains pervasive. As for not having to do with C++, that's exactly my point: it's not the ability that's bad, it's how you use it (or don't). C++ got off on the wrong foot in a serious way and has never really recovered. <br /> <br /><b>Peter:</b> I'm not sure I understand what you're after, exactly. Can't you enforce immutability by simply using <code>let</code> with all your ivars (or whatever we're calling them in Swift)? Or are you talking about being able to use the same class for as both mutable and immutable?bd4fb5710392ef8c87a5fa875948a00fSat, 21 Jun 2014 00:15:20 GMTPeter - 2014-06-20 22:01:58http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsThe only thing that bums me out is that, as opposed to structs, classes don't have support for enforcing immutability. I would have loved to see C++'s const-correctness. <br /> <br />If we had that, Swift could also almost be described as C++ without the C. 058e85ac2bfa365a7c98f9e880890bb1Fri, 20 Jun 2014 22:01:58 GMTEric Allam - 2014-06-20 20:51:02http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsAlong with austinz, I would love to hear your thoughts more on pattern matching in Swift.bb3fa05615fb550fe07ac1faa18382b3Fri, 20 Jun 2014 20:51:02 GMTCowheel - 2014-06-20 20:34:41http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsGreat article, but the intro to Operator Overloading kinda rubs me the wrong way. The problems you described have been known for decades, and I don't think anyone learning C++ in the last 10 years is making those same kinds of mistakes. I'm pretty sure Bjarne doesn't even think operator &lt;&lt; for streams is a good idea anymore, but it's what we're stuck with (so many things could be better about C++ if they weren't so married to backwards-compatibility). <br /> <br />Even so, those particular choices had nothing to do with it being C++ and everything to do with the experience (or lack thereof) of the people making those choices. All of those same mistakes could still be made in Swift. <br /> <br />That said, I absolutely love the fact that you can actually create new operator tokens in Swift. <br /> <br />Here's my attempt to do something similar in C++ (yay macro abuse!) <a href="https://github.com/cogwheel/IdOp">https://github.com/cogwheel/IdOp</a>7dd70c926e26b78f50b65677e208005bFri, 20 Jun 2014 20:34:41 GMTDavid Hart - 2014-06-20 19:58:33http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">(I think a good case could be made that an even better way to handle error returns would be with an either type. In any case, I look forward to exploring the options.)</div></div> <br />Why not go one step further and mention enum's ability to act as Either: <br /> <br /><code>enum Result { <br />&nbsp;&nbsp;&nbsp;&nbsp;case Success <br />&nbsp;&nbsp;&nbsp;&nbsp;case Error(NSError) <br />}</code>a63619e0a4608059d6ab05e49b19aa1dFri, 20 Jun 2014 19:58:33 GMTaustinz - 2014-06-20 18:28:54http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsThis is a great article. Would love to see your thoughts on enumerations and pattern matching in Swift.c6b6cb3857288034678082ffbab9cf3bFri, 20 Jun 2014 18:28:54 GMTmikeash - 2014-06-20 17:29:30http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsNote to commenters: arguments about how stupid the Apple community is for rejecting other languages and then embracing Swift do not belong here, and any such comments will be deleted. Take it to Twitter or your own blog or wherever you guys talk about such fluff.023fdd07ddfed8be476f4950c0c6624aFri, 20 Jun 2014 17:29:30 GMTmikeash - 2014-06-20 15:05:16http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#comments<b>blubby:</b> A "tirade"? There are <i>two sentences</i>. Defensive much?395a183bf693b8a22e3a97b48a02ceacFri, 20 Jun 2014 15:05:16 GMTblubby - 2014-06-20 15:02:22http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsI was just thinking that these features (or at least the major, non syntactic-sugary ones) are already available in C++11, including to Objective-C developers. <br /> <br />But, I think it's the Obj-C dev culture that one is supposed to despise C++ and like Obj-C even if as a language it was obsolete 10 years ago, nevermind in 2014. <br /> <br />This shows in the operating overloading section, where a minor point (iostreams using &gt;&gt; and &lt;&lt;) is turned into a tirade against operator overloading in C++ while ignoring the majority of the cases where it is actually used for "traditional purposes". <br /> <br />Still, it's nice that Apple platforms have access to a blessed modern language. It would have been even nicer for them to recommend a standardised, cross-platform language, but as mentioned before, the cognitive dissonance might have been too great for the developer community, and one transition à la PowerPC to Intel is enough for a lifetime.df1604e15f2e35fa4b1a8242a35b5baeFri, 20 Jun 2014 15:02:22 GMTDavidH - 2014-06-20 14:39:38http://www.mikeash.com/?page=pyblog/friday-qa-2014-06-20-interesting-swift-features.html#commentsIt turns out that contrary to what the Swift manual says, you can use some Unicode symbols for operator overloads. There is a thread on this in the Swift forums.7f1fbf5858a09c4ee014176bca58f362Fri, 20 Jun 2014 14:39:38 GMT