Earlier quoted context omitted.
You only have to be a paid developer to get the beta of XCode; once it comes out of beta, it'll be available on the Mac App Store for free. That said, it'd be nice to see Swift get open sourced at some point.
I'm afraid that it's going to be tied too tightly to the Cocoa Runtime to make opening the language up feasible without also opening Cocoa up.
Swift – observations from Rust’s original designer
81–88 of 88 posts
Re: Swift – observations from Rust’s original designer
#82"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…
Re: Swift – observations from Rust’s original designer
#83- Chris Lattner, http://nondot.org/sabre/
Re: Swift – observations from Rust’s original designer
#84Aren't the interfaces-as-generics constraints also from c#? It seems to be c# more than anything else.
One of the Swift developers is a former F# dev: https://twitter.com/jopamer The language seems more closer to F# than C# to me. It's all good though!
Re: Swift – observations from Rust’s original designer
#85"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…
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.
interface ISample { void Process(); }
ISample sample = new ConcreteSample(); // Duty #1
class GenericSampleProcessor : where T : ISample // Duty #2
{ public void Process(T sample) { sample.Process(); } }
Re: Swift – observations from Rust’s original designer
#86Earlier quoted context omitted.
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.
// protocol = interface interface ISample { void Process(); } ISample sample = new ConcreteSample(); // Duty #1 class GenericSampleProcessor : where T : ISample // Duty #2 { public void Process(T sample) { sample.Process(); } }
It's the same in Java:
ISample sample = new ConcreteSample(); // Duty #1
class GenericSampleProcessor // Duty #2
Java got generics in 1.5, released September 2004, and bounded types like this were in that release. C# got generics in 2.0, released in November 2005, and i imagine it had them too. I assume Java lifted this idea from elsewhere. I am really quite surprised that Mr Hoare thinks this is a novel discovery in Rust.Re: Swift – observations from Rust’s original designer
#87Earlier quoted context omitted.
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 na…
> 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/documenta...
Re: Swift – observations from Rust’s original designer
#88Earlier quoted context omitted.
Macro system != C preprocessor.
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 it…