反論ってわけじゃないですけど、(&)がVBにおいてはbit AND演算として用いられない(一意的な演算子)であればまだ良いんですが、(話がこんがらがりそうなので、スレッドを分けます) #fedibird
QT: https://fedibird.com/@the_kwa/112496732905208325 [参照]
@opaupafz2 完全に横道ではありますが、VBの&演算子については心配ありません。
VBでの&は文字列同士のみに定義されていて、それどころか前後の型を文字列に拡大変換しようとするぐらい文字列志向の演算子です。
つまり、&を使った場合、くっつけた文字列が返るか、ダメなら型変換エラーになります。
ちなみに、VBのbit演算は「And」演算子です。「And」演算子にはBoolean演算のパターンもありますが、今ではBooleanには「AndAlso」演算子を使うのが主流ですから、気にすることはないでしょう。
……と、ここまで書いた上でアレなんですが、現在のVBには演算子のオーバーロードがあるため、演算子前後の型を完全に把握していない限り、そのコードから何が起こるかは結局確定できなかったりします(台無し)
@the_kwa まったく別の使い道をするような演算子オーバーロードをする人が、いるとは思いたくないですね・・・(趣味ならまだしも、実用とかで使われたら・・・ )
たとえばC++やPythonのように型エラーになるなら演算子オーバーロードとかはまだ良いんですけど、中には、片方の型が異なると、暗黙で型変換をしちゃうような言語があるんですよ・・・
(ちなみに余談ですが、演算子オーバーロードの例で言うと、C++の(<<)、(>>)も主観ですが、かなり変なオーバーロードをしていると思います(公式))
@opaupafz2 おそらくJavaやらそのあたりのことを念頭においてのことだと思うのですけど、あの文字列型に合わせていく挙動、個人的にはいうほど違和感ないのですよね。
数値を起点に考えるとWhy!?!?!??!?になるのも理解できるのですが、「Stringクラスに【数値型との間での拡大変換&演算子オーバーロード】が定義されている」と考えるとめちゃくちゃ素直な挙動なのですよ。
@the_kwa 結局のところ、演算子を別々にしたうえで型変換するならわかるのですが、オーバーロードをしたうえであのような挙動になっているのが、まぁ最終的には主観になってしまうんですが、自分にマッチしていないんですよ。
あと経験上、暗黙型変換に頼ったコードはバグの原因になりやすいので、できれば型エラーになってほしいなぁというのが個人的なところです
@opaupafz2 あ、はい、さんざん引っ掻き回した上で言うのもあれですが、記事に関しては承知しております……(なのでBTしたのちリンクも参照もなしに空リプしてました)
変数展開を用いて云々に関しては、もう完全にまっさらな新しい言語でも作らない限りどうしようもなくてしょうがないところですね……。理想ばかりを謳って目の前にある古いコードが動かないような処理系などなんの役にも立ちませんし……。