Reasoning behind swift's function notation?

Question

Why does Swift use this function notation:

func greet(person: String, day: String) -> String {
    return "Hello \(person), today is \(day)."
}

I don't get why it uses the small arrow -> notation to specify return type. func identifier() -> Type instead of something more sensible, like Type identifier().

I have seen similar notation in Haskell, but in Haskell it makes sense to me because Haskell uses curried functions, so the arrow represents function currying. In swift it just seems verbose and superfluous.

What was the reasoning behind this design choice?

Please answer this objectively. This is not opinion based because I am not asking for opinions, I just want to know the reasoning behind the design choice.

What reasons motivate you to think `Type identifier()` is "most sensible", other than "a 40 year old language did it so" — Alexander, Dec 15 '16 at 00:58
@AlexanderMomchliov I don't think it is "most sensible," idk why you are using quotation marks. I feel that swift seems to be using something overly verbose for no reason I can tell. Why change what programmers are used to? There must be a reason, and this is why I am asking this question. — theonlygusti, Dec 15 '16 at 01:05
Because it's "most sensible" is a subjective matter that's very hard to find consensus on. For one, I started my programming adventures with python, where there are no type names at all. Am I to think that all static languages (C, C++, Java, C#, Swift, the full lot...) are "overly verbose" for "no reason I can tell"? — Alexander, Dec 15 '16 at 01:07
also, Swift is by far the most concise static language of any of the ones I can think of, so I'm not sure what makes you think it's verbose. — Alexander, Dec 15 '16 at 01:09
@AlexanderMomchliov I agree swift is generally concise (I find it somewhat beautiful in most cases...) I just don't understand the possible motivation behind this particular design choice. And no one said anything about the C-way being the "most sensible" — theonlygusti, Dec 15 '16 at 01:12
My bad, "more sensible". Moot point, that's doesn't change the anything. — Alexander, Dec 15 '16 at 01:25
Allow me to restate my question. What reasons motivate you to think Type identifier() is "more sensible", other than "a 40 year old language did it so". Happy? — Alexander, Dec 15 '16 at 01:26
I'm also curious, what would you suggest? And how would you suggest `let x: () -> Int` be written, so as to distinguish it (a variable that stores a closure with no parameters that yields an `Int`), from `let y: Int` (just an `Int`). — Alexander, Dec 15 '16 at 01:29
@AlexanderMomchliov `let x(): Int`. But I admit, that would look way too much like Pascal, which is even older than C. — Joker_vD, Dec 15 '16 at 14:05
So now part of your type annotation is in its spot, and part of it part of the variable name... That's "sensible" to you? — Alexander, Dec 15 '16 at 15:01

Alexander · Answer 1 · 2016-12-15T01:11:42.493

This question is 99% likely to be closed for being opinion based, but I'll try to give an objective stab as to what might have motivated this choice.

Most C like languages have that format, of Type identifier(params). Undeniably, this is draws from C's original design. C++, Java, C#, all follow this style.

This style has significant issues for non-trivial types, as it makes it hard to pick out the method name without first reading through the type and parsing it, mentally. Consider this pretty typical Java method:

...
public static final Map<String, Array<MyGenericType<Foo, Bar>>> myMethodName(Type param) { ... }
...

The method name, myMethodName, is halfway across the screen (assuming you follow a generous 120 character ruled code standard, and not an 80 char one). It's really quite silly.

Style guides have picked up on this, and for many C languages, it's advised to put the name on a new line, with all type information, access specifiers, etc, on the previous line. This is especially prevalent in C++.

Consider this real example from the Boost library in C++.

template <class A1, class A2, class A3, class A4, class A5, class A6>
inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&)
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

Many would suggest it be written like this:

template <class A1, class A2, class A3, class A4, class A5, class A6>
inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type 
auto make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&)
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

but in any case, the C++ teamed realized this madness, and would now allow this to be written as:

template <class A1, class A2, class A3, class A4, class A5, class A6> 
make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&) -> inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

C++11 supports `auto function() -> type {}` syntax as well as the classic `type function() {}` syntax. — Ferruccio, Dec 15 '16 at 00:58
I don't get why it would be closed as opinion-based, there is a definite answer. I don't want to know what _might_ have motivated the choice, I want to know "What was the reasoning behind this design choice?" — theonlygusti, Dec 15 '16 at 00:58
@Ferruccio WOAH, that's really cool! I knew about `auto`, but I've never seen it in this context. That's really neat! Man, the more I use `C++11`, the more it feels like a whole new language — Alexander, Dec 15 '16 at 01:01
@theonlygusti You'll have a better chance of getting an answer by asking the swift team. I doubt such a decision was publicly documented, as it would have been made in Swift's early stages, before it was open sourced — Alexander, Dec 15 '16 at 01:01
@theonlygusti See my edit, and this http://softwareengineering.stackexchange.com/q/200828/109689 — Alexander, Dec 15 '16 at 01:08

Reasoning behind swift's function notation?

1 Answers1