FINEARCHS

str.index_ofはあるようですが配列に対するものはなさそうですね。追加してもいいと思います。

Vim等では`"..."`はエスケープシーケンスを解釈し、`'...'`は（`'`自身のエスケープを除き）解釈せず生文字として受け取る等の形で両者の差別化がされているのですが、どうでしょうか？ いずれにせよ、生文字リテラルを書く記法も欲しい気がします。

グローバルスコープ直下のifやブロック式にreturn、関数の直下にbreakやcontinueが存在していること自体がおかしいのでエラーにしてもいいような気がします…

1. グローバルスコープ直下にreturn|break|continueがあったらエラー 2. 関数スコープ直下にbreak|continueがあったらエラー 3. return|break|continueを含むif|evalがexprとして扱われていたらエラー これらを実装できればよさそうですかね？ 個人的には、1.と2.は[return文の処理内](https://github.com/syuilo/aiscript/blob/929d91bd0eb084a6705a0dd1b48bf77083d1b768/src/interpreter/index.ts#L449C2-L453)でスコープ名をチェックするような処理で済ませられるならそれがシンプルでいいと思います。 3.に関しては構文解析レベルのエラーにしたほうが早い気がします。

@syuilo 確かにその方式は自然だと思いますが、returnがifに吸収されてしまうため ``` @someFunc(a) { if !(valid(a)) return null //... } ``` のような冒頭での脱出が出来なくなるのが少し不便だと思います。 とはいえ、そのようなコードは大体 ``` @someFunc(a) { let result=0 if !(valid(a)) { result=null } else { //... } return result...

@saki-lere はい、現状だとその通りで、if及びevalは値を取り出されない時のみ関数/ループを抜け出すようになっています。 加えて言うと、 ``` @someFunc() { let ret= eval { return 1 } ret return 0 } // it returns 1 ``` のように、取り出された値をスコープ直下で呼び出すとreturn文のように機能するようになっていたと思います。

@syuilo 一律関数抜け出しにしてしまうほうが一貫性があるのは確かですが、個人的には値が取り出されるif/eval内のreturn ``` // 例 @someFunc() { let ret= eval { return 1 } } ``` が関数抜け出しを意図していることはほぼなく、if/evalの値として返るものと期待（勘違い）されていると思われるので、意図しない挙動を防ぐためエラーを出すのが良いと考えています。 また、現状のreturnの実装は一律関数抜け出しとかなり相性が悪いように感じられます。

> `(if (y == 0) {return null} else x/y)` は構文エラーにならないのに `[(if (y == 0) {return null} else x/y) x*y]` は構文エラーになるなど、直感に反する場面はいくつかあるかもしれないと思います。 @yuriha-chan さんの言うような使い方をする人がいるのであれば、やはり一律関数抜け出しの方が良さそうですね。そちらの方向で進めてみます。 例外キャッチを利用した実装は思いつきませんでした…試してみようと思います。 （それが完成してからこのissueを閉じます）

@marihachi 一度それで実装しようとしたのですが、いい実装が思いつかなく二の足を踏んでいます…

グレーアウトだと元々白黒の絵文字がわかりにくくなってしまうと思います。 上から何かしら半透明か隙間の多い画像を被せるのはどうでしょうか？