Swift用Swift编写的AST。 ∞的第3部分

在上一篇文章中,我开始介绍Swift语法的Declaration语法”部分。

在这篇文章中,我将介绍letvar声明。 Swift语法怪异的另一部分确实是棘手的部分。

let从简单的一个开始-let。 这是语法:

在概念上没有什么新鲜的。 让我们对列表使用与ImportPath相同的方法

  struct ConstantDeclaration { 
let属性:[Attribute]
let修饰符:[DeclarationModifier]
让初始化器:PatternInitializerList
}

我不会将pattern-initializer部分分隔为另一种类型,并将其建模为元组:

  struct PatternInitializerList { 
让初始化器:[(模式,初始化器?)]
  init(head:(Pattern,Initializer?), 
尾巴:[(模式,初始化程序?)]
{
初始值设定项= [head] + tail
}
}

将来我们可能应该将此列表抽象为类似List东西。

新类型呢? 声明修饰符使我感到惊讶。 只要看一下它的语法:

它包含所有可能的修饰符。 但是其中只有几个可以使用let声明有效。 看起来在这一点上,Swift团队经历了一些紧缩,并决定不对其进行过度设计。 我们将其建模为巨大的枚举:

 枚举DeclarationModifier { 
案例类
案例“便利”
案例动态
案例“最终”
大小写
案例懒惰
情况“可选”
案例`override`
案例`postfix`
大小写前缀
大小写必填
静态的
案例“无主”
案例`unownedSafe`
情况“弱”
案例访问(AccessLevelModifier)
大小写突变(MutationModifier)
}
 枚举AccessLevelModifier { 
案例“私人”,privateSet
案例`fileprivate`,fileprivateSet
案例`internal`,internalSet
案例`public`,publicSet
case`open`,openSet
}
 枚举MutationModifier { 
大小写变异
大小写不变
}

我认为这是真正的失败点。 这意味着就Swift编译器而言,并非所有语法正确的树都是正确的。 不好。 我可以在我的语法版本中修复它,或者在Swift邮件列表中提出更改建议。 但是可以在覆盖AST之后执行此操作(如果有)。