This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
あれのせいで鉄鉱石を採掘した瞬間に鉄にして運搬してしまうメソッドに迷いが生じるんだよなぁ
基本的に鉱床のすぐそばで鉄板・銅板に加工してから鉄道輸送しているのでコンクリ床だけは別のラインを確保しなければならない
加工前を要求されて微妙に困るシリーズとしては他に線路がありますね(石レンガではなく石を要求するため)
This account is not set to public on notestock.
「大東亜以下」メールでマイナビが謝罪 “学歴フィルター説”は否定(1/2 ページ) - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2112/07/news155.html
> マイナビの新卒向け採用サービス「マイナビ新卒紹介」が12月6日に送信したメールの件名が「<第1>大東亜以下➈」となっていた
これで学歴フィルタ否定して信じるやつがいるのかよwww
サイクルが一定で睡眠時間を確保できていればみんな生活習慣マトモ組です。
人体の構造が雑なんじゃなくて仮説が間違っている
This account is not set to public on notestock.
創作上の NL でケツ使う場合にもいちいち洗う描写してないこと多いし、それは単にどれだけ神経質になるか文化圏の問題でしかなさそう (?)
よーするに「BL だから穴を追加した」じゃなくて「読者や作者にそういうことを気にする人々が多いから穴が追加された」じゃない? という (めちゃくちゃどうでもいい)
この好みタグ、普段見てる動画のタグが出てくるので、仕組みとしてはエロサイト見てたらエロ広告出てくるみたいなもんなので、つまり…
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
そもそも比較演算子も boolean を返す演算子なんだから、
「v が true と等しいことを確認する」を v == true と書くなら、それは結局「v == true という演算の結果が true と等しいことを確認する」ことでもあるんだから (v == true) == true と書かなければ筋が通らないし、以下略
(((v == true) == true) == true) と書かないのに v == true と書くのは一貫性がないでしょう
a == b を「事実の表明」か何かだと勘違いしているのかもしれないが、そんなものはない。ただの比較演算子です
まあ数学の文脈を引き摺っているのだとしたら多少は同情するけど、いや論理学というものがあってね……
逆に中学高校までの数学で「a が 2 と等しいかどうか」の『かどうか』を表現する記法が存在しないので、その影響でというのはあるかもね
This account is not set to public on notestock.
This account is not set to public on notestock.
あまりコーディング規約がきちんとしているところで仕事をする機会が無いが、trueの比較でif(bool)はやるけど、falseのときはif(!bool)じゃなくてif(bool == false)と書くようにしている。なんか見落としそうで。!使えと言われたら使うけども。
This account is not set to public on notestock.
@tacumi そもそも Haskell だと括弧によるブロックよりもオフサイドルールを使うし、もっといえば guard とかでどうにかするケースの方が多そう
[[ ... ]] と (( ... )) は中身がゼロか非ゼロかで真の扱いが逆になってるとかね
🖕 ← これはですね、下が点で上が棒、すなわち「!」記号を表現したものであり、 C 言語などの論理否定演算子にちなんで否定の意味を持っています #適当
C++11 からは contextual conversion で operator bool() が (たとい explicit であろうと) 呼ばれるようになったので無事 if(stream) で済むようになった。めでたし (?)
クソの話をするなら===falseの話をしますが、しなくていい場ですね?
This account is not set to public on notestock.
This account is not set to public on notestock.
インドネシア・ジャワ島で火山が噴火、1人死亡 逃げ遅れた住民も(朝日新聞デジタル) - Yahoo!ニュース
https://news.yahoo.co.jp/articles/05f4bd50cda745eb7788fd3aeb9bd03f21bdfc1c
JAVA + YOU,
EVACUATE
TODAY!
nullable な String s に対して s.equals(t) みたいなことをすると危険なんじゃ、みたいなとんでもない罠
近年の話だと、 Java の Optional<T> を null が入れられるやつが一番好きかな
たとえばビットパターン混ぜ混ぜする時とかは「PatternA | PatternB」みたいに書きたいけど、条件とかの時は「条件A | 条件B & 条件C」よりも「条件A or 条件B and 条件C」みたいに予約語方式の方が目に入りやすくて見間違えにくいじゃん?><
その条件はテキストで書かれるので、メタな意味を持つ and や or や not はテキストで書くより記号で書いてほしいですね。というわけで and / or / not キーワードきらい。
Optional<String> a = null;
Optional<String> b = Optional.empty();
Optional<String> c = Optional.of("hello"); // ←これ合ってたっけ?
もう Java の String 生成で new String〜 的なのが必要かどうかなんて覚えてないよ (たぶん mutate しないなら不要)
だからさっきから書いてるように、| とか ! とか記号小さすぎて見間違いとか見落としの危険高いじゃん!?><;
条件が並んでいて | に見落しも何もないと思う。条件が2つ以上並んでいるなら必ず接続があるんだから。
わかりやすくするために超極端に言うと、(!illiliilllilli | iilliillili)よりも (not illiliilllilli or iilliillili)のほうが見やすいじゃん!?><;
そんなクソコードが許されるなら
and_ and nad _or or and_and and or_ or
は読みづらいじゃん……その論法はクソすぎる
ちなみにこれはそもそも成立してないです (成立していないことを看破するのさえコスト高い)
This account is not set to public on notestock.
はちゃめちゃに長い operator とかでなければ人類は必ず見間違いや見落しをするので開発環境やコンパイラが適切な指示や指摘をしてくれるならなんだっていい
まあ正直これなんだけど、シンタックスハイラトなしの極限環境をたまに使うものぐさオタクなので気にしてしまう
ifでnotの有無の間違いによるミスってコンパイラが検出できないバグの率高くない?><;
あるいは is_foo() と is_not_foo() を用意する手もあるだろうし、あるいは enum class Foo { Present, Absent } のようにする手もあるだろうし、やりようはいくらでもある。ただ API デザインをする人が思想を持っているか次第
まあ誤りがあるにせよテストで検知できないようでは駄目じゃん? というお気持ちがあります
条件の意図せぬ反転なんて assert 挟みまくってユニットテストちゃんと書けばそれなりの割合で検知できそうだし (根拠なし)
というか assert 挟みまくって意図せぬブランチに進んでいるのに気付くのはデバッグ以前の段階でコーディング作業の一部なので
開発環境やコンパイラ、と含みを持たせたのは、当然テストを書くだとかなんとかもっと色々やるのがラクな環境があることの含みであって、syntax checker さえあればという話ではない
「読みづらくても(コンパイラやテスト環境がしっかりしてれば)何とかなる!」って、それ「読みづらいコードでもコンパイラやテスト環境がしっかりしてれば問題ないので読みづらいコードを書いてもよい」って主張と何が違うのか?><;
その「読みづらい」は「視認性が良くない」と「意図を読み取りづらい」が混同されていて、区別するべきだと思いますね
どうでもいいけど { ... } はわかりづらいから BEGIN ... END にしたがる人の話を思い出したわ
よくみると
# define END ;}
になってて、気が利いているのかいないのか……
そこまではしないけど、Pascal好きとしては色つきのエディタならばbegin endの方が見やすく感じてる><;
これって結局「括弧がクソデカく見えてくれ」とかの話であって、「{ はブロック開始であるという意味が読み取りづらいからクソコードの温床になる!」みたいな理屈にはならないじゃん、という気持ち
たとえばこれが case-esac だったり い if-fi だったり、または for-endfor だったり if-endif だったりといった追加情報がある方が { ... } よりいいじゃん、という理屈であれば私も同意するけど、 begin-end って幅と占有面積以外何も違わないじゃん。そういうのは議論の対象外。
幅と占有面積以外にも「識別子っぽいかそうでないか」も違いますね (個人的にはここが重要だけど)
This account is not set to public on notestock.
This account is not set to public on notestock.
@kb10uy 日本で有名なのは『C プログラミング診断室』のやつだけど、それ以前に Unix v7 の Bourne Shell の実装からしてそんななので由緒正しい(?)邪悪な記法 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/mac.h
This account is not set to public on notestock.
}//なんとか
だと、ズレてても検出できないんですよね。
while(cond1) {
while(cond2) {
foo();
}//while
if(cond3) {
bar();
}//if
}//while
が
while(cond) {
while(cond2) {
/* このあたりでごっそりコードを消したが、うっかり消しすぎた */
bar();
}//if
}//while
になっていても、コンパイルが通ってしまう。
で、ブロックの中身がデカかったらミスマッチに気付けない。
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
知らん operator や keyword、APL に勝るものはないのでもうなんでもいいです
Haskell の not equal が /= なのを誰も挙げてなくて、界隈の偏りを感じる
宇宙船演算子、こういう風に静的型付けの環境でこういう風にするのであれば普通に便利なのではかもって気がしてる><
ちゃんと型検査される、『「どっちがでかいの?ていうか同じ?」型』>< https://gist.github.com/orange-in-space/51a5ea3884bc0f001923b0a8a6734772
https://doc.rust-lang.org/stable/std/cmp/trait.Ord.html
もう世界で百億人くらい同じこと考えていて綺麗な言語は既にそうなっているので、そうなっていないレガシー言語がしょーもないとかいう話をグダグダしていること自体がしょーもない
This account is not set to public on notestock.
APL の not equal はちゃんと /= でも =/= でもなくて ≠ ですからね!!!
Ordering::cmp() が Ordering を返す。 Ordering は Greater, Equal, Less の3つの値のいずれかをとる。
素朴。
@orange_in_space https://gist.github.com/orange-in-space/51a5ea3884bc0f001923b0a8a6734772#file-threewaycomparisonclass-cs-L22-L40
この部分と何が違うのかわからないんですが
(a.cmp(&b) は Ord::cmp(&a, &b) とも書けますが、そうすればもっと同じですよね)
@orange_in_space 「a<=>b の結果が OrderIs.LessThanRight であるとき以下略」と「Ord::cmp(&a, &b) の結果が Ordering::Less であるとき以下略」のどこが本質的に違うのかわからないんですが。
<=> 演算子がないと満足できないって話ですか?
@lo48576 ぜんぜん違うじゃん?><; それで言う所のOrd型(?)を返す演算子があったら便利だよね!>< って話を書いてるのに><
@orange_in_space なぜそうなっていないかというと、 PartialOrd (<https://doc.rust-lang.org/stable/std/cmp/trait.PartialOrd.html>) などの概念があり、「NaN と NaN を比較したときどうすんの」などの問題があるからだと思われます。
Nan <=> NaN は何を返すべきだと思いますか? Rust ではそういう面倒な問題はそもそもありません
そういえば C++ の ordering も strong と weak があって云々などあった気がするけど、今どうなってんだ?
宇宙船演算子 - Wikipedia https://ja.wikipedia.org/wiki/%E5%AE%87%E5%AE%99%E8%88%B9%E6%BC%94%E7%AE%97%E5%AD%90
の
”Perl (数値のみ)[1]、PHP (バージョン7以上)[2]、Ruby[3]、Apache GroovyはA < B、A == B、A > Bのケースでそれぞれ-1、0、1を返す実装契約を規定している。”
みたいな実装だと型がゆるふわで気持ち悪いけど、ちゃんと型がかっちりしてる言語で導入すれば、宇宙船演算子が返すのが『「順序はこうだよ!」って型』を返すので安全だし、安全なまま短く書くメリットが出ていいじゃん!?><
っていう話をしてる><
だから、それが「a.cmp(b)」でなく「a <=> b」のような形でないといけないという強い信念は何なんだ? という話をしてます
ちゃんと比較演算の結果は「デカい」「同じ」「小さい」の3値の専用型で返ってくるわけですよ
宇宙船演算子の本質は「(boolean ではなく) 3値を返す、情報量の多い比較である」ところであって、宇宙線の形でも演算子であることでもないでしょう
特に、比較結果専用の型が返ってくるという点で安全性というか「設計の正しさ」は十分に実現されているといえるはずなのでは?
Standard library header <compare> - cppreference.com
https://en.cppreference.com/w/cpp/header/compare
C++ は各 ordering に型を用意するようにしたのね
それは「ThreeWayComparison.Compare(a, b)」と「a <=> b」を比べるから落差が大きいのであって、言語仕様の問題では?
たとえば Rust ではさっきの例 (a.cmp(&b)) はフル修飾すると
<std::string::String as std::cmp::Ord>::cmp(&a, &b)
になるわけですが、言語仕様と標準ライブラリ設計がうまくできているのでこれを
a.cmp(&b)
と書けるわけです。ここから敢えて (a.partial_cmp(&b) の存在を無視してまで) a <=> b を導入しないと片手落ちだと主張するほどの強い信念って何なんですか?
だから、短く書けたら便利だから宇宙船演算子欲しい(けども整数型で帰ってくるなんてキモイ仕様は絶対ヤダ)って言ってるんじゃん!?><
つまり C# ではそういう演算子が欲しい、というだけで言語一般の話はしてなかったわけですか
あと結局 NaN <=> NaN では何が返ってくるべきだと思ってるのだろう (これは素朴な疑問)
「比較や順序にも複数の概念がある」という前提で考えたとき、
1. その中の特定のひとつだけに演算子を与える
2. すべてを統合して、オペランドの型次第で比較結果の型も変化する
3. 演算子を割り当てない
のいずれかを選択することになるよね。
C++20 は 2 (のはず) で、 Rust は 3 なんだけど
Standard library header <compare> - cppreference.com
https://en.cppreference.com/w/cpp/header/compare
C++ の ordering のあれこれを知っていたら、「three way comparison は Greater / Eq / Less を返す!」みたいな簡単な発想では足りないというのはわかりそうなものだけど……
std::strong_ordering
https://en.cppreference.com/w/cpp/utility/compare/strong_ordering
std::weak_ordering
https://en.cppreference.com/w/cpp/utility/compare/weak_ordering
std::partial_ordering
https://en.cppreference.com/w/cpp/utility/compare/partial_ordering
https://mstdn.nere9.help/@orange_in_space/107411394832547304
"宇宙船演算子、"
"こういう風に静的型付けの環境でこういう風にするのであれば"
↑つまり型がしっかりしてるならば
"普通に便利なのではかもって気がしてる><"
"がも"が"ではかも"になってて意味不明だけど、つまり元ネタには型の問題があるけどそれさえクリアできれば普通に便利かもって言ってる><
PHP か何かの話をしているなら、そもそもそんな静的型付きでさえない言語を論って一体なにを言いたいのというレベルだし
オレンジ語っぽさをがんばってなくすなら
「宇宙船演算子って簡潔に書けて便利そう。でも、型がゆるふわで整数型で返すような実装はごめんだなぁ」
って言うことを最初に書いた><
そしたら「Rustはハイカラなので順序はちゃんと型で返す!!!」って話が返ってきて「そういう話をしてるんじゃないんだけど?><;」ってなった><
私が言いたいのは、「『でも、型がゆるふわで整数型で返すような実装はごめんだなぁ』は動的型付き言語について言ってるならナンセンスだし、静的型付き言語相手に言ってるならマトモな言語は皆そうなってるし、誰を批判してるんだ?」ということです。
雑に言えば藁人形っぽい。
型が雑な言語に「型がキッチリしてればいいのになぁ」って、それ単なる嫌味だし何ひとつとして得るものがない非建設的な話ですよね
もしかして strcmp の話してました? (そんなことはないと勝手に思ってたけど)
https://mastodon.cardina1.red/@lo48576/107411400369514947
「綺麗な言語は既にそうなっているので、そうなっていないレガシー言語がしょーもないとかいう話をグダグダしていること自体がしょーもない」がまさに「動的型付き言語について言ってるならナンセンスだし、静的型付き言語相手に言ってるならマトモな言語は皆そうなってるし、誰を批判してるんだ?」の部分です
まさかこれから比較で -1 を返すような演算子を新規導入する静的型付き言語とか常識的になさそうなので、わざわざ言うようなことでもなくね? との理解から批判だと思い込んでたけど
宇宙船演算子 - Wikipedia
https://ja.wikipedia.org/wiki/%E5%AE%87%E5%AE%99%E8%88%B9%E6%BC%94%E7%AE%97%E5%AD%90
改めて確認してきたけど、整数返す実装なんて全部動的型付き言語やんけ
少なくともwikipedia日本語版の記事の例示だと型がゆるふわな環境以外での宇宙船演算子の実装事例が書いて無いけど、型がきっちりな宇宙船演算子導入事例って具体的にどんなのがあるの?><
はい、「<=>」を実装している沢山ある言語のなかでも静的型付きなのは C++ だけでしたね
https://mastodon.cardina1.red/@lo48576/107411488336630434
こういう考えなので、欲しいのが「マトモで端的な三方比較」ではなく「<=>という演算子」だとは思ってなかったんですよ
まあ言いたいことはわかりました、 C# (.NET) では現状存在する三方比較では短く書くことができないので <=> みたいな形で演算子がどうしてもほしい、なるほどそうですね
じゃあ最初から「そんな心配しなくてもC++では宇宙船演算子が型をきっちりとした実装で導入されるからそんな心配しなくても大丈夫だよ!」で50分の謎のやり取りしないで済んだじゃん?><
や、だってまさか言いたいことの本題が「C# の三方比較クソ長ったらしすぎ」だったとは思いませんよ
まああと前の文脈を掘り起こすなら、「a <=> b」と「a.cmp(b)」のどちらが読解しやすい? みたいなアレのお気持ちもある (べつに私は慣れだと思うので心底どうでもいいんだけど、 {} と begin-end だったり and/or と &/| を気にする人はそういうの気にしそうだなとは思った)
This account is not set to public on notestock.
This account is not set to public on notestock.
C# の switch 知らんけど見たところ C の switch とおおよそ似たようなものだと考えると、「switch が式ではない制御構文である限り楽にはなれない」くらいが答えという気がする
C# はそこに関してはなぜか型がゆるふわだけど、別に長くないよ?>< むしろオレンジの書き方の方が冗長><
IComparable インターフェイス (System) | Microsoft Docs
https://docs.microsoft.com/ja-jp/dotnet/api/system.icomparable?view=net-6.0
え、マジで現代に静的型付きなのに三方比較を int で返す言語があったの!?
それはごめんなさい、 C# のマトモでなさを見誤ってました
Comparable (Java Platform SE 8 )
https://docs.oracle.com/javase/jp/8/docs/api/java/lang/Comparable.html#compareTo-T-
やっぱり Java 由来っぽい雰囲気あるな。
まあ組込み配列型が共変な言語だからなぁ…… (←何回擦るのか)
This account is not set to public on notestock.
C# 、2000年発の言語なのにどうしても新しめな印象を持ってしまうけど、コア部分の言語仕様が Java のあれこれを引き継いでいて、そもそも2000年って結構昔……みたいなアレ
バージョン覚えてないからランタイムで言うけど.NET FW <= 2.0までに産まれたやつと4.5 <=あたりで産まれたやつの差がデカすぎるだろ…
オレンジのさっきのgistでの本題として言いたい事はそのおかしさで、なおかつ、ちゃんと型安全にするのであれば宇宙船演算子を導入すると便利そうって言いたかった><
あと、この事例がまさにそうだけど、こういう場合には静的か動的かって話ではなく型安全とか強い弱いの文脈の話であって動的でゆるふわだけど強い型付けとか色々あるわけであって、静的/動的ではあんまり書かないほうがいいんでは感><
そもそも静的型付き言語は型をしっかりつけろという前提があると仮定していたので、静的型付きなのにガバい言語とかいまどき新しく用意するか? と思っていたという話です。
古代言語の系譜なら C みたいにガバいのも仕方ないとなるけど
@yumetodo 意味が明確化されるとか、メソッド生やせるとか
(まで書いたところで C++ の enum にはメソッドを生やせないことを思い出してしまった……)
@yumetodo や、でも
class Ordering {
int v;
constexpr Ordering(int n):v{n} {}
public:
operator int() { return v; }
static constexpr Ordering greater = Ordering{n};
// ...
};
みたいな感じで擬似的に enum っぽくして整数への型変換も許してメソッド (たとえば .reverse()) を生やせるようにするみたいな手はあった気がするんですよね。
@yumetodo あ、でもこれだと switch での網羅性検査ができないんですね……もうだめだ
@yumetodo 比較にも種類があるというのは完全に同意で、その結果として比較種類次第で結果型もまた変わってくるはずなので、整数だとその辺り曖昧にならないか……? みたいな気持ちがちょっとあります (たとえば NaN と NaN を比較して unordered だというのは整数でどう表現するんだ? という)
そもそも型がゆるふわかどうか面って、どこがどのようにゆるふわかで例えばオレンジが大好きな(だけど実用はしたことが無い)Adaの思想であれば「整数型とかそのまま使うのマジ!? ちゃんと名前ついた型作れよ」みたいな発想だし、あれかも><
で、強い弱いも型安全も文化圏によってかなり指すものが違ったりするので、オレンジは「ゆるふわ」ってゆるふわな書き方をしてた><;
そもそも雑でいいやという思想だと動的型付けになりがちなので (スクリプト言語の大半もそうだし)、そのあたりのコアの思想が明確でない中途半端というか一貫しない言語はそもそも考慮する価値をあまり感じないですね……
https://en.cppreference.com/w/cpp/utility/compare/partial_ordering
weak ordering、 Rust が Option<Ordering> を使っている一方で C++ は std::partial_ordering を用意しているの、個性というか方向性の違いを感じる
Rust は代数的データ型のパターンマッチがあって C++ はそうではないという文法が表れているという認識。
C++ だとswitch(ord) { case optional.value(greater): ... } みたいなこと書けないから
オレンジが言いたい事としては、この議論をするなら、特に型システムの議論に慣れてない人がいる場合には、『動的静的の厳密な違いの話』( https://mstdn.nere9.help/@orange_in_space/105989721643608005 https://mstdn.nere9.help/@orange_in_space/105989751027039873 )と、『静的型な環境と動的型な環境それぞれの傾向の話』は厳密には違うって話もしてあげないと、混乱して可哀想かもって・・・><
そもそも言語の設計の話をするならその辺りは教養の範囲内ではの気持ちがなくもないので……
Go が代数的データ型を導入してないの本当に謎なんだよな、いや謎もなにも言語としての表現力や抽象のしやすさよりも多数のユーザに書かせるときのコードの複雑さのアラインとかを考えているとか、そういう産業的な理由なのだろうけど
でも、お約束の
1 + "hoge"
がエラーになるかどうかみたいなのもどう型付けするかの話であって動的静的の話とは直接関係ないって、そこ理解してない人が多い話ではあるかも><
そういう (言ってみればエッジケース的でもある) 話、結局「自然なセマンティクス」があるよねという話になるので、最低限意味論という概念を認識できていないとどうしようもないし、この話をするたびにいちいち意味論について書くほど暇でもないというのがある
人間の三大欲求であるところのパターンマッチのある言語でプログラムを書きたい欲
C++のエラーメッセージを先頭から読んでたら人生が終わるか標準化委員になっちゃう
This account is not set to public on notestock.
昔、代数的データ型がどう代数的なのかとてもよく語っているブヨグがあったんだけど、たぶん消えてしまった
以後そのような web 記事を他で見たことがないので、なんとなれば私が書く必要が……みたいな気持ちがちょっとある (いやまあ探せば沢山あるんだろうけど)
こういう話をするたびに「なぜ Go は……」とか思ってしまうのでマジで健康に悪い、 Go に関するすべての知識を脳から一掃して健康になりたい
育ちが悪いので、 Rust を書いててブロックが式になるけど手続き型っぽいのなどを見て最初に浮かんだ感想は「これ Ruby で見たやつだ、いいじゃん」でした (Scheme ではなかった)
ポヨグヤミン入門が論理回路からの Verilog からの C だったので、どうしても手続き型視点がなぁ
なんでVerilogから入ったのにPascal系の風習に慣れなかったのか謎><;
CPU を設計するときと CPU を駆動するプログラムを設計するときは脳の使う領域が違うので……
論理回路の設計なんてリアクティブプログラミングの典型例みたいなところがある (適当) けど、それは日頃コードを書くとき CPU の声を聞きたくなるというのとは別のレイヤーの話なので
あと言語について語るとき大抵は syntax の話なんて興味なくて semantics の方しか見てないので
シェルスクリプトで case - esac なのが { ... } じゃなくて不満だとか、そういうことは思わないし
This account is not set to public on notestock.
for (int x = 0; x < col; x++) {
for (int y = 0; y < row; y++) {
arr[y][x] = foo(x, y);
}
}
こうですか
共変な配列問題、何が正しい(≠実用的)な解決策なのかあんまり分かってない。読むときは共変、書くときは反変としてインターフェースを分ければいいんか?
Rust の AsRef<T> と AsMut<T> みたいなのはひとつのやり方だと思うけど、 AsMut<T> の前提として AsRef<T> の実装が求められているのであまり継承がどうという方向で適当かは……
配列が複雑なデータ構造なのにmutableなのが悪いような気がしてきた。mutabilityは悪