13 ms·

Swift – observations from Rust’s original designer

344 points by porada 12y ago

Pxtl 12y ago
Aren't the interfaces-as-generics constraints also from c#? It seems to be c# more than anything else.
- keithwarren 12y ago
  I agree, it seems to be heavily influenced by C#. I am primarily a C# dev and reading through the code and docs I seem to have no mental friction, as opposed to ObjC which seemed to make me bang my head on my desk.
- chrisseaton 12y ago
  I think any attempt to precisely pin down where a particular language feature has come from or where a language draws inspiration from is pretty futile. Many language constructs were invented simultaneously under different names in different languages.
- rayiner 12y ago
  Type parameters constrained by sets of method signatures dates to 1977: http://en.m.wikipedia.org/wiki/CLU_(programming_language) http://en.m.wikipedia.org/wiki/CLU_(programming_language). See also, Theta and some of Todd Millstien's work in the 1990s.
- balakk 12y ago
  One of the Swift developers is a former F# dev: https://twitter.com/jopamer https://twitter.com/jopamer The language seems more closer to F# than C# to me. It's all good though!
  - iends 12y ago
    He is also a former typescript developer.
jmgrosen 12y ago
He seems to generally like it -- similar to Rust in a lot of ways, but a little higher-level, which is appropriate for its intended uses (iOS and OS X apps). He nor I seem to think that it can replace Rust (especially if they don't open it up!), but it definitely seems like a compelling option. EDIT: Does anyone know if it's possible to try it without a paid iOS / OS X dev license? I'd especially like to try the playground, but I'm not willing to dump $100 on it.
- chc 12y ago
  They used to offer free student developer memberships, but I think they stopped that a while back. Now you have to be part of one of the paid programs (or be part of a university that's signed up with Apple). It is pretty disappointing that Apple is walling in Swift like this. I was excited about it to begin with, because it looks like a great language, but apparently as Microsoft moves toward openness, Apple is doing the opposite. Now I'm not really sure what to do with it.
  - jmgrosen 12y ago
    I wouldn't be surprised if Apple ends up open sourcing Swift after it cleans it up, perhaps even making it an LLVM project. I see it similarly to how they handled their own AArch64 backend -- proprietary at first, but mostly for secrecy before it was announced and then merging it with the preexisting backend after it was announced.
    - chc 12y ago
      How much cleaning up do you expect at this point? It's already both announced and released to developers. Obviously it's not 100% finished, but if they intended to open-source it, I wouldn't expect that announcement to come after publicly releasing it.
      - X-Istence 12y ago
        They haven't publicly released it yet. Xcode 6 which includes Swift is currently part of the beta available as part of the Apple Developer Program. That means it is still under NDA as well. Most likely after Xcode 6 is released publicly (i.e. available on the Mac App Store) they will do a code dump back to the LLVM project.
deleted 12y ago
[deleted]
pornel 12y ago
I hope ideas will flow the other way too, and Rust adopts some sugar from Swift. I find `if let concrete = optional` sooo much nicer than `match optional { (concrete) => , _ => {} }`. Rust has solid semantics that covers more than Swift. OTOH Apple has put their UX magic into the language's syntax. Some syntax shortcuts, like `.ShortEnumWhenInContext` are delightful. The two combined will be the perfect language ;)
- viscanti 12y ago
  I REALLY like that syntax for the maybe monad.
- xixixao 12y ago
  Funny how this just falls out of JS (in CS): if concrete = optional call concrete
  - stormbrew 12y ago
    Pretty much every language to date allows this construct. And it's often considered a bad idea in languages where = is assignment because it's so easy to get it confused with == and accidentally assign to the thing you're trying to compare to, which will usually evaluate to truthy. The special things about the way it works in Swift are: - You have to put let in front, thus avoiding the confusion. - If the RHS is optional it unwraps the option for the success branch, but the variable is not available in any other scope, thus ensuring safe use. In JS, C, CS, Ruby, etc. you're not really doing anything useful if you assign a value to another name just for one branch of an if statement. In Swift you are.
  - tveita 12y ago
    That's a bad idea if "optional" is a number, a boolean or a string.
- jmgrosen 12y ago
  To be fair, you can also do `optional.map(|concrete| { ... })`. I'll admit that's not quite as nice as Swift's, though.
pepper_chico 12y ago
Does he knows something of Obj-C? Because a lot what he says coming from elsewhere was already well known in Obj-C, like named parameters, "protocols", etc. Which he barely mentions. I think in the light of Obj-C, the newer C# would be less mentioned.
- chc 12y ago
  Objective-C doesn't really have named parameters. Objective-C has arguments spliced into the selector at each colon. (Of course, Swift inherits the selector->parameter limitation, but it goes to somewhat greater lengths to hide it.)
  - stormbrew 12y ago
    I'm pretty sure that Objective-C's named parameters actually have priority over all other forms, being from the nearly identical form they took in Smalltalk. It's only recently that languages have had the looser form of named parameters where their order doesn't matter and they're mostly just a way to disambiguate default arguments. The Smalltalk form is actually more powerful, since it gives you a kind of multiple dispatch (a.la. C++ argument overloading) that would be quite expensive in a non-statically typed language otherwise.
adamnemecek 12y ago
Lack of expressions and a macro system are really unfortunate.
- platz 12y ago
  Thank god they didn't unleash a macro system on everyone.
  - adamnemecek 12y ago
    Macro system != C preprocessor.
    - ThatGeoGuy 12y ago
      To be honest I would be disappointed if they let loose a macro system that is as incomplete as the C preprocessor. I'll be much happier if in a year or two they add a proper, more well thought out macro system to the language which aids in readability rather than ruins it. Now, we'll likely not get the Lisp macro system in all its glory, but I think the point to take away (despite the short parent comment) is that its almost better not to have a broken macro system than something that is rushed an not properly implemented.
      - JayArby 12y ago
        The C preprocessor is bad enough; it's much better if a separate macro language can be avoided altogether, leaving a single consistent syntax for the language. If there has to be a macro system, I would greatly prefer a simple preprocessor to a more powerful system that would allow even greater convolution of the syntax.
tptacek 12y ago
What are the distinctive features of Rust that Swift has that aren't in some way derived from ObjC? (I'm sure there are some; I just don't know Rust.)
- jmgrosen 12y ago
  To name a few: safety enforced at compile-time without any sort of GC/ARC (probably the biggest), more precise control over the hardware (e.g. more concrete pointers), the lack of a required runtime -- basically it has much better support for low-level features while not sacrificing many high-level features.
  - kibwen 12y ago
    I believe tptacek was asking for the intersection of features between Swift and Rust, not for features that Rust has but Swift doesn't (like compile-time memory safety without GC/ARC).
    - jmgrosen 12y ago
      Oh, you're totally right. Sorry, my parser is buggy! Why couldn't he have just have written "(Swift ∖ ObjC) ∩ Rust"? :)
- yoklov 12y ago
  Nothing unique to rust. The biggest thing I see is that it's an imperative language with functional-style ADT's, tuples, sum types, etc. It also looks fairly similar syntactically (all those let's). Not sure if there are other things it has in common.
  - deleted 12y ago
    [deleted]
- ben0x539 12y ago
  Protocols being used both as type parameter constraints and as types themselves reminded a few people of Rust's traits, but of course Rust didn't come up with those from whole cloth either.
zak_mc_kracken 12y ago
I think the author is seeing a little more than there actually is. There is a lot more overlap between Swift and C#/Java than with Rust. Actually, I see very little Rust in Swift, except for very trivial features that are present in 90% of C-based languages. But hey, any opportunity to pimp your favorite language is fair.
- MoOmer 12y ago
  I don't believe the author is 'pimping' Rust. "C#" appears five times on the page, in snippets like this: It seems to borrow quite extensively C# and .. I don't know how to say this politely or immodestly ... Rust. Which is flattering if true! Of course I'm biased. Also a language pluralist, and since Rust is a major cobbling-together of things we liked in other languages (ML, C++, C#, Lisp, Ruby, etc.) It also seems like he's more generally excited about the prospects of not being limited to a small set of languages to do powerful things. "It's remarkable to me that in the years between, we've seen such a shift in what's considered "normal" new-language tech. F# is shipping on several platforms (whether or not M# ever actually surfaces again); Scala is considered an employable skill; C++11 has lambdas and local type inference at least, if not algebraic types or pattern matching; Rust actually exists now; and now one can rely on similar comforts in the Apple ecosystem. How delightful!"
- scriptproof 12y ago
  It is common when a new language appears to authors to see similarity with their own language. Actually, most of the features of Swift were already implemented in some older language. Extended pattern matching for example exists in Scala.
  - ibotty 12y ago
    ... and in many other languages way before scala.
kibwen 12y ago
To those wondering why Graydon is qualified in the title as just the "original" designer of Rust, it's because (as far as anyone seems to know) years of being a technical lead wore him down (lots of administrative tasks and infrastructural tasks, little coding) and the fact that the position of BDFL was foisted upon him unwillingly, to his chagrin. He abdicated the project last year, though I still keep hoping that we'll entice him back someday!
lnanek2 12y ago
He doesn't seem to know much about iOS or Objective-C due to that comment about parameter names probably being unused. You wouldn't be able to make meaningful method selectors calling into the code from Objective-C without them, since the names of the parameters are part of the method name in Objective-C.
- kennywinker 12y ago
  Method parameter names are used similarly in Swift as in ObjC. For example two methods can have the same name, as long as they have a difference set of parameters. For example: func methodName(paramName: String) and func methodName(paramName: String, otherParam: Int) are different. I'm still playing with this but there are some interesting/weird things in here. What follows is a bunch of random observations of how named params work in Swift / ObjC. For instance: func methodName(name name: String) Can be shortened using a pound symbol, because the variable name within the method, and the parameter name are the same thing: func methodName(#name: String) It also seems that most of the Cocoa APIs follow a convention, when called from Swift, of having an unnamed first parameter, and a named second parameter. e.g. this: -(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath becomes: func tableView(tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell! which means it's called like so: myObject.tableView(tableView, cellForRowAtIndexPath: indexPath) If you name a parameter, you have to use the name. The order of parameters matters, and there doesn't seem to be a way to define optional method parameters (make sense as parameter names are essentially ObjC "selectors").
  - mercutio2 12y ago
    > and there doesn't seem to be a way to define optional method parameters Did you miss the part about default values? If you're calling an Objective-C selector with more than one argument, you are indeed using an external parameter name, but external parameters are explicitly not required if you're writing pure Swift. https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html#//apple_ref/doc/uid/TP40014097-CH10-XID_213 https://developer.apple.com/library/prerelease/ios/documenta...
beyondcompute 12y ago
Yeah, that's all good. But why call people who understand that programming environments should not be opaque (and not violate elementary laws of design by obscuring readings of system's state) "livecoding nerds"? Really, why? :)
- Angostura 12y ago
  Perhaps because he doesn't see 'nerd' as pejorative.
  - beyondcompute 12y ago
    Well, me neither. :) Although it looks a little bit suspicious in the text. But what's the relation between 'not throwing crucial design principles out of the window this time' (by not creating opaque, contrived and state-hiding system because tradition seems to approve it) and 'Live Coding' (where people see process of writing code in real-time as a part of artistic performance)?
CmonDev 12y ago
"Protocols get to play double duty as either concrete types (in which case they denote a reference type you can acquire with as from any supporting type) and as type constraints on type parameters in generic code. This is a delightful convenience Rust stumbled into when designing its trait system and I'm glad to see other languages picking it up. I'm sure it has precedent elsewhere." - C# again. PS: Apple says "Swift is an innovative new programming language"! Just like everything else they do lately!
- 14113 12y ago
  This is what annoyed me most about the whole Swift presentation. Swift is not in any way shape or form innovative, in terms of language features or design. It is however, another language that aims to be as productive as possible, while still being safe, like Java, C#, Rust, Go etc. It'd be far more interesting to compare it to them (especially where they have bindings for iOS e.g. Java, C#) in terms of productivity, code maintainability, readability etc, instead of in terms of language features.
- dbaupp 12y ago
  Haskell has it for its type classes in the form of existentials[1] too: forall a. SomeClass a => a in Haskell is quite similar to &SomeTrait in Rust. [1] http://www.haskell.org/haskellwiki/Existential_type http://www.haskell.org/haskellwiki/Existential_type
- twic 12y ago
  I pretty much only know Java and shell script. Could someone perhaps explain what this "double duty" is? A small example would be really helpful.
  - CmonDev 12y ago
    // protocol = interface interface ISample { void Process(); } ISample sample = new ConcreteSample(); // Duty #1 class GenericSampleProcessor<T> : where T : ISample // Duty #2 { public void Process(T sample) { sample.Process(); } }
knocte 12y ago
Couple of things that are still not clear to me, even when people keep saying that it's similar to C#: - How about Garbage Collection? - Many mentions to "type inference", is it then a statically-typed language? Or is it hybrid?
- krig 12y ago
  - Garbage Collection is handled via reference counting and ARC. No automatic cycle detection, the programmer has to manually track and resolve reference cycles. Same as using ARC in Objective C. - It is a statically typed language. Type inference is the same mechanism as is used in C++11 with the auto keyword. Basically, anywhere the compiler can "guess" the type, you don't have to be explicit about it. Unless you want the variable to have a different type from the inferred type, that is.
pajju 12y ago
There is the official Book coming from Apple: The Swift Programming Language by Apple Inc. Link: https://itunes.apple.com/us/book/the-swift-programming-language/id881256329?mt=11 https://itunes.apple.com/us/book/the-swift-programming-langu... Hope it helps.
Tloewald 12y ago
A lot of the features allegedly inspired by C# actually come directly from Objective-C. It's a decent discussion (I also skimmed the manual front to back after the presentation) but it's sad the writer appears ignorant of how advanced a language Objective-C is/was, especially since it significantly predated C++, let alone Java and C#.
- teh_klev 12y ago
  Sure, but can you explain which features rather than leaving off at the author is "ignorant". Are there features in Objective-C available now that weren't present back in the early days? Perhaps this is what the author means? Has Objective-C drawn inspiration from newer languages such as C# or Java?
- groovy2shoes 12y ago
  According to Wikipedia, both C++ and Objective-C "appeared in" 1983. I otherwise share your sentiment.
oscargrouch 12y ago
"I started work on the Swift Programming Language (wikipedia) in July of 2010. I implemented much of the basic language structure, with only a few people knowing of its existence. A few other (amazing) people started contributing in earnest late in 2011, and it became a major focus for the Apple Developer Tools group in July 2013. The Swift language is the product of tireless effort from a team of language experts, documentation gurus, compiler optimization ninjas, and an incredibly important internal dogfooding group who provided feedback to help refine and battle-test ideas. Of course, it also greatly benefited from the experiences hard-won by many other languages in the field, drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list." - Chris Lattner, http://nondot.org/sabre/ http://nondot.org/sabre/

344 points by porada 12y ago

Pxtl 12y ago

Aren't the interfaces-as-generics constraints also from c#? It seems to be c# more than anything else.

keithwarren 12y ago
I agree, it seems to be heavily influenced by C#. I am primarily a C# dev and reading through the code and docs I seem to have no mental friction, as opposed to ObjC which seemed to make me bang my head on my desk.
chrisseaton 12y ago
I think any attempt to precisely pin down where a particular language feature has come from or where a language draws inspiration from is pretty futile. Many language constructs were invented simultaneously under different names in different languages.
rayiner 12y ago
Type parameters constrained by sets of method signatures dates to 1977: http://en.m.wikipedia.org/wiki/CLU_(programming_language) http://en.m.wikipedia.org/wiki/CLU_(programming_language). See also, Theta and some of Todd Millstien's work in the 1990s.
balakk 12y ago
One of the Swift developers is a former F# dev: https://twitter.com/jopamer https://twitter.com/jopamer The language seems more closer to F# than C# to me. It's all good though!
- iends 12y ago
  He is also a former typescript developer.

jmgrosen 12y ago

He seems to generally like it -- similar to Rust in a lot of ways, but a little higher-level, which is appropriate for its intended uses (iOS and OS X apps). He nor I seem to think that it can replace Rust (especially if they don't open it up!), but it definitely seems like a compelling option. EDIT: Does anyone know if it's possible to try it without a paid iOS / OS X dev license? I'd especially like to try the playground, but I'm not willing to dump $100 on it.

chc 12y ago
They used to offer free student developer memberships, but I think they stopped that a while back. Now you have to be part of one of the paid programs (or be part of a university that's signed up with Apple). It is pretty disappointing that Apple is walling in Swift like this. I was excited about it to begin with, because it looks like a great language, but apparently as Microsoft moves toward openness, Apple is doing the opposite. Now I'm not really sure what to do with it.
- jmgrosen 12y ago
  I wouldn't be surprised if Apple ends up open sourcing Swift after it cleans it up, perhaps even making it an LLVM project. I see it similarly to how they handled their own AArch64 backend -- proprietary at first, but mostly for secrecy before it was announced and then merging it with the preexisting backend after it was announced.
  - chc 12y ago
    How much cleaning up do you expect at this point? It's already both announced and released to developers. Obviously it's not 100% finished, but if they intended to open-source it, I wouldn't expect that announcement to come after publicly releasing it.
    - X-Istence 12y ago
      They haven't publicly released it yet. Xcode 6 which includes Swift is currently part of the beta available as part of the Apple Developer Program. That means it is still under NDA as well. Most likely after Xcode 6 is released publicly (i.e. available on the Mac App Store) they will do a code dump back to the LLVM project.

deleted 12y ago

[deleted]

pornel 12y ago

I hope ideas will flow the other way too, and Rust adopts some sugar from Swift. I find `if let concrete = optional` sooo much nicer than `match optional { (concrete) => , _ => {} }`. Rust has solid semantics that covers more than Swift. OTOH Apple has put their UX magic into the language's syntax. Some syntax shortcuts, like `.ShortEnumWhenInContext` are delightful. The two combined will be the perfect language ;)

viscanti 12y ago
I REALLY like that syntax for the maybe monad.
xixixao 12y ago
Funny how this just falls out of JS (in CS): if concrete = optional call concrete
- stormbrew 12y ago
  Pretty much every language to date allows this construct. And it's often considered a bad idea in languages where = is assignment because it's so easy to get it confused with == and accidentally assign to the thing you're trying to compare to, which will usually evaluate to truthy. The special things about the way it works in Swift are: - You have to put let in front, thus avoiding the confusion. - If the RHS is optional it unwraps the option for the success branch, but the variable is not available in any other scope, thus ensuring safe use. In JS, C, CS, Ruby, etc. you're not really doing anything useful if you assign a value to another name just for one branch of an if statement. In Swift you are.
- tveita 12y ago
  That's a bad idea if "optional" is a number, a boolean or a string.
jmgrosen 12y ago
To be fair, you can also do `optional.map(|concrete| { ... })`. I'll admit that's not quite as nice as Swift's, though.

pepper_chico 12y ago

Does he knows something of Obj-C? Because a lot what he says coming from elsewhere was already well known in Obj-C, like named parameters, "protocols", etc. Which he barely mentions. I think in the light of Obj-C, the newer C# would be less mentioned.

chc 12y ago
Objective-C doesn't really have named parameters. Objective-C has arguments spliced into the selector at each colon. (Of course, Swift inherits the selector->parameter limitation, but it goes to somewhat greater lengths to hide it.)
- stormbrew 12y ago
  I'm pretty sure that Objective-C's named parameters actually have priority over all other forms, being from the nearly identical form they took in Smalltalk. It's only recently that languages have had the looser form of named parameters where their order doesn't matter and they're mostly just a way to disambiguate default arguments. The Smalltalk form is actually more powerful, since it gives you a kind of multiple dispatch (a.la. C++ argument overloading) that would be quite expensive in a non-statically typed language otherwise.

adamnemecek 12y ago

Lack of expressions and a macro system are really unfortunate.

platz 12y ago
Thank god they didn't unleash a macro system on everyone.
- adamnemecek 12y ago
  Macro system != C preprocessor.
  - ThatGeoGuy 12y ago
    To be honest I would be disappointed if they let loose a macro system that is as incomplete as the C preprocessor. I'll be much happier if in a year or two they add a proper, more well thought out macro system to the language which aids in readability rather than ruins it. Now, we'll likely not get the Lisp macro system in all its glory, but I think the point to take away (despite the short parent comment) is that its almost better not to have a broken macro system than something that is rushed an not properly implemented.
    - JayArby 12y ago
      The C preprocessor is bad enough; it's much better if a separate macro language can be avoided altogether, leaving a single consistent syntax for the language. If there has to be a macro system, I would greatly prefer a simple preprocessor to a more powerful system that would allow even greater convolution of the syntax.

tptacek 12y ago

What are the distinctive features of Rust that Swift has that aren't in some way derived from ObjC? (I'm sure there are some; I just don't know Rust.)

jmgrosen 12y ago
To name a few: safety enforced at compile-time without any sort of GC/ARC (probably the biggest), more precise control over the hardware (e.g. more concrete pointers), the lack of a required runtime -- basically it has much better support for low-level features while not sacrificing many high-level features.
- kibwen 12y ago
  I believe tptacek was asking for the intersection of features between Swift and Rust, not for features that Rust has but Swift doesn't (like compile-time memory safety without GC/ARC).
  - jmgrosen 12y ago
    Oh, you're totally right. Sorry, my parser is buggy! Why couldn't he have just have written "(Swift ∖ ObjC) ∩ Rust"? :)
yoklov 12y ago
Nothing unique to rust. The biggest thing I see is that it's an imperative language with functional-style ADT's, tuples, sum types, etc. It also looks fairly similar syntactically (all those let's). Not sure if there are other things it has in common.
- deleted 12y ago
  [deleted]
ben0x539 12y ago
Protocols being used both as type parameter constraints and as types themselves reminded a few people of Rust's traits, but of course Rust didn't come up with those from whole cloth either.

zak_mc_kracken 12y ago

I think the author is seeing a little more than there actually is. There is a lot more overlap between Swift and C#/Java than with Rust. Actually, I see very little Rust in Swift, except for very trivial features that are present in 90% of C-based languages. But hey, any opportunity to pimp your favorite language is fair.

MoOmer 12y ago
I don't believe the author is 'pimping' Rust. "C#" appears five times on the page, in snippets like this: It seems to borrow quite extensively C# and .. I don't know how to say this politely or immodestly ... Rust. Which is flattering if true! Of course I'm biased. Also a language pluralist, and since Rust is a major cobbling-together of things we liked in other languages (ML, C++, C#, Lisp, Ruby, etc.) It also seems like he's more generally excited about the prospects of not being limited to a small set of languages to do powerful things. "It's remarkable to me that in the years between, we've seen such a shift in what's considered "normal" new-language tech. F# is shipping on several platforms (whether or not M# ever actually surfaces again); Scala is considered an employable skill; C++11 has lambdas and local type inference at least, if not algebraic types or pattern matching; Rust actually exists now; and now one can rely on similar comforts in the Apple ecosystem. How delightful!"
scriptproof 12y ago
It is common when a new language appears to authors to see similarity with their own language. Actually, most of the features of Swift were already implemented in some older language. Extended pattern matching for example exists in Scala.
- ibotty 12y ago
  ... and in many other languages way before scala.

kibwen 12y ago

To those wondering why Graydon is qualified in the title as just the "original" designer of Rust, it's because (as far as anyone seems to know) years of being a technical lead wore him down (lots of administrative tasks and infrastructural tasks, little coding) and the fact that the position of BDFL was foisted upon him unwillingly, to his chagrin. He abdicated the project last year, though I still keep hoping that we'll entice him back someday!

lnanek2 12y ago

He doesn't seem to know much about iOS or Objective-C due to that comment about parameter names probably being unused. You wouldn't be able to make meaningful method selectors calling into the code from Objective-C without them, since the names of the parameters are part of the method name in Objective-C.

kennywinker 12y ago
Method parameter names are used similarly in Swift as in ObjC. For example two methods can have the same name, as long as they have a difference set of parameters. For example: func methodName(paramName: String) and func methodName(paramName: String, otherParam: Int) are different. I'm still playing with this but there are some interesting/weird things in here. What follows is a bunch of random observations of how named params work in Swift / ObjC. For instance: func methodName(name name: String) Can be shortened using a pound symbol, because the variable name within the method, and the parameter name are the same thing: func methodName(#name: String) It also seems that most of the Cocoa APIs follow a convention, when called from Swift, of having an unnamed first parameter, and a named second parameter. e.g. this: -(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath becomes: func tableView(tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell! which means it's called like so: myObject.tableView(tableView, cellForRowAtIndexPath: indexPath) If you name a parameter, you have to use the name. The order of parameters matters, and there doesn't seem to be a way to define optional method parameters (make sense as parameter names are essentially ObjC "selectors").
- mercutio2 12y ago
  > and there doesn't seem to be a way to define optional method parameters Did you miss the part about default values? If you're calling an Objective-C selector with more than one argument, you are indeed using an external parameter name, but external parameters are explicitly not required if you're writing pure Swift. https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html#//apple_ref/doc/uid/TP40014097-CH10-XID_213 https://developer.apple.com/library/prerelease/ios/documenta...

beyondcompute 12y ago

Yeah, that's all good. But why call people who understand that programming environments should not be opaque (and not violate elementary laws of design by obscuring readings of system's state) "livecoding nerds"? Really, why? :)

Angostura 12y ago
Perhaps because he doesn't see 'nerd' as pejorative.
- beyondcompute 12y ago
  Well, me neither. :) Although it looks a little bit suspicious in the text. But what's the relation between 'not throwing crucial design principles out of the window this time' (by not creating opaque, contrived and state-hiding system because tradition seems to approve it) and 'Live Coding' (where people see process of writing code in real-time as a part of artistic performance)?

CmonDev 12y ago

"Protocols get to play double duty as either concrete types (in which case they denote a reference type you can acquire with as from any supporting type) and as type constraints on type parameters in generic code. This is a delightful convenience Rust stumbled into when designing its trait system and I'm glad to see other languages picking it up. I'm sure it has precedent elsewhere." - C# again. PS: Apple says "Swift is an innovative new programming language"! Just like everything else they do lately!

14113 12y ago
This is what annoyed me most about the whole Swift presentation. Swift is not in any way shape or form innovative, in terms of language features or design. It is however, another language that aims to be as productive as possible, while still being safe, like Java, C#, Rust, Go etc. It'd be far more interesting to compare it to them (especially where they have bindings for iOS e.g. Java, C#) in terms of productivity, code maintainability, readability etc, instead of in terms of language features.
dbaupp 12y ago
Haskell has it for its type classes in the form of existentials[1] too: forall a. SomeClass a => a in Haskell is quite similar to &SomeTrait in Rust. [1] http://www.haskell.org/haskellwiki/Existential_type http://www.haskell.org/haskellwiki/Existential_type
twic 12y ago
I pretty much only know Java and shell script. Could someone perhaps explain what this "double duty" is? A small example would be really helpful.
- CmonDev 12y ago
  // protocol = interface interface ISample { void Process(); } ISample sample = new ConcreteSample(); // Duty #1 class GenericSampleProcessor<T> : where T : ISample // Duty #2 { public void Process(T sample) { sample.Process(); } }

knocte 12y ago

Couple of things that are still not clear to me, even when people keep saying that it's similar to C#: - How about Garbage Collection? - Many mentions to "type inference", is it then a statically-typed language? Or is it hybrid?

krig 12y ago
- Garbage Collection is handled via reference counting and ARC. No automatic cycle detection, the programmer has to manually track and resolve reference cycles. Same as using ARC in Objective C. - It is a statically typed language. Type inference is the same mechanism as is used in C++11 with the auto keyword. Basically, anywhere the compiler can "guess" the type, you don't have to be explicit about it. Unless you want the variable to have a different type from the inferred type, that is.

pajju 12y ago

There is the official Book coming from Apple: The Swift Programming Language by Apple Inc. Link: https://itunes.apple.com/us/book/the-swift-programming-language/id881256329?mt=11 https://itunes.apple.com/us/book/the-swift-programming-langu... Hope it helps.

Tloewald 12y ago

A lot of the features allegedly inspired by C# actually come directly from Objective-C. It's a decent discussion (I also skimmed the manual front to back after the presentation) but it's sad the writer appears ignorant of how advanced a language Objective-C is/was, especially since it significantly predated C++, let alone Java and C#.

teh_klev 12y ago
Sure, but can you explain which features rather than leaving off at the author is "ignorant". Are there features in Objective-C available now that weren't present back in the early days? Perhaps this is what the author means? Has Objective-C drawn inspiration from newer languages such as C# or Java?
groovy2shoes 12y ago
According to Wikipedia, both C++ and Objective-C "appeared in" 1983. I otherwise share your sentiment.

oscargrouch 12y ago

"I started work on the Swift Programming Language (wikipedia) in July of 2010. I implemented much of the basic language structure, with only a few people knowing of its existence. A few other (amazing) people started contributing in earnest late in 2011, and it became a major focus for the Apple Developer Tools group in July 2013. The Swift language is the product of tireless effort from a team of language experts, documentation gurus, compiler optimization ninjas, and an incredibly important internal dogfooding group who provided feedback to help refine and battle-test ideas. Of course, it also greatly benefited from the experiences hard-won by many other languages in the field, drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list." - Chris Lattner, http://nondot.org/sabre/ http://nondot.org/sabre/