プログラミング言語 Rust 4【ワッチョイ】 (302レス)
上下前次1-新
抽出解除 レス栞
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
16(2): (ワッチョイ 66e8-AMuz) 2018/01/13(土)10:23 ID:PvY+igkm0(2/2)調 AAS
https://stackoverflow.com/questions/45086595/is-it-considered-a-bad-practice-to-implement-deref-for-newtypes
ぐぐったらこんな議論も。
17(2): (アークセー Sxbd-YNmt) 2018/01/13(土)19:09 ID:zJNsIIn8x(1)調 AAS
>>16の論旨は「MyType<T>は常にVec<T>として扱われても問題ないか?あるならDerefはおすすめしない」だと思うけど、
今回の場合はむしろMyType<T>は特別なことが無い限りVec<T>として使いたいんじゃないの?
18: 9 (ワッチョイ 392d-FSib) 2018/01/13(土)20:15 ID:5hbvxbkG0(1)調 AAS
>>16 読みました
見覚えのあるピンク玉はrust playgroundの中の人でした
「smart_ptrぐらいの同一性がある場合にはDerefが必要だけど
strにDeref<Taget = [u8]>が無いように
Derefだとやりすぎな場合もあるからdelegate構文欲しいよね」
ってなとこでしょうか
strの例は「替わりにas_bytesがあるよ」ということかなと
strとsliceとか他のライブラリを眺めた個人的な結論としては
has_aならAsRef、is_aならBorrowをimplして受ける関数で使い易くしておくのが
Rust的な落とし所なのかなーといった印象です
AsRef, Borrow, Derefの使い分けは宣言的にプログラマの裁量に任されてる感じ
よくよく考えれば自分のコードにもas_xxx, as_xxx_mutが散見されている現状なので
Mytypeにもas_vecを書けばそれでも良かったような気がします
>>17
自分のケースの場合はそもそもMyTypeがいらなくなってしまったもので
Derefはオーバーパワーかなと思ってます
とはいえ smart_ptrのように扱うならDerefが有用ということが
知見として学べたので 大変ありがたかったです
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.018s