Next: 改行できる箇所の追加実装

[marihachi]

What

パーサーに以下の仕様を追加し実装します：

• 配列リテラルの[の後および]の前には0個以上の改行を配置する
• オブジェクトリテラルの{の後および}の前には0個以上の改行を配置する
• 配列リテラルで1つ以上の連続した改行をセパレータとして使用できる
• オブジェクトリテラルで1つ以上の連続した改行をセパレータとして使用できる

いくつかテストを追加。

---

パーサー内でトークンの種類を取得する方法を改善します。

• プロパティで実装するとType Guardが誤作動する。 → メソッドに変更してType Guardを抑制する。

Why

以下の不具合修正
#396 (comment)

Additional info (optional)

変更箇所が多いのでコミットごとにレビューしてもらう方が良いかもです。

[FineArchs]

#396

グループ式内の改行は式内でバックスラッシュを使うと改行できる仕様とぶつかるのでやめておきます

この辺りあまりよく分かっていないので、もう少し詳しくお願いします

[marihachi]

1 + 2のような式の途中で改行を許すと式の意味が変わったり、文として解釈されることがあるので、
式の途中で改行したい場合はバックスラッシュ+改行で改行する
という仕様にしてた気がします。

これは1つの文：

let x = 1 + 1

こうすると、文と式文に分かれてしまう

let x = 1
  + 1

[FineArchs]

それはそうなんですが、括弧の中には１つの式しか入らないのでその多義性は本来起こらないんですよね
まあ別の機会にまた考えようと思います

[FineArchs]

パーサーの改修をmarihachiさん（と私）以外がレビューしにくい問題
パーサーの修正は必要なレビューの人数減らします？

[marihachi]

@syuilo レビュー可能？👀

[marihachi]

パーサーの改修をmarihachiさん（と私）以外がレビューしにくい問題 パーサーの修正は必要なレビューの人数減らします？

@FineArchs
レビューしにくい問題はどこにありますかね
仕様が把握できないとかでしょうか

[FineArchs]

それもあるとは思いますが、単純にプログラムとしての複雑性が高いというのが一番大きいと思います。
不可抗力なので対策が難しそう…

[salano-ym]

局所的な変更であればレビューは可能かと思います

[marihachi]

マージ条件を満たしたのでマージします