I don't think anyone ever said the transformation for syntax sugar has to be trivial. Even if it did, I find the claim that But, the transformation isn't trivial. At the least, you have to determine the types of the parameters. very sketchy because the types don't need to be determined; they're known at compile time.

@Doval, yeah, I didn't express that very well. Tried again.

"To count as syntactic sugar, java would have to be pretending that you really wrote foo_int and foo_double functions but it doesn't." - as long as we talk about overloading methods and not polymorphisms what would be a difference between foo(int)/foo(double) and foo_int/foo_double? I don't really know Java very well but I would imagine that such renaming really happens in JVM (well - probably using foo(args) rather then foo_args - it does at least in C++ with symbol mangling (ok - symbol mangling is technically an implementation detail and not part of language).

@Doval: "I don't think anyone ever said the transformation for syntax sugar has to be trivial." – True, but it has to be local. The only useful definition of syntactic sugar I know of is from Matthias Felleisen's famous paper on language expressivity, and basically it says that if you can re-write a program written in language L+y (i.e. some language L with some feature y) in language L (i.e. a subset of that language without feature y) without changing the global structure of the program (i.e. only making local changes), then y is syntactic sugar in L+y and does

… not increase L's expressivity. However, if you cannot do that, i.e. if you have to make changes to the global structure of your program, then it is not syntactic sugar and does in fact make L+y more expressive than L. For example, Java with enhanced for loop is not more expressive than Java without it. (It's nicer, more concise, more readable, and all around better, I would argue, but not more expressive.) I am not sure about the overloading case, though. I'll probably have to re-read the paper to be sure. My gut says it is syntactic sugar, but I'm not sure.

@JörgWMittag This looks like a great paper, thanks for pointing me in that direction. I would imagine that if renaming a variable counts as a local change, so does renaming a function, and thus overloading qualifies.

@MaciejPiechotka, if it were part of the language definition that functions were so renamed, and you could access the function under those names, I think it would be syntactic sugar. But because its hidden as an implementation detail, I think that disqualifies it from being syntactic sugar.

@Doval, the question is at the call site. How does the compiler know which overload to call. Is it only doing that with local information?

@WinstonEwert What's your definition of "local information"? The function gets chosen based on the static type of the arguments, which is known at compile time.

When I think of a local transformation, I think of it as only using information at the call site. Thus information about which overloaded versions of a function exists is non-local. Basically, I think of something that just rewrites the AST without having to look at symbol tables, etc.

Winston, please look at the edit to my question. It clarifies why I think method overloading is syntatic sugar. Also, BTW if I'm not mistaken the Java compiler does compile foo(int) to foo_i and foo(double) too foo_d. It treats overloaded methods as completely different methods.

@Prog, given docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.6, it looks to me like java does not compile foo(int) to foo_i, they are compiled to different methods but the methods are not distinguished by name.

The ONLY reason I would consider overloading in Java not sugar would be because of its reflection capabilities. In C++ we have templates, and thus generic semantics would get lost. If (and that's a big if) C supported overloading (with consistent name mangling semantics), that would be sugar.

@ThomasEding, What's your definition of "sugar"?

A language reduction from L to L' such that: (1) L contains L'. (2) For all language constructs in L, L' can express identical semantics. (Identical is stronger than equivalent.)

@ThomasEding, are for loops syntactic sugar for while loops?

@WinstonEwert: Very much so. Even if is sugar over while.

@WinstonEwert: But for the availability of Reflection, would there be any way of telling whether they were distinguished by name or not? Even with Reflection, would there be any way other than by examining bytecode to distinguish whether a compiler attached type information to names whenever methods were defined or called, and Reflection simply stripped that information when the names were retrieved?

@ThomasEding, my definition is that syntax sugar is a case where construct X is converted to construct Y in the same language as part of the compilation/interpretation of a program (at least conceptually). In C, a[x] is interpreted as *(a+x). However, if doesn't get converted into a while during compilation, even if it theoretically could.

@ThomasEding, ultimately it comes down to differing definitions of the phrase. There's no point in arguing over the definition of words, I'll simply note that I believe mine is closer to how the phrase is typically used. But that's also possibly just my experience. Undoubtedly, there are also many uses that accord with your definition.

@supercat, if that's your criteria for deciding whether something is sugar, everything is sugar. That's seems an uselessly broad category.

@WinstonEwert: I wasn't seeking to define "sugar", but merely to ask whether there are any meaningful semantic differences, outside Reflection, between having multiple overloads with the name name, versus overloads with different names. There is one which hasn't been mentioned, which is that the way outside constructor calls are implemented would not allow a type to have more than one constructor except by using overloading.