反論ってわけじゃないですけど、(&)が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 そうですねぇ、究極的には好みの問題、極端に言えばそれこそ"宗教"的な話になってくると思います。演算子オーバーロードや暗黙の型変換をどこまで認めるかのラインは難しいですよね。
もっとも、JavaScriptのほうは型変換の問題というより、変数そのものには静的な型がないし決めようがない言語仕様の限界という感じがしますが……