Swift func declaration similar to Go

[Greg Ing]

There's a nice similarity in the function declaration syntax of Apples new language Swift and Go.

Swift:

func aFunctionName(arg: Int, anotherArg: String) -> (Bool, String) {

   println(String(column))

   return true, "true" 

}

Go:

func aFunctionName(arg int, anotherArg string) (bool, string) {

    fmt.Println(string(arg))

    return true, "true"

}

- func not "function"

- Return type at end of declaration

- Argument type after argument name

Cool to see a very similar syntax in a completely different language.

Greg

- Go got style it don't need no while

[Greg Ing]

Yes there's a typo

[Jean de Klerk]

I'll be honest, a lot of what I saw while reading Swift docs was very reminiscent of Go. Good point about signatures though.

Jean

[Rob Pike]

Interesting that Go had an arrow there in the early days (see my
GopherCon keynote) but we dropped it because it's not necessary.
Neither are the colons.

-rob

[Carl Menezes]

Exactly what I like about Go. If there isn't a sound reason for something, it doesn't exist.

[Robert]

Yeah, not a fan of the arrow, not sure why it needs to be there.

[Jsor]

Eh, not a huge deal. It's reminiscent of the function/mapping syntax:

f: domain -> codomain

I assume that's why they put it there.

[Adie Nurahmadie]

I think I find myself actually fond of the function as mapping syntax, it looks less ambiguous, also more concise for simple type

f: Int -> Int

vs

f func(int) int

I guess it's just a matter of personal taste/preference

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
regards,
Nurahmadie
--

[luz...@gmail.com]

On Tuesday, June 3, 2014 4:10:39 AM UTC+2, Greg Ing wrote:

- Return type at end of declaration

The 'identifier colon type' notation is just Pascal style. Most new languages with types (Scala, Kotlin, Rust) or type extensions to existing languages (ActionScript, TypeScript, Hack) do this.

[Rob Pike]

Yes, and we simplified it. The colon isn't grammatically necessary.

-rob

[ayng...@gmail.com]

I wish they'd use Go instead of rolling their own... (and yes, I hope to see Go on Android, also for GUI work, soon...)

 /Alexander

[rogerjd]

That was good catch, I like it.

can't leave it like this:

  x:int

so, use

  x: int

so why not just use

  x int

Roger

[Kevin Gillette]

I was trying to find some justification for why they did that, and figured it must be that the absence of a type annotation makes the function generic. But no, their generic functions still do the angle-brackety stuff and explicit `v: T` parameters.

[Andy Balholm]

On Jun 2, 2014, at 10:53 PM, Rob Pike <r...@golang.org> wrote:

> The colon isn't grammatically necessary.

In Swift, the colon is there to make it parallel with the function invocation syntax (which inherits the colon from ObjC and Smalltalk).

[James Wendel]

From my understanding, Swift was created (instead of using another language) as Swift has fairly good interaction with existing Obj-C code.  You can mix and match Obj-C and Swift within the same project without too much of a problem. (guide here).  Since they were so tightly bound by being compatible with Obj-C, it threw out most other languages that already exist.

Plus one of the primary creators of Swift seems to be the guy behind LLVM and Clang, so I'm sure it wanted to reuse the toolchain he has put a lot of work into already.

[Jens Alfke]

On Tuesday, June 3, 2014 4:49:50 AM UTC-7, ayng...@gmail.com wrote:

I wish they'd use Go instead of rolling their own... (and yes, I hope to see Go on Android, also for GUI work, soon...)

No chance of them (or Android) adopting Go when it has its own completely nonstandard ABI that doesn't interoperate with anything else on the platform. You can't even produce libraries with Go; it has to own the entire process. Its stacks are different from anything else so no system debugging/profiling tools work with them, and calling into native code requires stack-munging at the call site which adds significant overhead.

I'm aware that there are good reasons for Go doing what it does, primarily to make goroutine stacks memory-efficient. But it makes Go really difficult to integrate with a platform's high-level APIs. It's best suited for standalone processes that use mostly system calls, things like servers.

--Jens

(As for people thinking Swift's syntax derives from Go; it may to some degree, but I also see at least as much influence from Rust and Haskell and Scala and Pascal and lots of other languages.)

[andrewc...@gmail.com]

This declaration order simplifies parsing a fair bit so its unsurprising you will see it in newer languages.

Also from the swift page:

"Swift is friendly to new programmers. It is the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language."

I think Go has a better claim to that than swift...