エラー型による条件分岐をやりやすくする

[FineArchs]

毎回if Core:type(v)!='error' ...と書かなければならないのは不便なので、より簡単な書き方を考えます。

今までの案
catch(v) {...}

• 投げてないのにcatchはおかしい

if Core:is_ok(v) ...

• あまり書きやすさが変わっていない？

補足
v ?? v2（vがエラー型以外ならv、エラー型ならv2を返す）、?.（エラー型ならチェーンしない？）も欲しい

[FineArchs]

if Is:ok(v) ... とか…？

[marihachi]

ifによる値のチェックとは区別して

if v is error { ... }

とか...？

[salano-ym]

Core:type(v) == Tをv is Tにする？

[FineArchs]

Core:type(v) == Tをv is Tにする？

同意見

[salano-ym]

isnotは必要？

[FineArchs]

どちらかと言うと型表記の方に補集合を表す表記方が欲しいような？

[takejohn]

Rustの?みたいにエラーならそれをreturnする演算子が欲しいかも……

@f() {
  let v = ...
  v?.something // vがエラーならvを返し、そうでなければプロパティを評価
}

// トップレベルの場合
let v = ...
v? // vがエラーならCore:abort(v.name)

標準関数を追加するならこう？(大して楽にならないかも)

Error:is(v) // vがエラーならtrue、そうでなければfalseを返す
Error:and(v, v2) // vがエラーならv2、そうでなければvを返す
Error:and_then(v, @(err) { ... }) // vがエラーなら関数を引数vで呼び出してその返値を返し、そうでなければvを返す

[FineArchs]

?はこれまた欲しいと言われているJavaScript流のオプショナルチェーン（?.）と文法的に衝突するんですよね…

[takejohn]

?.と書いてエラーが出たときに、

• エラーを呼び出し元に再送出するか
• エラーを式の評価値とするか

どちらの記法のほうが平均的なコードが簡単になるんでしょうね……

前者にした場合、後者のv?.propの代わりにError:or_else(v, @(v) { v.prop })あるいは@(){ v?.prop }()
後者にした場合、前者のv?の代わりにif v is error { return v }
みたいな書き方になるのかな

それか?も?.も導入(?.を優先してトークナイズ)してv? .v2あるいは(v?).v2みたいに書かせるとか……
これは文法がややこしくなりそうですけど

[takejohn]

#237 はbug扱いになっているのでそっちを優先的に着手したいですね

[FineArchs]

あと今のReturnをラッパーで包む実装方法だと中途returnの実装がかなり面倒になりそうな気がするんですよね
（この辺りはreturnの実装の方を変えるべきな気もします）