[swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

Tino Heth 2th at gmx.de
Tue Jan 31 04:10:12 CST 2017


> It seams like there is discussion to be had, comparing these models:
> 
> 	[A] functions have simple names, and arguments have labeled tuple type model
> 	[B] model where we strictly require the labels for referring to n-ary functions (e.g. "insert(cell:, into:)" instead of "insert")
> 
> I like [B] because it does solve cases of ambiguity, where only using the base-name of the func causes the "Variable used within its own initial valueā€¯ described by Michael.
> 
> What are some advantages of [A]? I assume that tuple splatting (i.e. passing a tuple of args when calling a n-ary function) is one of them, or is that not related?


Imho B has drawbacks which count as advantages for A:

- More typing (obvious, although not that terrible)

- Can easily be confused with an actual function call (imho "(" is tightly coupled with the idea of "ah, that's a function that is called"):

func f(_ arg: Int) -> Int {
	print(arg)
	return 0
}

func f(arg: Int) -> Int {
	print("Not", arg)
	return arg
}

let arg = 1

let outFunc = f(arg:)
let outInt = f(arg)

- May look odd (especially if you are used to functions in math)

func g(_ a: Int, _ b: Int) -> Int {
	return a + b
}

let looksLikePearl = g(:, :) // "Expected expression in list of expressions" - compiler doesn't like it either ;-)

> Am 31.01.2017 um 01:59 schrieb Joe Groff via swift-evolution <swift-evolution at swift.org>:
> 
> The ability to reference a function by only the first segment of its name is likewise legacy of the original model, though it happens to be useful since good naming hygiene encourages different base names for different things to begin with.

+1, hope the short syntax stays the preferred choice when there is no ambiguity.

- Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170131/6d8dc7df/attachment.html>


More information about the swift-evolution mailing list