Function types syntax

[Mark Mahieu]

On 27 Jan 2010, at 07:41, John Rose wrote:
> 
> On the subject of readability:  The C declarator-like syntax for function types is nobody's favorite (I claim).  The analogy between T(A) and T method(A) { is widely cited, but is also (I claim) widely experienced as a strained analogy.  The reason for this is the usual focus of attention and anchor for informal parsing—the method name—is missing in the former syntax.  In C++0x, the C-style function type syntax is being improved (but not replaced) by a more standard postfix arrow syntax: (A)->R.
> 
> Here's a variation of Neal's suggestion using a postfix placement for return types, which is much more standard in languages (e.g., Haskell) that rely heavily on function types:
> 
> #(String)->int stringLength;
> 
> stringLength = #(String s) int length: {
>  if (s == null) break length = -1;
>  length = s.length();
>  };
> 
> Remember that postfix type syntax (with right associativity) reads very well when writing higher-order functions:  (int)->(String)->boolean is clearly something that takes an int, then takes a String later on and produces a boolean.  Compare the stuff people are complaining about, which is the fault of C-declarator-style syntax:  ##boolean(String)(int).  Who's going to read that one correctly!?
> 
> Best wishes,
> -- John



I like the postfix style too, but I guess I can understand how the C-declarator-style makes sense from a certain perspective.

I know Neal warns against designing language features based on specific use cases, but it is interesting to note the connection between a particular perspective (or emphasised category of use cases) and choice of syntax, transparency or not, conversion to interfaces/abstract classes etc.

Twisting one of Joe Darcy's favourite parables slightly, I sometimes wonder whether identifying our 'elephant' is so difficult because we really have a pair of them on our hands.

Mark