Swift用Swift编写的AST。 ∞的第3部分
在上一篇文章中,我开始介绍Swift语法的Declaration
语法”部分。
在这篇文章中,我将介绍let
和var
声明。 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之后执行此操作(如果有)。