Add defmac crate

[qryxip]

• Add defmac
• Add derive_builder
• Add unchecked-index (for "高速化するもの")
• Add tests for the above 3 2 crates
• Update libm (breaking change?)
• Update derive_more (minor change)
• Update euclid (minor change)
• Update im-rc (breaking change (MSRV bumped))
• Update nalgebra (breaking change?)
• Update rand_pcg (minor change)

[statiolake]

Builder パターンを競プロで使う需要はあるのでしょうか...？
ライブラリ作成時と考えてもやはり思い付かないような。

[qryxip]

マラソン時にパラメータが5個10個くらいあるDefaultかつバリデーションを行ないたいstructを

let data = Data {
    cost: 42,
    ..Data::default(),
};
debug_assert!(data.validate());

の代わりに

let data = Data::builder()
    .cost(42)
    .build()
    .unwrap();

と書くことを想定してました。ただまあ..微妙そうですね。builder patternが欲しくなるときってデータを追加するごとに何らかの計算を行ないたいとかrequiredなパラメータがあるけどoptionalなのと合わせると7個を超過するので関数にし難い場合とかなので。

[statiolake]

うーむ...。どれほどのユースケースがあるのか微妙です。

また、 unchecked_index が Safe Rust 内でプログラマが安全性を保証することを要求していますので、競プロ的に多少便利でも非常に Rust 的でない気がしてしまいます。標準にある get_unchecked() 系列と実質的にも同じだと思いますので、導入には少々反対です。 (一応デバッグ時はアサーションが効く点で便利ではあるとは思いますが...)

サーバー側で UB に起因する無意味な判定が出るようなことがあれば、デバッグにも影響しそうです。 (別の箇所をコメントアウトしたら (関係ないのに) テストケースがREしなくなったから、そこに問題があると誤認するなど) 。

[qryxip]

unchecked_index::unchecked_indexの"Safety"は「Readmeの例のようにUncheckedIndex<_>が見える場所全部をunsafeで囲め」と解釈できる?のでこういうのは非推奨な筈です。

let mut xs = vec![0];
let mut xs = unsafe { unchecked_index::unchecked_index(&mut xs) }; // 添字アクセスが速くなるおまじない★
xs[0] += 1;
assert_eq!(xs[1], 1); // oops

あと推奨する使用用途としては『高速化するもの』の冒頭に書かれた通りの正真正銘マラソン専用のcrateとして、危険性を承知した上自己責任で必要最小の部分に適応することですね。マラソンでもない普段のコンテストではその通りメリットよりもデメリットの方が大きいので。

実際このことは周知されていて、C++使いですら通常のコンテストではoperator[]よりもstd::vector::atを用いることが(一部で)推奨されているほどです。なのでunsafe codeの危険性があまりわからない人がマラソンでもない問題に対して濫用するという蓋然性は低いと思います。少なくとも↓よりは。

競技プログラミングにてミュータブルなグローバル変数を使ってみたら書くスピードが上がりそう

[qryxip]

derive_builderについてはbuilder patternの方が嬉しいケースがあまり思い浮かばないので消します..

[qryxip]

これは今考えたのですがdebug modeでチェックすることは高速化のため安全性を『諦める』部分を少しでも小さくしようとする試みではないでしょうか。 (手元にテストケースさえあれば確実に境界違反を発見できる) 逆に[_]::get_unchecked(_mut)を直接使うのに比べてほんの僅かでも安全な選択肢を与えるといった考え方はどうでしょうか?

[statiolake]

個人的な感覚なのかもしれませんが、たとえ Safety に「全て unsafe で囲んでね」と書いてあるとしても、 Rust が保証するメモリ安全性などの条件を Safe Rust 内で犯せてしまう、というのは大きな問題かと思います。逆にプログラマーが意識的に気をつけるべき条件があるようなものを閉じこめるのが unsafe の役割だと思っています。

The need for all of this separation boils down a single fundamental property of Safe Rust:
No matter what, Safe Rust can't cause Undefined Behavior.

(https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html)

マラソンの経験はないので憶測にはなるのですが、基本的に (考察の時間に比してコーディングの) 時間は十分あるものと認識しています。必要があればデバッグ時と本番でチェックの有無を切り替えるような関数を用意することもできるかと思います。通常の競プロのように素早くコードを書き捨てる必要はないと思いますので、マラソンがメインターゲットであるならなおさら不要な気もします。

[qryxip]

基本的に (考察の時間に比してコーディングの) 時間は十分あるものと認識しています。

一日考えたのですがその通りなので削除したいと思います。というかより安全?なAPIのものをmacro_rulesすら無しで簡潔に書けてしまいました。 (unchecked-indexで用いられてないsince 1.28のSliceIndexとsince 1.33のPinを使った)