Stabilize associated type bounds (RFC 2289) by compiler-errors · Pull Request #122055 · rust-lang/rust
https://github.com/rust-lang/rust/pull/122055
おお、mergeされている
Stabilize associated type bounds (RFC 2289) by compiler-errors · Pull Request #122055 · rust-lang/rust
https://github.com/rust-lang/rust/pull/122055
おお、mergeされている
しかしまあ、tracking issueを購読していてもstabilization PRの存在にすら気付かないままFCPが終わっていがちなのをどうにかしたいな
MastodonからMisskeyアカウントをフォローしていない、避けている理由としてどんなものがありますか？（複数回答）
候補に理由がある場合はその他を選んで返信で追加してください。
仮に文脈を掴めない投稿が流れてきた場合にそれがローカル限定投稿絡みなのか否かを考えるのが面倒そうだから、寄り合い所帯のMisskeyインスタンスとその他の実装の両方にアカウントを持っている人たちについては後者を優先してフォローしているところがある
フォローする前に最低限タイムラインの雰囲気を確認するのは大前提として、それでも可能性を排除できない以上は思考にかかる負荷としては同じなので
RFC 2119の各種キーワード（`MUST`/`SHOULD`/`MAY`/etc.）は定義の明瞭さの割に雰囲気で使われがちな用語だと思っている
普段は陽気なアルマーさんがふと見せるお淑やかさといった趣でとても良い
Threads has entered the fediverse - Engineering at Meta
https://engineering.fb.com/2024/03/21/networking-traffic/threads-has-entered-the-fediverse/
> Misskey created its own solution with its `_misskey_quote` property, which builds on FEP-e232.
これは逆で、確かFEP-e232の方がMisskeyの引用機能の一般化なのであって、その枠組みで引用機能を実現している各種実装が慣習的にlink relation typeとして先行実装であるMisskeyの`misskey:_misskey_quote`のURIを流用しているという経緯のはずだよね
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Mastodonが引用機能を実装すれば他の実装の表現もその方式に収束するのではないかと期待していたけど（<https://github.com/kitsune-soc/kitsune/issues/29#issuecomment-1766449402>）、本当にFEP-e232ベースで実現するつもりなのか。しかもlink relation typeとして`misskey:_misskey_quote`を流用するつもりはないと。良いね
`misskey:_misskey_quote`はlink relation typeのつもりで定義された名前ではないのだから、名前空間を所有しているmisskey-hub.netの所有者の合意を取れない限りはlink relation typeとしては別のものを使うのが筋だというのが個人的な意見なので