今日は皮膚科に行ったり

diary

game

昨晩はゴッドフィールドをプレイしていた。ルールを大凡把握できた。

APEXをインストールした。チュートリアルを終えた。

dermatology

午前中に皮膚科に行った。

ステロイド治療をすることになった。かなり即効性がある。

long nap

五時間昼寝していた。

mercari

ウェブポンでダブった製品をメルカリに出品。

そのコラボ相手の人気はそれほど高くないので、売れる見込みは少ないが、 市場価値としてこうあってほしい金額で出しておく。

ウェブポンの場合、転売という表現はあまり該当しない。ああいった謎の景品の場合、こうでもしないと価値が定まらない。

あと、反応を見ていると、コラボ相手のファン層がメルカリとか転売とかにすごく嫌な感情を抱き、それが先行し過ぎている人がちらほら見えた。 それはその層特有ではなく、広くそういうものなのかもしれない。 (ファン心理として認められないものを売ることがあるのは確か。例えばサイン色紙とか。)

そういった反応を頭が悪いというつもりはないし、転売は良い行為だと両手を上げるわけでもない。 ただ、市場に出回る機会すらないようなコラボ商品という物の価値はとてつもなく低いか、とてつもなく高いかで、つまり値段が付けられないものであり、結局、そのコラボ相手の価値を測れないものであることを示してしまう。

今日の勉強

rust

TRPL pp.216-225

関数のライフタイム注釈の書き方

fn function_name <'a> (x: &'a t, y: &'a t) -> &'a t {
    ...
}

コンパイラに型注釈が教えること:

いかなる値のライフタイムも変更していない。 むしろ借用チェッカーはこれらの制約を守らない値をすべて拒否するべきと指定。 引数のうち小さいほうに等しい具体的なライフタイムになるので、無効になる可能性があるので、その場合は拒否する。

関数は正確な生存期間を知る必要はなく、何らかのスコープが'aに代替され、このシグニチャを満足することだけを知っている必要がある。

手動でライフタイム注釈をする必要がある理由

構造体にライフタイム

構造体に参照を保持させるには、ライフタイム注釈をつける必要がある

struct StructName <'a> {
    field: &'a t
}

この注釈は、StructNameのインスタンスがフィールドに保持している参照よりも長生きしないことを意味する。

ライフタイム省略規則

ライフタイム注釈なしでコンパイルできるケースは歴史的な経緯による

ライフタイム省略規則:

用語:

3つの規則。上から順に適用される。

  1. 参照である各引数は、独自のライフタイム引数を得る
  2. 1つだけ入力ライフタイム引数があるなら、そのライフタイムを全ての出力ライフタイム引数に代入する
  3. 複数の入力ライフタイム引数があるが、メソッドなのでそのうち一つが& self&mut selfなので、selfのライフタイムが全出力ライフタイム引数に代入される

メソッドシグニチャのライフタイム引数

ジェネリックな型引数の場合と同じ記法

impl <'a> StructName <'a> {
    ...
}

‘static

注意: エラーメッセージで'staticライフタイムの仕様を提言されても、本当に全期間生きてほしいかどうかを考慮せよ

なぜならほとんどの場合、その問題は以下のいずれかである。