What is parentheses around a function name for?

Using Swift
21

Sure, if you're asking if putting parentheses around single value expressions is useful in general, I think the answer is not. Putting parentheses around a bare function name, or a single number literal, or any other value, is usually moot.

If you ask if we should therefore disallow them, I'm not so sure. You have certainly found a few quirks, and possibly bugs, in how the type system handles implicit conversion between functions, values of function type, closures and their labels, but I consider that minor bugs.

Have you been bitten by these in practice, or is this more of an theoretical question of language consistency?

22

The biting came in the form of lost hours from trying to understand the undocumented behavior.

enum Outer {
  static func f(outer: Void) { }

  enum Inner {
    static func f(inner: Void) { }

    static func bar() {
      // These 4 compile:
      f(inner: ())
      (f)(inner: ())
      f(inner:)(())
      f(outer:)(())

      // These 4 do not:
      f(outer: ()) // Incorrect argument label in call (have 'outer:', expected 'inner:')
      (f)(outer:)(()) // 3 errors. Main one is Cannot call value of non-function type '()'
      (f)(inner:)(()) // Same 3 errors as above.
      (f)(()) // Missing argument label 'inner:' in call
    }
  }
}

I'd never seen anyone use parentheses around a function, before labeled arguments, so I didn't know WTF I was looking at for half of those. I still don't get the scoping/visibility, but that's a different topic.

23

So what prompted you to do so?

I guess it is interesting to try to understand, but it doesn't seem like you stumbled upon a bug while trying to solve a real-world programming problem, and were bitten by bugs and uncompilable code?

But rather that you were curious, and interested in trying to figure out the underlying rules, and that the "hours lost" where more of an exploration, non?

Regardless, I think you've found some real bugs, but I'm not sure they are more than minor quirks in the theoretical. ¯\_(ツ)_/¯

24

Please never say anything like this to a human being again, or think the relevant thought. This thinking is endemic in the programming community, and hasn't done us any favors.

25

I'm sorry if I offended you! Sorry. I didn't intend to state anything about you, but merely to ask you a question. In sincerity. "No", is a valid answer to my question.

Also, for the record: I do not consider it useless to understand and explore the nuances of stuff, and am sorry if I came off otherwise. But I do think there is a practical difference between stumbling upon things while exploring stuff and getting lost in the wild :slight_smile:

4 Likes