Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part21
https://mevius.5ch.net/test/read.cgi/tech/1692105879/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/02/14(水) 10:53:25.15

>>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ

**デフォルトの名無しさん** · 2024/02/14(水) 11:07:38.32

使う側が気をつけるならC++も問題ないからな

**デフォルトの名無しさん** · 2024/02/14(水) 11:17:22.43

>>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター

**デフォルトの名無しさん** · 2024/02/14(水) 11:23:15.20

>>759
そゆこと
だからRustは不要

**デフォルトの名無しさん** · 2024/02/14(水) 11:28:02.15

ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない

**デフォルトの名無しさん** · 2024/02/14(水) 11:51:49.92

ここで>>9-20の流れを振り返ってみましょう

**デフォルトの名無しさん** · 2024/02/14(水) 11:52:42.46

C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば

fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}

みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。

**デフォルトの名無しさん** · 2024/02/14(水) 12:13:59.14

>>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん

>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする

**デフォルトの名無しさん** · 2024/02/14(水) 12:19:27.37

>>761
だからの文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。

**デフォルトの名無しさん** · 2024/02/14(水) 12:25:13.12

>>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。

**デフォルトの名無しさん** · 2024/02/14(水) 12:29:23.30

>>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している

**デフォルトの名無しさん** · 2024/02/14(水) 12:49:07.16

>>768
自明だと検証できる証明を示して頂戴。

検証可能性の無い主張は単なる疑似科学だし。

**デフォルトの名無しさん** · 2024/02/14(水) 12:52:16.39

欠点がない言語なんて無いから言い争ってもね。

**デフォルトの名無しさん** · 2024/02/14(水) 12:57:57.69

そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明

**デフォルトの名無しさん** · 2024/02/14(水) 13:07:28.33

たし🦀

**デフォルトの名無しさん** · 2024/02/14(水) 13:09:31.24

おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき

**デフォルトの名無しさん** · 2024/02/14(水) 13:16:05.40

drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ

**デフォルトの名無しさん** · 2024/02/14(水) 13:33:10.33

境界知能が可視化されてる

**デフォルトの名無しさん** · 2024/02/14(水) 13:53:52.28

>>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。

**デフォルトの名無しさん** · 2024/02/14(水) 13:55:32.21

>>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ

ダックタイピングは白紙の契約書にサインするようなものだ

**デフォルトの名無しさん** · 2024/02/14(水) 13:57:04.55

>>775
お前のこと？

**デフォルトの名無しさん** · 2024/02/14(水) 14:31:04.48

>>777
これな

**デフォルトの名無しさん** · 2024/02/14(水) 14:41:15.13

>>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……

**デフォルトの名無しさん** · 2024/02/14(水) 15:12:12.70

>>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな

**デフォルトの名無しさん** · 2024/02/14(水) 15:36:36.14

>>764
Rustで++は排除されている

理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな

**デフォルトの名無しさん** · 2024/02/14(水) 16:02:27.29

>>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。

**デフォルトの名無しさん** · 2024/02/14(水) 16:29:39.74

>>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ

fn increment(dest: &mut u32) -> u32 {
　std::mem::replace(dest, *dest + 1)
}

**デフォルトの名無しさん** · 2024/02/14(水) 16:36:51.93

質問している人間相手なら関係ないことを書いて良いわけではない

**デフォルトの名無しさん** · 2024/02/14(水) 16:42:22.39

>>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。

**デフォルトの名無しさん** · 2024/02/14(水) 16:46:13.61

ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん……

**デフォルトの名無しさん** · 2024/02/14(水) 16:46:26.67

一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない

**デフォルトの名無しさん** · 2024/02/14(水) 16:51:03.66

>>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。

ID:S2bQYQek さん、すいません

**デフォルトの名無しさん** · 2024/02/14(水) 17:05:32.23

人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい

**デフォルトの名無しさん** · 2024/02/14(水) 17:06:20.11

だから境界知能なんでしょ

**デフォルトの名無しさん** · 2024/02/14(水) 17:19:45.82

腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう

**デフォルトの名無しさん** · 2024/02/14(水) 17:26:03.70

tmuxよりscreen派だよ。

**デフォルトの名無しさん** · 2024/02/14(水) 17:50:47.59

個人的には後置インクリメントだけを関数化するのは微妙に感じる

fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う

**デフォルトの名無しさん** · 2024/02/14(水) 19:51:05.67

>>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。

**デフォルトの名無しさん** · 2024/02/14(水) 19:57:21.78

>>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。

**デフォルトの名無しさん** · 2024/02/14(水) 20:14:14.28

>>796
C++では機能の異なる同名メソッドを区別できないから欠陥品

**デフォルトの名無しさん** · 2024/02/14(水) 20:52:10.35

>>797
引数・戻り値で区別できるだろ。

**デフォルトの名無しさん** · 2024/02/14(水) 21:01:37.45

>>798
それに依存してしまうのがC++の限界

**デフォルトの名無しさん** · 2024/02/14(水) 21:18:41.79

>>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。

**デフォルトの名無しさん** · 2024/02/14(水) 21:58:58.38

>>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため

**デフォルトの名無しさん** · 2024/02/14(水) 22:13:29.10

>>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？

Rustのtraitて、副作用のコントロールできたっけ？

**デフォルトの名無しさん** · 2024/02/14(水) 22:26:20.82

traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ

**デフォルトの名無しさん** · 2024/02/14(水) 23:19:42.33

>>803
コンセプト。

**デフォルトの名無しさん** · 2024/02/14(水) 23:20:56.22

>>792
毎度毎度のことで余裕を削られた最後だったんだよ。

**デフォルトの名無しさん** · 2024/02/15(木) 00:20:11.01

毎度毎度のことという認識を持っていながらなぜここに書き込むのか

**デフォルトの名無しさん** · 2024/02/15(木) 00:23:07.31

>>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。

**デフォルトの名無しさん** · 2024/02/15(木) 07:06:08.60

>>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的

**デフォルトの名無しさん** · 2024/02/15(木) 07:43:10.62

>>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。

**デフォルトの名無しさん** · 2024/02/15(木) 07:55:56.64

>>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり

**デフォルトの名無しさん** · 2024/02/15(木) 08:11:38.37

>>810
検索したけど見つからなかった……
リンクある？

**デフォルトの名無しさん** · 2024/02/15(木) 08:17:50.82

[Why I Use Golang In 2024](https://www.youtube.com/watch?v=6gwF8mG3UUY)

**デフォルトの名無しさん** · 2024/02/15(木) 08:19:40.94

>>812
サンクス。
家帰ったら見るわ。

**デフォルトの名無しさん** · 2024/02/15(木) 08:48:36.69

>>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、

**デフォルトの名無しさん** · 2024/02/15(木) 09:52:51.93

>>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。

**デフォルトの名無しさん** · 2024/02/15(木) 09:55:25.99

エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？

**デフォルトの名無しさん** · 2024/02/15(木) 10:07:56.04

>>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。

**デフォルトの名無しさん** · 2024/02/15(木) 10:11:47.35

C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる

**デフォルトの名無しさん** · 2024/02/15(木) 10:21:13.40

まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは

Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある

**デフォルトの名無しさん** · 2024/02/15(木) 10:32:36.57

>>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…

**デフォルトの名無しさん** · 2024/02/15(木) 10:37:24.02

「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。

現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。

C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。

Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。

**デフォルトの名無しさん** · 2024/02/15(木) 10:38:37.60

今の時点で使いやすければなんでもいいんだYO

**デフォルトの名無しさん** · 2024/02/15(木) 10:45:22.07

C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま

**デフォルトの名無しさん** · 2024/02/15(木) 11:47:28.36

C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ

**デフォルトの名無しさん** · 2024/02/15(木) 12:02:34.79

>>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法

**デフォルトの名無しさん** · 2024/02/15(木) 14:40:35.94

そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分

**デフォルトの名無しさん** · 2024/02/15(木) 14:47:01.34

サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある

**デフォルトの名無しさん** · 2024/02/15(木) 16:20:13.71

>>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。

**デフォルトの名無しさん** · 2024/02/15(木) 16:46:19.25

>>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね

**デフォルトの名無しさん** · 2024/02/15(木) 16:50:52.01

すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる

**デフォルトの名無しさん** · 2024/02/15(木) 17:21:54.77

>>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない

**デフォルトの名無しさん** · 2024/02/15(木) 17:26:25.25

Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい

**デフォルトの名無しさん** · 2024/02/15(木) 17:31:26.55

Ruby は、Go/Rust/Elixir の3大言語を超えた！
Rust の上昇は止まったか？

Stack Overflow 米国年収。2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5～7 -> 7.3～7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6

**デフォルトの名無しさん** · 2024/02/15(木) 17:35:21.87

>>832 夢見てないで現実見ては？
https://active.nikkeibp.co.jp/atcl/act/19/00546/011500001/

**デフォルトの名無しさん** · 2024/02/15(木) 17:41:41.98

>>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草

**デフォルトの名無しさん** · 2024/02/15(木) 17:53:07.04

>>835
Rustインフルエンサーの成れの果てですなw

**デフォルトの名無しさん** · 2024/02/15(木) 18:08:05.70

>>834
せめて用途別のプログラミング順位を挙げてくれ

…単発に言っても無駄か😭

**デフォルトの名無しさん** · 2024/02/15(木) 18:08:23.00

Goは２年も続けられるだろうか

大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら
返されたResultを無視してもコンパイラが警告出さないからやめた
Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに

↓を見て気持ち悪さを感じる人には向かない

file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる

**デフォルトの名無しさん** · 2024/02/15(木) 18:11:15.85

>>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。

起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。

**デフォルトの名無しさん** · 2024/02/15(木) 18:19:47.46

「Go」、2月のTIOBE指標で過去最高8位に
https://japan.zdnet.com/article/35215159/
https://japan.zdnet.com/storage/2024/02/13/0ee0eaf7a75e201ad2ee580740569609/240213_tiobe.png

**デフォルトの名無しさん** · 2024/02/15(木) 18:24:55.60

>>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。

**デフォルトの名無しさん** · 2024/02/15(木) 18:31:33.80

>>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。

**デフォルトの名無しさん** · 2024/02/15(木) 18:34:16.56

>>817
これはごもっともな意見
50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる
それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題

**デフォルトの名無しさん** · 2024/02/15(木) 19:40:03.38

50年後にC++23はサポートされているのだろうか
というかC++は50年後もアップデートしているのだろうか

**デフォルトの名無しさん** · 2024/02/15(木) 19:52:43.98

>>843
cargo fix --edition
のあるRustは至れり尽くせりだよ

**デフォルトの名無しさん** · 2024/02/15(木) 20:00:49.77

>>844
既にC++17とC++20で以前導入の機能の削除が大量に行われている

**デフォルトの名無しさん** · 2024/02/15(木) 20:11:12.94

じゃあもうRustで良いじゃん

**デフォルトの名無しさん** · 2024/02/15(木) 20:27:48.49

CになかったC++の機能は削除してもチューリング完全が保証される
逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター

**デフォルトの名無しさん** · 2024/02/15(木) 22:27:00.96

>>840
Kotlinが上がってきてるのうれしい
Fortranも上がってるのはなぜだ

**デフォルトの名無しさん** · 2024/02/15(木) 22:56:46.83

C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。
たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。
基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。
実質的には Rust のエディションみたいなことにはなってるんだよなあ。

**デフォルトの名無しさん** · 2024/02/15(木) 23:13:05.86

llvmも実装はc++だし。

**デフォルトの名無しさん** · 2024/02/15(木) 23:33:02.83

>>850
Rustは必ずeditionを明示しないといけないから
あるソースコードがどのeditionなら確実に動くのか明確にわかる
そしてそのeditionを指定してコンパイルも通り実行もできる

しかしC++は当初のC++11に従いコンパイルできて動いていたものが
今はC++11の機能のいくつかは削除されてしまっているために

**デフォルトの名無しさん** · 2024/02/15(木) 23:44:16.83

>>852
C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが

**デフォルトの名無しさん** · 2024/02/15(木) 23:57:58.06

一般人と同等の読解力を複オジに期待しないこと

**デフォルトの名無しさん** · 2024/02/16(金) 01:17:00.51

cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ
勉強になるわ〜

**デフォルトの名無しさん** · 2024/02/16(金) 02:58:58.82

>>853
名前が同じならなんでも良い…… ってこと！？

**デフォルトの名無しさん** · 2024/02/16(金) 05:29:44.45

>>856
「規格が同じなら」ということだよ。

c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。