Answers:
怎么样了：“语法糖是某些功能的便捷速记，它不会引入任何有意义的抽象层。”
a->b如您所指出的，Take 等价于(*a).b。此符号是否允许您以任何有用的方式（否则隐藏方式）考虑代码？不，所以是语法糖。
现在考虑a[i] == *(a + i)。考虑任何以任何实质性方式使用数组的C程序。您能想象不使用[]符号来理解它吗？使用多维数组？将数组视为整个单元是有意义的，而不是作为对连续内存块开始的引用。如果您打算对数组进行复杂的操作确实有助于了解数组在C中的工作原理，但始终必须考虑“我需要在内存的右边存储2 * i字节的两位内存”，这毫无用处。所引用的内存位置a。” 数组的重点是能够抽象化将序列存储为相干单元的过程。该[]符号有助于这种抽象。这不是语法糖。
这并不是说语法糖总是坏事。像许多典故一样，它已成为一个绰号，并与“真实特征”相对立。但是，如果不是let简写形式（和其他形式），则LISP和Scheme将不可读。
三元运算符<pred> ? <cnsq> : <alt>是另一个示例。语法糖可以帮助组织程序并删除冗余代码，这可以节省日常维护成本。如果语法糖有助于消除编程的语法障碍，那么有时它可能比堆积在“真实特征”上更为可取。
用R ^ 5RS引用，“编程语言的设计不应通过在功能之上叠加功能来实现，而应消除那些使附加功能显得必要的弱点和限制。” 恕我直言，语法可以说是弱点和局限性，因此让程序员摆脱语法可以提高语言的表达能力。
恕我直言，我认为您无法对语法糖进行定义，因为该短语是BS，很可能被那些在“真实操作系统”上使用“真实工具”谈论“真实程序员”的人使用。
之所以获得其学士学位，是因为“真实特征”或“语法糖”的想法就像没有真正的苏格兰谬论。因为这些短语是“临时保留不合理断言的尝试”。这里的断言是这里的功能微不足道，因为您可以改用“真实功能”。
它的BS，因为有人认为应避免使用糖，因为您可以编写错误，但应坚持使用糖，因为它更难编写错误。那不是很棒 使用相同的逻辑，相同的短语会得出完全相反的结论。
它的BS，因为没有人引用可用性研究或缺陷计数研究来支持其可读性或可维护性或可能的缺陷论证。
它的BS，是因为人们经常对等或对等。例如，此问题断言C＃字符串是char数组的糖。他们不是。
但是，如果您想说两件事在语义上是等效的，那么它们就是糖，这可以帮助您继续进行定义。
如果您想对某人不屑一顾，也可以使用该短语。
这是一个相关概念的非常严格的定义：表达性，由
Matthias Felleisen撰写：
关于编程语言的表达能力 [后记是我能找到的唯一自由格式。
另请参阅有关Java语言和闭包的条目。
实际上，如果可以通过仅进行局部更改而将其更改为不具有语法的形式，则该语法就是糖。例如，如果没有语法格式，则需要更改几个不同的代码位置，或将片段移动到其他位置，那么它就不是糖。
也就是说，适当使用语法糖是可以的。我认为，任何Scheme程序员都希望有一种let特殊的形式，而不是必须先创建一个新的匿名函数然后应用它，这将做同样的事情。目的是使代码更清晰。
我认为“ 语法糖 ”一词表示表达相同底层语义的另一种语法。
以一种编程语言A为例，该编程语言A的操作sum可以累加任意长度的整数列表。用这种语言我们可以写表达式
sum []
sum [3, 4, 5, 1]
sum [2, 7]
其结果分别为0、13和9。
现在，假设我们意识到90％的时间使用sum两个参数，因此为了方便起见，我们引入了新的符号
2 + 7
这只是语法糖的sum [2, 7]。
现在，使用第二种语言B，该语言没有任何加法运算。我们可能有类似<，的运算符=，允许我们比较数字，但无法添加数字。在语言B的版本2中，我们引入了一个新的带有语法的加法运算
2 + 7
像往常一样增加数字。
在语言A的上下文中，该+表示法是语法糖（它是一种替代，简化和即席的表示法，可以代替该sum [...]表示法使用）。同样，正如Hoa Long Tam的答案所指出的那样，在C中，表示法p->field是的语法糖(*p).field。
在语言B的上下文中，该+符号不是语法糖（这是用于求和运算的唯一有效语法）。同样，如果C只能通过指针访问结构成员，并且如果没有符号(*p).field，则该符号p->field将不是语法糖。
我认为，关于语法糖的误解可以追溯到关于编程语言语义的混淆。推理是这样的：
上面的推理导致了诸如“无法正确定义语法糖”，“口味问题”或“毕竟每种编程语言功能都只是语法糖”之类的通用断言。
我认为上述论点的主要问题在于语义不仅与程序可以计算的内容有关，而且还与如何计算语义有关，即，使用了什么原始构造以及如何将它们组合在一起。
因此，例如，对象不是底层位配置和位转换的语法糖，而是一种可以对数据和操作进行建模并描述计算的构造。使用对象，方法，方法调用进行的计算与使用字节，处理器寄存器，内存地址进行的计算（即使两种计算的结果相同，即使第二种计算用于实现第一种计算）也不相同。
我做了很长的描述，但是我认为这是一个重要的方面，我在其他答案中都没有提到。
底线：语法糖是一种已经存在于某种语言中并且已经具有明确定义的语法和语义的构造的替代（可能更方便）语法。新语法（语法糖）与现有语法不同，但具有相同的语义。如果以一种语言和一种新语法引入一种新的构造，那么您就没有语法糖。
语法糖是一种功能，它不会扩展语言本身的表达能力，因此是多余的，有时甚至是符号的滥用，但它既简化了作者的生活，又为读者提供了更多的见识。
为了回答我自己的问题，一个功能是语法糖，当且仅当它被包括主要是为了增强美观性和可读性，并且可以以大约一对一的方式被琐碎地翻译成减糖版本。（我大致是一对一的，指的是模微不足道的东西，例如交换运算的顺序，变量名和空格。）
只能由大量程序员约束才能使用的任何功能都不是语法糖。作为其子集，任何增加类型安全性的功能都不是语法糖，因为通过程序员的纪律来手动实施类型安全性是非常重要的。例如，C ++的对象系统不只是C指针强制转换多态性之上的语法糖。
如果删除了任何功能，那么它们都将需要大量的代码重复或进行重大的重新设计，这都不是语法上的糖，因为这些功能都不是一件小事。例如，模板不仅是语法糖，因为没有它们就获得等效的功能将需要大量的克隆和修改。
的东西，例如是语法糖：
a[i] 代替 *(a + i)
a -> b 代替 (*a).b
foreach 而不是手动键入迭代器语法。
所有运算符重载都是纯语法糖。
这听起来像一个公平且合理明确的定义吗？
我不确定计算机科学领域内的内容，但是对于逻辑领域，定义的保守性和可消除性[ 1 ] 的概念似乎是一致的。
应用库里-霍华德的对应关系，人们也许可以提出关于“句法糖”的平行概念。