Live data from Hacker News

Swift – observations from Rust’s original designer

graydon2.dreamwidth.org

81–88 of 88 posts

Re: Swift – observations from Rust’s original designer

#81
post #66
post #11

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.

C# is "open source", but the CLR is not.

Re: Swift – observations from Rust’s original designer

#82
post #60

"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.

Re: Swift – observations from Rust’s original designer

#83
"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/

Re: Swift – observations from Rust’s original designer

#84
post #61
post #2

Aren'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!

He is also a former typescript developer.

Re: Swift – observations from Rust’s original designer

#85
post #82
post #60

"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.

// 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(); } }

Re: Swift – observations from Rust’s original designer

#86
post #85
post #82

Earlier 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(); } }

Ah, i see, thanks.

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

#87

Earlier 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...

Oh cool, I definitely missed that!

Re: Swift – observations from Rust’s original designer

#88

Earlier 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…

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.
Post reply on HN