Require parameter names when referencing to functions

wadetregaskis · 2019-07-24T05:26:40.473Z

beccadax:

init(_ c: Character)
init(_ cocoaString: NSString)
init(_ content: Substring.UnicodeScalarView)
init(_ scalar: Unicode.Scalar)
init(_ substring: __shared Substring)
init(_ unicodeScalars: String.UnicodeScalarView)
init(_ utf16: String.UTF16View)
init(_ utf8: String.UTF8View)
init?(_ codeUnits: Substring.UTF16View)
init?(_ codeUnits: Substring.UTF8View)
This is a list I'm quite comfortable with. Every overload here straightforwardly converts something that's already very string-like to a string. None of these overloads are implementation details or security risks.

The question is: does this hold true in ~all such cases? It seems like this is relying on an assumption / assumed rule that any 'dangerous' 'overloads' deliberately use a distinct [full] name. Which seems like a good idea irrespective of this thread, since otherwise actual invocations of the method could likewise unwittingly using the dangerous version by accident, but have method authors actually been that careful to date?

soroush · 2019-07-24T17:47:16.339Z

It seems to me like we have five options proposed here:

Status quo
Require parens and parameter names for every non-nullary function reference
Require parens and parameter names only when required to disambiguate between a property and a function, or multiple functions with the same base but different parameters
Require parens and parameter names if there is a single parameter labeled with words but not when they have only underscores (so max would be exempt but contains(where:) wouldn't be)
Syntax for providing an alternate name, available only for references but not callers

It seems like both 4 and 5 are workable, with 5 being a little more challenging to implement?

Ponyboy47 · 2019-07-24T18:47:06.627Z

soroush:

Require parens and parameter names only when required to disambiguate between a property and a function, or multiple functions with the same base but different parameters

Isn't this just the status quo?

soroush · 2019-07-24T19:17:01.121Z

Ponyboy47:

Isn't this just the status quo?

Not quite. In the world of option 3, if you tried to use let func: ((Thing) -> Bool) -> Int = myArray.count, that would be a warning or an error (because it's an ambiguous reference), which is different than the current world.

Jordan brings up a few problems with it though:

jrose:

I'm against the "disambiguate as needed" approach because it makes it harder for library authors to change their code. If a method has a sensible base name, and you want to add functionality that would share the same base name but uses different argument labels, you shouldn't have to worry about whether someone might be referring to the method with just the base name.

salutis · 2019-07-25T08:25:43.041Z

I thought about this problem some more and came up with the following rule that I think would greatly improve readability of functional code in Swift:

When referencing a function, all of its external parameter labels must be listed.

With this rule in place, functions like + or max can be used ergonomically as they do not expose any external parameter labels. All the other functions that expose external parameter labels expose them for a good reason and so they should always be listed at the point of use.

AliSoftware · 2019-11-19T17:44:29.084Z

Waking up that thread because I'd love to see progress on this.

Got hit by that problem today while trying to reference a #selector:

class MyViewController: UIViewController {
  ...
  @objc func validate() { ... }
  override func viewDidLoad() {
    super.viewDidLoad()
    let doneBtn = UIBarButtonItem(barButtonSystemItem: .done, target: self, action: #selector(validate) // error
    self.navigationItem.rightBarButtonItem = doneBtn
  }
}

That code errors, telling me that #selector(validate) is ambiguous because it could match either MyViewController.validate() or UIResponder.validate(_:)

Making the change suggested in this thread that all functions with parameters should reference their parameters explicitly would solve this. If we make an exception about "only external parameter labels must be listed" like suggested by @salutis in the message above, that would mean that because UIResponder.validate(_:) doesn't have an external label for its parameter, the ambiguity would remain though…

I'd love if we could find a solution so that all parameters have to be explicit when referencing a function. Maybe the only exception we could accept is for operators (like +) but not for anything else (I'm fine with having to reference max(_:_:) instead of max for example)

Ilias_Karim · 2019-11-20T21:41:50.177Z

How about specifying parameter names as well as their types? That seems to be the only resolution to the ambiguity brought up by @wadetregaskis in response to @beccadax.

mattrips · 2019-11-21T01:38:13.127Z

I very much like this proposal.

However, wouldn't this syntax change be source breaking?

Wildchild9 · 2019-12-18T06:41:04.769Z

This is clearly a big hole in Swift as it hinders Swift's expressivity and introduces tons of ambiguities in its current state. Though this is a breaking change, I only foresee it causing more problems in the future, so I hope this gets changed sooner rather than later.

toph42 · 2020-09-09T23:23:13.926Z

@soroush Did this ever get a proposal?

soroush · 2020-09-10T03:12:51.382Z

Sadly, no. I feel like we didn't really make any decisions about which direction the proposal should go in, and it kind of fell off my radar. Happy to work on a proposal if we have a direction in mind!

austintatious · 2020-09-10T14:30:04.994Z

I think it's definitely time this is resurrected and implemented. One should be required, as suggested, to use the full name of a function (e.g with its labels) when referring to a function -- with no chance of it being returned to its current state.

toph42 · 2020-09-10T15:27:27.034Z

All of them, or just external argument labels (so, excluding _ names)?

Nobody1707 · 2020-09-10T16:05:15.125Z

I think everyone had agreed on foo(_:bar:). The only disagreement was on when, if ever, foo would be allowed.

austintatious · 2020-09-10T16:08:57.294Z

foo on its own should never be allowed unless there are NO parameters.

func foo() must be referred to as foo
func foo(bar: Int) must be referred to as foo(bar:)
func foo(_ bar: Int) must be referred to as foo(_:)

soroush · 2020-09-10T17:20:58.207Z

I think the best thing to do is vote for one of the 5 options above. @austintatious, it sounds like you’re a hard 2?

toph42 · 2020-09-10T18:03:52.415Z

Is there no exceptions for operators and functions without external parameter names? There was much derision (including from myself) for forcing ugly map calls.

dhoepfl · 2020-09-23T10:44:08.495Z

Two (three) cents from me:

Functions without arguments could be written with a Void argument (just like Void is used for return values):

foo(Void)

If you leave out the comma, wouldn’t it be okay to leave out _, too?

let x = array.reduce(0, max(::))

Shouldn’t the return type be part of the syntax?

func foo(_ x: Int) -> String { "\(x)" }
func foo(_ x: Int) -> Int { x*2 }

let a : [Int] = [ 1, 2, 3 ].map(foo(:))   // Should have to be: .map(foo(:)->Int)

CTMacUser · 2020-09-24T19:48:22.482Z

dhoepfl:

Functions without arguments could be written with a Void argument (just like Void is used for return values):
foo(Void)

Swift isn't C. The "myFunc(void)" syntax from C(++) is a legacy irregularity. It was required because "myFunc()" was (kind of) the same as "myFunc(...)" in ancient C! And void isn't an actual type that can be used for objects.

But in Swift, Void is a full type with instances, and said instances can be passed around. So a function that can take a single argument of type Void is a legitimate signature. Since we have regularity, we represent zero arguments by actually having zero arguments.

xAlien95 · 2020-10-05T22:57:40.528Z

soroush:

It seems to me like we have five options proposed here:

Status quo

Require parens and parameter names for every non-nullary function reference

Require parens and parameter names only when required to disambiguate between a property and a function, or multiple functions with the same base but different parameters

Require parens and parameter names if there is a single parameter labeled with words but not when they have only underscores (so max would be exempt but contains(where:) wouldn't be)

Syntax for providing an alternate name, available only for references but not callers

It seems like both 4 and 5 are workable, with 5 being a little more challenging to implement?

I'm probably alone here, but I would prefer to keep the status quo.
Currently, when no additional information is given at the reference site, if you have both a variable and a function sharing the same name, the first one gets chosen.

1: let f = 2
2: func f(_ x: Double) {}
3: func f(_ x: String) {}
4: func f<T: Decodable>(_ x: T) {}
5: func f<T: Encodable>(_ x: T) {}
6: 
7: let g = f  // g: Int = 2

Also, as others already mentioned, you cannot always disambiguate by means of the parameters labels only. To correctly disambiguate the two f functions at lines 2 and 3, you need to explicitly annotate f's type signature (and I don't know if the fs at lines 4 and 5 can be referenced at all since the type signature is generic).

What I suggest is to add an heuristic to first type check assuming that the ambiguous reference is a variable and to proceed with functions only if it fails. I know it's an heuristic, but from the example above it looks like it's already been used, so it's the currently expected behavior.

If Sequence.count has worked with no issues until now, it should still work as expected after adding Sequence.count(where:). In order to reference the latter, you need to either use

let l = [0, 1, 2].count(where:)
let l = [0, 1, 2].count as ((Int) throws -> Bool) throws -> Int