Qiita 7 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2025/09/13(土) 12:24:07.83

Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)

https://qiita.com/

Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。

https://internet.watch.impress.co.jp/docs/news/1025972.html

前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/
Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/
Qiita 4 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1705486836/
Qiita 5 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1717651046/
Qiita 6 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1739527246/

**デフォルトの名無しさん** · 2025/09/23(火) 15:33:33.09

>>64
一見すると素人には閉区間が便利に見えてしまうけどそのような複雑化する害が多すぎるんだよな
プログラミング言語としては半開区間が最適だ

**デフォルトの名無しさん** · 2025/09/23(火) 17:38:31.18

IDコロコロ君の投稿を容易に見分けられるようになってしまい残念な気持ち。

**デフォルトの名無しさん** · 2025/09/23(火) 19:08:43.70

>>60
半開区間イテレータはゼロコスト抽象化が可能だけど、
閉区間イテレータはその仕様上どうしても枯渇フラグが別途必要となるため、
データサイズの増大とコード実行が遅くなってしまうからね。
閉区間イテレータは効率を求める場面ではタブーと教えるしかないよ。

**デフォルトの名無しさん** · 2025/09/23(火) 19:13:50.59

>>69
Rustはもともと効率のいい半開区間イテレータ「..」しかなくて、「..」以外の仕様でも半開区間が採用されているため、間違えることがないようにできているよ。
動作が遅くてもいいから欲しいとの要望により、閉区間イテレータ「..=」を後から追加したんだよ。
速度を気にする場所でこの変な記号「..=」を使うのは要注意と覚えれば大丈夫。

**デフォルトの名無しさん** · 2025/09/24(水) 04:44:51.44

歴史的な事情で対称性の悪い表記が存在するのって（その歴史を知らないと納得できないから）負の遺産だよね。

**デフォルトの名無しさん** · 2025/09/24(水) 09:37:45.93

古い言語は仕方ないね
新たな言語を作るならば歴史的な知見で誰もが半開区間ベースの言語仕様にするでしょう
①プログラムを書く上で便利　理由>>64
②実行効率も良い　理由>>74

**デフォルトの名無しさん** · 2025/09/25(木) 07:39:21.36

Pythonのrange(1,5)も1,2,3,4を意味する半開区間だよ

**デフォルトの名無しさん** · 2025/09/25(木) 08:04:45.13

半開区間と閉区間の両方をサポートしてて紛らわしい表記になってるのが残念という話が理解できない人かな

**デフォルトの名無しさん** · 2025/09/25(木) 10:55:22.03

Rustみたいに標準ライブラリ全体の仕様を半開区間で統一すれば間違えることもなく悩まずに済むのに

**デフォルトの名無しさん** · 2025/09/25(木) 11:16:52.45

要らない..=をサポートしてしまった為に糞化してしまったRust哀れ

**デフォルトの名無しさん** · 2025/09/25(木) 11:29:57.30

>>81
糞化って何？
意味がわからない

**デフォルトの名無しさん** · 2025/09/26(金) 10:22:57.69

確かに元から糞なものが糞化とは腹が痛い

**デフォルトの名無しさん** · 2025/09/26(金) 12:42:08.13

>>82
「糞化って何？」って何？
意味がわからない
元から糞なものが糞になって糞化したと言っても意味が通る

**デフォルトの名無しさん** · 2025/09/26(金) 16:46:57.32

>>82
ウンコになったってことだよ

**デフォルトの名無しさん** · 2025/09/26(金) 20:33:46.74

>>64
それよりもっと重要なことが抜けてるぞ
Pascal方式で避けられないそれら+1や-1がRust方式では不要となるだけでなく
Rust方式では長さ0を特別扱いせずに自然に扱えることが最大の特徴

Rust方式は長さnがstart..(start + n)であるため
長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える

Pascal方式は長さnがstart..(start + n -1)であるため
長さ0はstart..(start -1)になり左右逆転してしまう
そのためこの不格好な逆転状態を長さ0とみなして扱うか
場合分けして長さ0を扱わないようにするか
場合分けして長さ0の時にnullとかnilとか空リストなど特別扱いする形になる

**デフォルトの名無しさん** · 2025/09/27(土) 00:25:32.78

＞長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える
　
長さ0を表現するのにstartが具体的な値持ってて自然てどういう理屈?

**デフォルトの名無しさん** · 2025/09/27(土) 00:31:44.56

>>87
長さ1や長さ2がstart違ってあちこちにあるように
長さ0もstart違ってあちこちに存在する

**デフォルトの名無しさん** · 2025/09/27(土) 00:43:10.07

>>88
Pascalでstartの違う長さ0表して便利な例挙げてみて

**デフォルトの名無しさん** · 2025/09/27(土) 00:55:46.18

>>87
Rustの..は性質の良い半開区間なので、
例えばstart..endを途中のmiddleの位置で分割すると、start..middleとmiddle..endの二つに綺麗に分かれる性質も持っているよ。
そしてそのmiddleの決定算出結果が処理内容や処理状況によっては、たまたまstartと一致することも出てくる。
その時、start..middleとmiddle..endの二つは、start..startとstart..endの二つに分かれて前者は長さ0になるね。
Rustでのプログラミングでも実際にこれはよく起きるよ。

**デフォルトの名無しさん** · 2025/09/27(土) 01:43:57.58

>>90
区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。

**デフォルトの名無しさん** · 2025/09/27(土) 01:48:32.95

閉区間と半開区間のどちらにメリットがある場合もあり、Rustも閉区間をサポートしてるのに半開区間のみを持ち上げてるのは見識が狭いな。

**デフォルトの名無しさん** · 2025/09/27(土) 02:17:11.42

>>91
区間には必ずスタート位置を伴いますね。
そこから長さが2だったり長さが1だったり長さが0だったりするわけです。
長さ0の時だけスタート位置が無いのは不自然でしょう。

>>92
良い性質を備えていてメリットがあるのは半開区間でしょう。
Rustの標準APIは区間分割split_atなどでも半開区間を前提として処理されます。

**デフォルトの名無しさん** · 2025/09/27(土) 02:20:12.82

『fast inverse square root (高速逆平方根) のようなトリックまとめ』
　
未定義動作コードの見本市みたいな記事。
C言語知りませんアピールか。

**デフォルトの名無しさん** · 2025/09/27(土) 07:25:01.25

C言語なんて動きゃいいんだよ動きゃ

**デフォルトの名無しさん** · 2025/09/27(土) 08:53:18.36

動きゃいいんだよ動きゃなんて言語でカーネルを作ってほしくない

**デフォルトの名無しさん** · 2025/09/27(土) 12:15:10.22

古いのから新しいのまであらゆるCPUで動きゃいいんだよ動きゃ

**デフォルトの名無しさん** · 2025/09/27(土) 13:57:37.59

＞動きゃいいんだよ動きゃ
　
動くかわからん未定義動作のコードにこういうこと言う奴は馬鹿

**デフォルトの名無しさん** · 2025/09/27(土) 16:57:30.37

特定のCPU/GPU環境と断ってる
C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え

**デフォルトの名無しさん** · 2025/09/27(土) 17:02:10.01

CとC++はこの手の気持ち悪いオジサン湧くからほんと無理

**デフォルトの名無しさん** · 2025/09/27(土) 17:19:12.43

>>94
その記事「特定のCPU/GPU環境」を書かないのが片手落ちやな

**デフォルトの名無しさん** · 2025/09/27(土) 20:09:28.90

>>100
直前に出たRustとC/C++の違いは
C/C++はお前のようなバカにも理解できるように分かりやすく話してあげてることだぞ

**デフォルトの名無しさん** · 2025/09/27(土) 20:36:16.39

>>77
半開区間で書く方が便利な場合があることを誰も否定してはいないだろう。一方、閉区間で
書く方が便利な場合もある。例えば1からnまでの自然数を表示したいときがそうだが、
半開区間しかないPythonではfor i in range(1, n + 1): print(i)なんてひねくれた書き方を
強要されるし効率も悪い（Pythonで効率を云々しても意味ないが）。だから、半開区間と
閉区間の両方の記法を提供するのが良い。

半開区間を表すのに左右対称な..を使うのは紛らわしいので不適切。Pascalなどで..で閉区間を
表す慣用が定着していたにもかかわらず、..で半開区間を表す愚行を最初にやらかしたのはDか。
その前車の轍をC#, Go, Rustが踏んでしまった。特に.NET兄弟のF#とPowerShellが..を閉区間で
既に使っていたのにC#が半開区間を表すのに..を導入してしまったのは大きな誤りだった。
Dはほぼ死語と化したから、..で半開区間を表す不適切な記法も消え去るべきだな。

**デフォルトの名無しさん** · 2025/09/27(土) 20:44:14.86

閉区間ｲﾗﾈｴ

**デフォルトの名無しさん** · 2025/09/27(土) 21:04:56.86

閉区間を表す記号を用意すべきかどうかについてはそれぞれ考え方の違いがあるんだなと思うが、.. は左右対称だから閉区間にすべきというのは正直よく分からん理由付けだわ。Pascalだってそんな理由で .. を閉区間の記号にしたわけではないと思うが。

**デフォルトの名無しさん** · 2025/09/27(土) 21:10:34.65

>>103
多くの言語が半開区間を基本として扱っている理由は、半開区間だけが優れた性質を備えていてプログラミングに適しているためだよ。
半開区間だけが、start～endは長さ start - endを示し、startから長さnはstart～(start + n)になり、長さ0をstart～startで示すことができ、start～endをstart～middleとmiddle～endの2つに分割できる。
間違えた古い言語に習うことなく、半開区間をstart:endやstart..endなど簡素に記述するそれらの言語C# Go Rust Pythonなどが正しいよ。
JavaScriptもarr.slice(start, end)は半開区間であり、半開区間を基本とする言語が多数派だね。

**デフォルトの名無しさん** · 2025/09/27(土) 21:12:07.66

＞特定のCPU/GPU環境と断ってる
＞C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
　
記事のコードがダメのはC言語の仕様として未定義動作と規定されてることをやってるからで特定CPU関係ないよ。

**デフォルトの名無しさん** · 2025/09/27(土) 21:17:11.52

>>105
数学での表記も閉区間と開区間の記号は左右対称で、半開区間は左右非対称。

　閉区間[a, b]　開区間(a, b)　左半開区間(a, b]　右半開区間[a, b)

..は閉区間にしか見えない。右半開区間は..<か..~にすべきなのにたった1文字をケチって
バグを呼び込むのは愚行としか言いようがない。

>>106
for i in range(1, n + 1): print(i)がプログラミングに適しているとでも?

**デフォルトの名無しさん** · 2025/09/27(土) 21:29:49.40

>>108
それら現在メジャーな各言語の、range(srart, end)もslice(start, end)もstart:endもstart..endも全て半開区間を意味しているため、間違える人はいなくて、初心者もすぐ理解して誰も困っていないよ。
0からn個がrange(0, n)
1からn個がrange(1, n + 1)
2からn個がrange(2, n + 2)
とてもわかりやすくなっているね。

**デフォルトの名無しさん** · 2025/09/27(土) 21:50:13.15

>>109
そんなものがわかりやすいわけないだろ。2からnまでの自然数を表示したい場合にはn - 1個だから
右端はn - 1 + 2 = n + 1でrange(2, n + 1)なんていちいち計算するのかw

mからn個ならC#のEnuemerable.Rangeが分かりやすい。

0からn個がEnuemerable.Range(0, n)
1からn個がEnuemerable.Range(1, n)
2からn個がEnuemerable.Range(2, n)

理解していなくて間違えるのではなく、理解しているが左右対称の見た目につられてうっかり間違えやすい。
それなのにわずか1文字をケチるのは愚行。

**デフォルトの名無しさん** · 2025/09/27(土) 21:54:38.07

① 多用される半開区間を少ない記号で書けるよう .. を半開区間の記号にしました。
② Pascal以来の伝統を重視して .. を閉区間の記号にしました。
③ 閉区間の記号は数学記号に倣って左右対称であるべきなので .. を閉区間の記号にしました。

自分は、説得力を感じる度合いとしては① >= ② >>> ③ かな。③ははっきり言ってパラノイアの戯言レベルの物言いにしか思えない。

また、半開区間の記号を ..< とか ..～のような冗長で読みにくい記号にする前提なら、それが .. を閉区間の記号にしたくない最大の理由になるかな。Pascalのように閉区間の記号しか設けていないのなら仕方ないが、開区間と閉区間の記号を両方用意するなら、開区間の記号の方をスッキリした記号にして欲しい。Rubyの .. と... で許容範囲ギリギリくらい。

**デフォルトの名無しさん** · 2025/09/27(土) 22:08:37.36

>>111
意味がある記号を書くのを冗長とは言わない。消すのを愚行という。Pythonが意味がある{}を消したのも愚行。

そんなに文字数を減らしたいなら半開区間の記号を.~にしたらどうか。

**デフォルトの名無しさん** · 2025/09/27(土) 22:45:20.51

> 閉区間[a, b]　開区間(a, b)　左半開区間(a, b]　右半開区間[a, b)

これでいうとrust方式は一貫性の点で詰んでないか？
閉区間[a, b] a..=b
開区間(a, b) ???
右半開区間[a, b) a..b
左半開区間(a, b] ???

pascal方式だと以下のように拡張しうる余地がある
閉区間[a, b] a..b
開区間(a, b) a<..<b
右半開区間[a, b) a..<b
左半開区間(a, b] a<..b

**デフォルトの名無しさん** · 2025/09/27(土) 23:23:15.70

このスレでパラノイアの妄執を開陳されてもなぁ。
..< とか　<..< とかで「一貫してるぞ、わーい」って喜べるの貴方くらいだよ。

**デフォルトの名無しさん** · 2025/09/27(土) 23:40:53.38

Rustは非常にシンプルで
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない

**デフォルトの名無しさん** · 2025/09/28(日) 00:57:38.05

>>114
108と113は別人だから、少なくとも2人はいるな。左右対称の..が閉区間に見えるのが自然な感覚なのに、
それに反して半開区間を割り当てているのが正解だなんて言い張っている方がカルト教団だよ。

数学に固執する本当のパラノイアはJuliaの作者だな。文字列連結演算子には+を使うのが自然な感覚なのに、
数学では+は可換演算子だから不適切で、*は非可換演算子の場合もある（例：行列演算）から*を使うのが
適切と言い張っている。

**デフォルトの名無しさん** · 2025/09/28(日) 01:05:52.83

>>115
合理的だな

**デフォルトの名無しさん** · 2025/09/28(日) 01:15:35.68

>>115
<は右の値を含まないことが一目瞭然だが、..はそうではなく右の値を含むようにしか見えない。

**デフォルトの名無しさん** · 2025/09/28(日) 01:22:45.65

対称なstart:endで半開区間を示す言語も多いけどそれには文句をつけずに
なぜかstart..endだけに文句をつけているから単なるキチガイだと思う

**デフォルトの名無しさん** · 2025/09/28(日) 01:28:15.16

>>119
:で半開区間を表す言語なんてあったっけ?

**デフォルトの名無しさん** · 2025/09/28(日) 01:34:38.77

マイクロソフトまでもがC#8.0でついに導入した範囲構文を
「start..end」と記述して半開区間を意味することにしちゃったからね
半開区間が多数派だよ

**デフォルトの名無しさん** · 2025/09/28(日) 02:06:41.24

>>102
気持ち悪いから絡んでくんなRust信者

**デフォルトの名無しさん** · 2025/09/28(日) 02:22:58.32

現在メジャーに使われているプログラミング言語で調査してみた
start:endやstart..endと書いた時にどちらを意味するか？
【閉区間】Ruby
【半開区間】C# Go Python Rust

**デフォルトの名無しさん** · 2025/09/28(日) 03:25:05.02

Rubyでも半開区間はstart...endと左右対称な形で書くよ
「半開区間を左右対称な形に記述するな！」と主張してる>>108は頭おかしい

**デフォルトの名無しさん** · 2025/09/28(日) 06:17:53.02

彼の主張する
・閉区間はPascalと同じstart..end
・半開区間は左右非対称な記号列
を満たす言語はそもそも存在するの？

Pascal自体は半開区間が存在しないから満たさない
>>123の各言語はRubyを含めて半開区間が左右対称な記号列

**デフォルトの名無しさん** · 2025/09/28(日) 06:43:10.95

>>91
>>>90
>区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。

これすげえな
多重ループすら見たことないのか

**デフォルトの名無しさん** · 2025/09/28(日) 08:23:09.99

ここの住人もQiitaと同レベルだよな

**デフォルトの名無しさん** · 2025/09/28(日) 08:34:28.79

争いは同じレベルの者同士でしか発生しないからな

**デフォルトの名無しさん** · 2025/09/28(日) 13:02:57.89

現行の言語のデザインに何も疑問を持たないのはそれだけの人

**デフォルトの名無しさん** · 2025/09/28(日) 13:46:21.84

>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が

**デフォルトの名無しさん** · 2025/09/28(日) 13:49:09.56

全てのインデックスを過不足なく処理することの需要が最も大きいんだから
その用法の記述が最もシンプルになるべき
情報圧縮なんて聞いたことすら無いから登場頻度の多いものに少ないビット数を割り当てるなんて聞いたことすらないんだろう
そこで数学ガーとか言い出すのは間違いなく数学も出来ない低学歴無職

**デフォルトの名無しさん** · 2025/09/28(日) 14:09:14.21

どの言語も範囲指定は半開区間が基本だから困ってる人はいないだろ
半開区間を左右非対称な記法にしなければ閉区間と誤解する人なんていない

**デフォルトの名無しさん** · 2025/09/28(日) 15:14:07.50

左右対称とかバカしかやらない
インデックスを過不足なく処理したいのに閉区間にされたら端の重複を除外する処理が追加で必要になる
知能が存在しないからそんな妄想ができる
間違いなく中学レベルの数学の証明すらできない脳障害の妄想
バカすぎて数学が出来なくて悔しかったので
思考力の無さを誤魔化すために「数学原理主義」に立つことで自分は数学ができるんだと言い聞かせるという低学歴しぐさ

**デフォルトの名無しさん** · 2025/09/28(日) 16:40:35.56

急所突かれて発狂ｗ

**デフォルトの名無しさん** · 2025/09/28(日) 17:11:35.80

Pythonのlist[start:end]は半開区間でstartを含んでendは含まないけど
これを「閉区間と勘違いするから左右非対称なlist[start:<end]に変更しろ」と要求してるのかよwww

**デフォルトの名無しさん** · 2025/09/28(日) 17:32:21.30

半開区間と閉区間の両方をサポートする言語と半開区間か閉区間のどちらかしかサポートしない言語との区別がつかない>>135は馬鹿だな

**デフォルトの名無しさん** · 2025/09/28(日) 18:01:58.35

なるほど
両方サポートしていれば閉区間の指定方法が別途あるから確実に両者の区別がついて混乱しないってことか

**デフォルトの名無しさん** · 2025/09/28(日) 18:33:01.36

そんなもん使い道が無い

**デフォルトの名無しさん** · 2025/09/28(日) 18:33:42.56

そもそもマシンコードに区間なんて存在しないんだから
内部的に２つの条件判断に置き換えるだけ
サポートしてるかどうかなど全く無意味

**デフォルトの名無しさん** · 2025/09/28(日) 18:34:40.04

しかもいまだにAIエージェントでコーディングしてない時点でヤバすぎる
やるのはエージェントだからタイピングの手間とか見やすさとかそんなものは存在しない
仕事してない無職の妄想

**デフォルトの名無しさん** · 2025/09/28(日) 18:58:05.58

AIにとっては左右非対称であることが重要
左右対称なら閉区間だと思い込む可能性が高い

**デフォルトの名無しさん** · 2025/09/28(日) 19:03:52.16

>>141
無職の妄想は意味ないよ

**デフォルトの名無しさん** · 2025/09/28(日) 19:04:21.97

>>141
証拠出せよ
出せないなら自殺して詫びろ

**デフォルトの名無しさん** · 2025/09/28(日) 19:17:29.37

そもそも人間は左右対称だと閉区間と思い込むもんなの？
そこからおかしいんじゃないの？

**デフォルトの名無しさん** · 2025/09/28(日) 19:19:06.15

>>144
思い込まない
何の証拠もない中卒の妄想
ソースが無い

**デフォルトの名無しさん** · 2025/09/28(日) 19:21:01.28

話題になり得るのはAIエージェントが取り違えしてないかどうかチェックするためのテストコードをどうやってAIエージェントに漏れなく全ての箇所で書かせるかとかだろ
人間にとっての見やすさなんて無職の自白

**デフォルトの名無しさん** · 2025/09/28(日) 19:28:03.90

区間記号を全てgrepして該当箇所をファイルに書き出して書き込み禁止にし
その該当箇所全てでテストコードを書かことを義務付けてパスしないと認めない指示にするとかだな
記号なんて全くどうでも良い
テストするんだから

**デフォルトの名無しさん** · 2025/09/28(日) 19:29:08.83

区間記号の解釈とテストがどうなっているべきかも.mdに最初に書かせて
それを守ってない行動は全てリバート

**デフォルトの名無しさん** · 2025/09/28(日) 19:38:57.62

現在メジャーに使われているプログラミング言語で調査してみた
半開区間の指定が左右対称か左右非対称か？
【左右対称】C# Go Python Ruby Rust
【左右非対称】Swift

**デフォルトの名無しさん** · 2025/09/28(日) 20:05:41.70

>>139
> そもそもマシンコードに区間なんて存在しないんだから
> 内部的に２つの条件判断に置き換えるだけ

https://godbolt.org/z/q6T916rjW と https://godbolt.org/z/KvxEv7dsq じゃ結構違うと思うが何言ってる?

**デフォルトの名無しさん** · 2025/09/28(日) 20:16:56.42

>>150
だからアセンブラで書けよ無能
どんなマシンコードにコンパイルされるかすら知らねえ猿が吠えんな

**デフォルトの名無しさん** · 2025/09/28(日) 20:25:27.74

>>151
ちょっと何言いたいんだか分からんね。

**デフォルトの名無しさん** · 2025/09/28(日) 20:27:54.00

>>152
アセンブラ書けねえのか無知

**デフォルトの名無しさん** · 2025/09/28(日) 20:28:29.22

>>129
>現行の言語のデザインに何も疑問を持たないのはそれだけの人

>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が

**デフォルトの名無しさん** · 2025/09/28(日) 20:29:19.56

>>152
分からんなら自殺しろ
アセンブラすら知らない猿が吠えんな
最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから
消えろ
この世から

**デフォルトの名無しさん** · 2025/09/28(日) 20:33:56.40

> 最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから

スマホで見て発狂してる可能性もあるかな?

**デフォルトの名無しさん** · 2025/09/28(日) 20:37:44.61

>>156
最適化レベルすら指定してない猿
無職か？

**デフォルトの名無しさん** · 2025/09/28(日) 20:48:48.21

> 最適化レベルすら指定してない猿

指定してる -Copt-level=2 が最適化指示とわからん人かな?

**デフォルトの名無しさん** · 2025/09/28(日) 20:59:03.90

AIって想像以上にアホだぞ

**デフォルトの名無しさん** · 2025/09/28(日) 21:12:11.28

>>124
Rubyは閉区間と半開区間の両方を提供したことと、閉区間に左右対称な..を採用したことでは
賢明だったが、半開区間に左右対称な...を採用したのは惜しい誤りだったな。..とも判別しづらいし。
..<か..~にすべきだった。

>>125
>>66にも書いたように、Swiftでは閉区間は...で左右対称、半開区間は..<で左右非対称だよ。
閉区間はPascalの..より.が1つ多い...だが、左右対称という点では共通する。

増分も指定できるように拡張することを見越すと、半開区間には..<より..~の方が適している。
開始値..増分..<終了値だと増分が負のとき変な感じがするが、開始値..増分..~終了値ならば
問題ないから。

もっともSwiftでは増分指定では記号を使わない。stride(from: 開始値, through: 終了値, by: 増分) の
ように省略不可の名前付き引数を書かせる。そして、名前付き引数だから順不同ということもなく、
この順でしか受け付けない。このようなガチガチの書式で固めたのもバグを防ぐための用心だろう。
Fortran, Juliaでは開始値:終了値:増分だがMATALAB, Octave, Scilabでは開始値:増分:終了値で
順序が異なるため、混同による書き間違えの恐れがあるから。

**デフォルトの名無しさん** · 2025/09/28(日) 21:13:50.83

>>131
>>116に挙げたJuliaの作者じゃないから、数学に合わせること自体に固執しているわけではない。
左右対称な..が閉区間を表すのが自然な感覚で、それに反するのはバグの元だからやめるべきだと
いうのが根源的な理由で、数学はそれに反していない例として挙げたに過ぎない。

人間は機械ではないから見た目に惑わされやすい。機械だけが相手なら半開区間をi!jで表せば
効率が最も良いし、多くの言語では破壊的変更も文法的に不要で好都合なはずだが、人間の
感覚では!は半開区間とは容易に結びつかない（:の変形と見なせば結びつかなくもないが）し、
|とも判別しづらいから不適当。

屁理屈を捏ねて自然な感覚に反することを強制するのは、ギークの村社会のキモい悪習としか
言いようがない。プログラム言語の記法の選定はUI設計の一種なのに、不自然で間違えやすい
記号を採用するのは工学的センスが絶望的にない。UIは美的にも心地良いことに越したことはなく、
その点でも見苦しい略語を多用するRustは落第だな。そもそも名前からして汚らしい。

>>144
基本ラテン文字の大文字全体を'A'..'Z'で表すのが素直な感覚（EBCDICのような化石はこの際
無視して良い）で、'Y'までしか含まないと言い張るのは無理がある。'A'..='Z'は冗長だし、
'A'..'['では何を意図しているかすぐには分からない人が多いだろう。

**デフォルトの名無しさん** · 2025/09/28(日) 21:25:20.44

Rustのイテレータがとてもわかりやすい
【C】i = 0 ; i < n; i++
【Rust】0..n
と
【C】i = 0 ; i <= n; i++
【Rust】0..=n
対応している

**デフォルトの名無しさん** · 2025/09/28(日) 21:32:15.76

>>158
書いてないぞ

**デフォルトの名無しさん** · 2025/09/28(日) 21:38:57.07

>>161
そんな感覚は無いのでお前の負け
ソース無し

**デフォルトの名無しさん** · 2025/09/28(日) 21:43:13.72

>>161
自然なのは左右対称とかどうでもいい猿の妄想じゃなくて
最も使われるものが最もシンプルに書けるという情報理論的効率性な？

**デフォルトの名無しさん** · 2025/09/28(日) 22:05:51.43

>>164
正直に白状しろ。心当たりが全くなくはないはずだ。

C++ STLの.begin()と.end()の組の.end()を書くときにも、もやもやする感覚が常に伴うな。
『リーダブルコード』に、

　プログラミングの命名規約では、包含／排他的範囲にbeginとendを使うことが多い。
　　でも、endは少しあいまいだ。例えば、「本の終盤（the end of the book）を読んでいる」の
　「end」は包含的だ。残念ながら英語には「ちょうど最後の値を超えたところ」を意味する簡潔な
　言葉がない。

と述べられている通り。簡潔な言葉がないなら作れば良かったと思う。例えば、endの次（next）だから
nendとか。無闇に造語すべきではないが、どうしても必要なら作れば良い。bitは成功例だろう。

とは言え、複数の本を本棚に並べ右端の横にブックエンドを置いたとき、.end()は本そのものではなく
ブックエンドだと考えれば、.end()はまあ納得できるから..ほど悪くはなく許容できる。

>>165
誤記予防という機能性を犠牲にしてたった1文字をケチる愚行。第一、閉区間より半開区間の方が頻繁に
使われるという主張も怪しい。作るプログラムによって異なるだろ。

**デフォルトの名無しさん** · 2025/09/28(日) 22:07:15.34

>>166
なんのソースもない中卒の妄想は意味ない
ソースを出せ
出せないなら自殺して詫びろ

**デフォルトの名無しさん** · 2025/09/28(日) 22:08:16.70

>>166
曖昧なことなど一つもない
定義を見れば良いだけ
定義以外の妄想してる時点で中卒無職だと確定する

**デフォルトの名無しさん** · 2025/09/28(日) 22:11:06.36

>>162
従来との対応関係のあることが最も重要なのでそれで正しい

**デフォルトの名無しさん** · 2025/09/28(日) 22:13:10.39

>>166
りーだぶるwwww
こーどwwwww

お前無職だろ？
そんな実績0の無能な猿が書いたゴミを流行りで買ってる時点で無職バレバレ

**デフォルトの名無しさん** · 2025/09/28(日) 22:15:00.74

>>167
低学歴ではないが、低学歴という煽りもここでは意味がないね。プログラム言語なんて小学生でも
分かる程度のものでしかないし、一般的感覚も自然言語と高校までの数学によって形成されるものだから。
そこから乖離した屁理屈をあれこれほざいても、ギークのキモい戯言でしかない。

**デフォルトの名無しさん** · 2025/09/28(日) 22:18:09.06

>>171
ソース出せない妄想と