It seems like in language holy wars, people constantly denigrate any feature they don't find particularly useful as being "just syntactic sugar". The line between "real features" and "syntactic sugar" tends to get blurred in these debates. What do you believe is a reasonable and unambiguous definition of syntactic sugar that avoids it being defined as any feature the speaker/writer doesn't find useful?
closed as primarily opinion-based by MichaelT, GlenH7, Scant Roger, Snowman, Ixrec Dec 13 '15 at 16:48
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.
How about this: "syntactic sugar is a convenience shorthand for some functionality that does not introduce any meaningful layer of abstraction."
This is not to imply that syntactic sugar is always bad thing. Like many alliterations, it has become an epithet and pitted against "real features." But LISP and Scheme, for example, would be unreadable if not for the
The ternary operator,
To quote R^5RS, "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." IMHO, syntax can qualify as a weakness and restriction and so letting programmers get away from syntax can increase a language's expressivity.
Here is a very rigorous definition for a related concept: expressiveness, by
Also see this entry on the Java language and closures.
Effectively, something is syntactic sugar if it can be changed to a form without the syntax by only making local changes. If, for example, without the syntactic form, you would need to change several different code locations, or move fragments to other locations, then it is not sugar.
That said, syntactic sugar is fine when used appropriately. I think any Scheme programmer would rather there be a
IMHO I don't think you can have a definition for syntactic sugar, because the phrase is BS and is likely to be used by people that talk about "real programmers" using "real tools" on "real operating systems"
Its BS because the idea of "real features" or "syntactic sugar" is like the No true Scotsman fallacy. In that the phrases are "ad hoc attempts to retain an unreasoned assertion". The assertion here is that a feature here is trivial because you could use a "real feature" instead.
Its BS because some argue the use of sugar should be avoided because you can write a bug but you should stick to it because its harder to write bugs. Isn't that awesome. The same phrase leads to exactly opposite conclusions using the same logic.
Its BS because no one cites usability studies or defect count studies, to back up their readability or maintainability or likely defect arguments.
However if you want to say two things are sugar if they are semantically equivalent and that helps go ahead and define it anyway you want.
If you want to be dismissive of someone you can also use the phrase.
I think the term syntactic sugar indicates an alternate syntax to express the same underlying semantics.
Take for example a programming language A that has an operation
whose results are 0, 13, and 9, respectively.
Now, suppose that we realize that 90% of the times we use
which is just syntactic sugar for
Now take a second language B that has no addition operation whatsoever. We may have operators like
which adds numbers as usual.
In the context of language A, the
In the context of language B, the
In my opinion, there are some misunderstandings about syntactic sugar that can be traced back to a confusion regarding programming language semantics. The reasoning goes like this:
The above line of reasoning leads to generic assertions like "syntactic sugar cannot be defined properly", it is a "matter of taste", or "every programming language feature is, after all, just syntactic sugar".
I think the main problem in the above argument is that semantics is not only about what can be computed by a program, but also about how it is computed, i.e. what primitive constructs are used and how they are combined.
So for example, objects are not syntactic sugar for the underlying bit configurations and bit transformations, they are a construct that allows to model data and operations and to describe computations. Computing with objects, methods, method calls, is not the same as computing with bytes, processor registers, memory addresses (even if the two computations have the same result, and even if the second computation is used to implement the first).
I made this description a bit long but I think it is an important aspect that I haven't seen addressed in other answers.
Bottom line: syntactic sugar is an alternate (possibly more convenient) syntax for a construct that is already in a language and has already a well-defined syntax and semantics. The new syntax (syntactic sugar) differs from the existing one but has the same semantics. If you introduce a new construct in a language and new syntax for it, then you do not have syntactic sugar.
syntactic sugar is a feature that doesn't extend the language expressivity itself, hence being redundant and sometimes an abuse of notation, but that both simplifies writer's life and gives the reader more insight.
To answer my own question, a feature is syntactic sugar if and only if it it was included primarily to enhance aesthetics and readability and can be trivially translated in a roughly one-to-one fashion into the de-sugared version. (By roughly one-to-one I mean modulo trivial things like the order of commutative operations, variable names and whitespace.)
Any feature that could only be de-sugared with a significant amount of programmer discipline is not syntactic sugar. As a subset of this, any feature that increases type safety is not syntactic sugar, since manually enforcing type safety via programmer discipline is highly non-trivial. For example, C++'s object system is more than syntactic sugar on top of C pointer cast polymorphism.
Any feature that would require either significant code duplication or a major redesign if removed is not syntactic sugar, since neither of these is a trivial undertaking. For example, templates are not just syntactic sugar because getting the equivalent functionality without them would require tons of clone-and-modify.
Example of things that are syntactic sugar:
All operator overloading is pure syntactic sugar.
Does this sound like a fair and reasonably unambigous definition?
"Syntactic sugar" is not a rigorously-defined term. Depending on who you ask, you will most likely get one of the following sorts of definitions:
I'm not sure about within the fields of the computer sciences, but with the field of logic there are the concepts of conservativeness and eliminability of definitions  seem to be in the same vein.
Applying the Curry-Howard correspondence, one might be able to come up with a parallel concept regarding “syntactic sugar”.