range-based for の変更案

プププランドのプリンス RiSK @sscrisk

どれがいいだろう…。 "本の虫: range-based forに対する意見求む" http://cpplover.blogspot.com/2011/02/range-based-for.html

普通のC++使い、銀天すばる @SubaruG

観てる： 本の虫: range-based forに対する意見求む http://t.co/MWL1XOg

普通のC++使い、銀天すばる @SubaruG

ADLは明らかに邪悪だし、メンバ関数を使うのがいいかもしれんにゃー。

普通のC++使い、銀天すばる @SubaruG

ただ、その場合は配列の扱いをどうするかを考える必要がある。規格で配列は例外のルールを作るべきか、それとも標準ライブラリにアダプタを用意するか、ですね。

プププランドのプリンス RiSK @sscrisk

案4はユーザにとっても言語にとってもとてもシンプルだと思う。でも，アダプタを書くだけで本当に全てのケースに対応できるのか分からない。(他の案もそういう意味では分からないんだけど)

隅須正昭 @nagoya313

ADLが邪悪ってのは、よく分からん衝突がうざいからってことでいいのかね

隅須正昭 @nagoya313

まぁルックアップとかたまに物凄く分かりにくい邪悪な例とかあるしなぁ。

総長 @krustf

range-based forの記事は風呂入ってから読む。

くっくっkura 🇯🇵🦀 @PG_kura

range-based for の記事、興味深い。

プププランドのプリンス RiSK @sscrisk

確かに… RT: @SubaruG: ただ、その場合は配列の扱いをどうするかを考える必要がある。規格で配列は例外のルールを作るべきか、それとも標準ライブラリにアダプタを用意するか、ですね。

プププランドのプリンス RiSK @sscrisk

アダプタを用意したらそれは std::array になっちゃうし，生配列のメリットが無くなる気もする。

プププランドのプリンス RiSK @sscrisk

シンプルイズベストの原則に従い案4を推す。しかし，配列はどうなるのか謎。

おしょー@実際モチベーションがない @manga_osyo

うーん、range-based for はなかなか興味深いにゃー。ライトなC++er だとやっぱり案1が一番理解しやすいのかにゃー。

くっくっkura 🇯🇵🦀 @PG_kura

既存コードが ADL ありきで動いている以上、ADL のサポートを将来外すという選択はそもそも採れない..んじゃないかな。

Usagi Ito 👩‍💻 High-tech Hermit 🧙‍♀️ @usagi_network

本の虫: range-based forに対する意見求む http://t.co/RL0g0tG ← 案4がいいに賛同。ADLの邪悪はさておくにしても、簡潔で明瞭で使い易く、また他の案に対して言語仕様の学習コストも考慮するにデメリットもない

ロイン @lowwin_bzn

range based forはAdaptorが一番しっくりくるなぁ

くっくっkura 🇯🇵🦀 @PG_kura

あー、違うか。range-based for に限定して ADL を外す可能性が残っているということか。

にゃははー仙人 @Flast_RO

range based forからADLを消したところで結局ADLは残ってるわけだし案１かfall-backはあっていいと思うんだけどな

普通のC++使い、銀天すばる @SubaruG

あ、ちなみに現行では、 <iterator> に配列に対して特殊化された begin, end が定義されてます。

にゃははー仙人 @Flast_RO

メンバはなぁ・・・　やっぱりrangeっていうものを明確した上でrequirementsを書かないと

にゃははー仙人 @Flast_RO

多分現状is_iterator<T>メタ関数を書くとしたらstd::iterator_traits<T>::iterator_tagが定義されてるかってことだろうけどis_range<T>を書くとしたら・・・ってなってしまうのが良くない

おしょー@実際モチベーションがない @manga_osyo

個人的には案3…かなぁ。

総長 @krustf

確かにADLはこの場合邪魔でしかない気がするので案4が良いかなあ、とは思った。個人的には案2が良い気もしたけどSTLテンプレートの特殊化はなあ。

普通のC++使い、銀天すばる @SubaruG

ちなみに現行の規格において <iterator> に定義された、コンテナに対する begin, end は、 perfect forward を使った template<class T> some_type begin( T&& x ); がある場合、そちらが優先される筈。

おしょー@実際モチベーションがない @manga_osyo

しかし、ユーザ側に選択肢を増やすのもなんかあれな気がする。複数定義した場合に混乱しやすいし。ぐぬぬ……。