+ JavaScript の質問用スレッド vol.141 +
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
質問者は !slip:vvvvv を名前欄に、その後は「レス番」＋!slip:vvvvv
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」から解離した議論はよそでやること。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです
■前スレ
+ JavaScript の質問用スレッド vol.140 +
https://mevius.5ch.net/test/read.cgi/hp/1558249632/ 何らかの形でちょっとずつでいいからテンプレ直していこうよ
↓
とりあえずまず>>2以降をバッサリ変えよう >>12
>>1に比べて>>2以降はスレ落ちを防ぐための何人が目にしてるかわからないような低価値テンプレでしょ
>>1を変えるのは慎重にならないといけないし、とりあえず手を付けなくてもいいけど
>>2以降の列挙されているのを整理することは「ちょっと」でしょ >>9
> ライブラリ固有の質問はこちらへ
>>5-7でライブラリ関連のテンプレを入れている矛盾を何とかしてくれ >>14
あっちにライブラリのテンプレが入ってないから
やむをえないでしょう
「そもそもあっちとは遥かに勢いが違う」というのも否めない
それだけ「ライブラリ固有の質問に需要がない」といえるのかも知れない
ただ lodash だと短く書けるという話はチラホラ出てるから
こっちで敢えて lodash 全面禁止する必要性があるかどうか…？ >>4 は多分誰も読んでないから全て削除で良いかと
即死判定は事実上ないから 読んでいる人が殆ど居ないかも知れないが
>>8 は 2 へ繰り上げる方が良いかも 現時点での >>2 の必要性は、私には分からん
要らんという意見が多数を占めるなら、以後削ることになろうかと >>3 の前半も、
「要らん」という意見が多数を占めるなら（以下同文 整理すると
>>2 要らんのと違う？
>>3 前半は要らんのと違う？
後半は >>16
>>4 要らんのと違う？
>>5-7 維持すべきだとおもう
>>8 は2へ繰り上げるべきだとおもう くだらないことをしてるから、いつもどおり参戦したいんだが、
今、個人プロジェクトが架橋に入ってるので、
残念ながら放置。また次回のスレ立て頃に遊びに来るよ >>1 >>8 >>16 の3スレでいい
ちなみに今リンクするならES9.0ではなく10.0ね >>15
> あっちにライブラリのテンプレが入ってないから
なら、あっちのテンプレ整備すればいい >>15で「需要がない」と言っておきながら、
> それだけ「ライブラリ固有の質問に需要がない」といえるのかも知れない
>>22でライブラリ関連のテンプレだけ残そうとする理由は何？
一貫性がなくて、結論だけ読むと、ライブラリ房に見える 現状、ライブラリは自己主張の激しい人が大半なわけで、>>1の趣旨に反する以上は専用スレでいいと思うけど
lodashがいいならシェア1位のjQueryもいいだろ、とか屁理屈こねる人が必ず出てくる >>1
> 質問者は !slip:vvvvv を名前欄に、その後は「レス番」＋!slip:vvvvv
前スレでは「回答者だけ」だったルールが「質問者だけ」に改変した意図を詳しく
https://mevius.5ch.net/test/read.cgi/hp/1558249632/22
公平性を期すなら「両方」に課すべきルールだと思う
まあ、「任意ルールは守られない強制すべき」という結論が前スレで出ているわけだが、性善説でルールを決めたのなら公平にすべき 強制じゃないと効果なしと前スレで散々言われたのに、なぜ強制でなく、しかも質問者に絞ったのか？ 仕様関連で最低限残すべきは、ES2019, HTML Standard, DOM関連ぐらいで、それ以外はFAQのリンク集に追加するぐらいでいい
http://fiddle.jshell.net/vSqKr/44/show/light/
Conpatibilityはcaniuseあたりが妥当か
ライブラリは向こうでやって + JavaScript の質問用スレッド vol.140 +
https://mevius.5ch.net/test/read.cgi/hp/1558249632/22
22 名前：Name_Not_Found (ﾜｯﾁｮｲ 938f-h/tS)[] 投稿日：2019/05/23(木) 08:49:53.51 ID:t2rWukz00
前スレから。
このスレは age 進行でお願いします。
質問者は !slip:vvvvv を名前欄に、その後は「レス番」＋!slip:vvvvv
回答者は !slip:vvvvv を名前欄に
質問者のかたは
1!slip:vvvvv
みたいなかんじで、よろしくお願いいたします。 >>28
jQuery / lodash ともに全面禁止にするべきなの？ 主要ライブラリ列挙は要らんな
それがどんなライブラリなのかの文章がないと紹介にならないし >>33
全面禁止じゃないけど
サポートする範囲としてはES仕様と、Web標準だけというのを明記したほうがいい
特定のライブラリの機能の質問はライブラリスレですること
このライブラリを使わないといけないんですとかいうのは金払って依頼しなさいということになる
あとはパフォーマンスやらブラウザ固有の機能や実装問題も対象外 サポートとか良く分からんし、ココは無償サポートの場でもなし
ブラウザの機能や実装の話が対象外って意味分からん >>39
そこは俺も分からなかった
標準仕様の話だけをしたい(実装の話はしたくない)意図は読み取れるが、それは>>36の好みだろと思った 実際に動くかどうかは二の次ってこと
つまり○○したいんですがどうすれば良いんですか？
Web標準の仕様にはあります。
（まだ実装されてません）
動くかどうかは話をしたくない もうそれならタイトルを変えたほうが良いんじゃねーの？
「JavaScriptとウェブ標準の仕様について語るスレ」にしたほうが良いでしょ
当初のスレの意味と違う話をしたいなら >>41
それはお前が回答する度に前提条件を前置きすればいいんじゃないか？
全体ルールにする意義が分からん >>39,40
WebはWebであってブラウザのためのものではないから
Web標準もブラウザのためだけのものではない
ブラウザはWebのためにあっても、Webがブラウザのためにあるわけではない
Webの仕様から離れて実際ブラウザがどう動くかという話はブラウザスレでやってもらわないと
パフォーマンスの話も、基本的にそれはブラウザという１アプリの話なんだからスレチ
そもそもここはJS単体の質問スレ
だけどこのスレは今Web制作板にあるので外様APIはWeb APIを中心に話すべきということになる
ブラウザの話までは含まれない >>44
ここは「Web制作のJavaScriptスレ」であって「JavaScript仕様スレ」ではないぞ？
仕様の話に限定したいなら、仕様スレでやれ
第一、仕様を理解している人だけが質問対象者なら、今までの質問者は99%アウトだ
質問スレでそんな運用が可能とは思えん これは俺の好みについて言ってるんじゃないよ
テンプレ議論からのこのスレのポリシーについて話してる
Webというものがブラウザのためだけのものでなくなって久しいんだから
基本ポリシーとしてブラウザの話も受け入れるのならば
ブラウザ以外のWeb技術を導入しているプラットフォームの話題も受け入れないとおかしいことになる
俺はそれが実質無理だろうと思ったから、ブラウザも含めてプラットフォームの話は無しにしたほうがいいと言ってるのであって
もしなんでも受け入れてもいいよというのであれば、賛成する
だけどブラウザの話は受け入れるのに、ブラウザよりもスレが盛り上がっていない、
下手したら存在しない他のプラットフォームの質問を専用スレでやれと蹴り出すのはだめだと言っている
俺の好みの話をするならば、立派な外部スレが有るブラウザの話も受け入れるのであれば、
矮小な他プラットフォームは尚更ここで吸収してあげないといけないだろうということ >>45
仕様を理解だとかそういうことは一言も言っていない
Webというものはブラウザのためのものでなくなってから久しい
あとの言いたいことは>>46を読んでくれ Web制作板なんだから、「Web制作上、必要なJavaScript実装」は許容するに決まってるだろ
実装全体を禁止する理由がない > 基本ポリシーとしてブラウザの話も受け入れるのならば
> ブラウザ以外のWeb技術を導入しているプラットフォームの話題も受け入れないとおかしいことになる
意味が分からん
JavaScriptなら受け入れるし、そうでないなら受け入れないんじゃないのか？ >>48
そうやって「実装」必要と抽象的に言えれば勿論そうだが
実際は抽象的な実装というのではなく具体的な話になってくるでしょう？
例えばAとBどちらが高速かという話になったら
質問者がしていていなかった場合であっても話の50%はChromeの実装が今現時点でどうなっているかになるでしょう？
ただこの手の話は仕様ベースであっても>>3のように時が立つと無効になるのだから
パフォーマンスの話というのは大変慎重にしないといけない >>46
> 俺はそれが実質無理だろうと思ったから、ブラウザも含めてプラットフォームの話は無しにしたほうがいいと言ってるのであって
「無理な理由」が秘密主義で説得力皆無なんだけど
「Web技術を導入しているプラットフォーム」も曖昧だし >>51
俺は100スレ以上前からいるが
過去ここで古くはWinメトロの話題からNode上でのStreamの話題や
様々なプラットフォームの質問が足蹴にされてきたのを見てきたから
ここはJSのスレでありJSというのはスクリプト言語であり様々なプラットフォーム上で動く
そしてWebというものも今やそれ自体もプラットフォームであり様々なプラットフォーム上で動く
俺はそういうのを大事にしたいと思ってるが、
実際のところIEやChromeなど特定のプラットフォームがどうこうの話ばかり
勿論著名実装がサポートしているかどうかの話くらいなら何も問題ないと思ってるが
それ以上に各実装の性質の踏み込む話、
そういう限定されたテーマというのはJSを「自ら学ぶ」ためというよりも
限定されればされるほど、今動けばいい「制作依頼」に近くなると思っているので
できるだけ普遍的なスレにしたいとは思ってる >>52
「俺がやりたいスレ」の話はおなか一杯だから、「実質無理」に触れてくれない？
結局、君の好みの話しにしかなってないと思うんだけど >>53
実質無理というのは足蹴にされてきて
俺が無理矢理そういうのを受け入れようとしたら批判された経験からだ
だから今後もそういう質問が来たらきっと「荒れる」んでしょ？という皮肉だ
だからそうじゃないというならそれをテンプレに明記して欲しい
「Web技術を使うJSの話題であれば何でも受け入れますよ」と
それなら俺の100スレの怨念も浄化される その辺の話になると板分けの問題になってくるな
開発環境以外でのNodeの話ならム板かwebprog板じゃないか？ >>50
高速化の質問についてはコードが出ているなら、「自分で試せ」で終わり
「このコードはどちらが早いですか？」
「このコードは動きますか？」
こんな質問は実装以前の問題だ
自助努力を推奨するスレとしては「自分で試せばわかる事は、自分で試せ」の答えしかない >>55
何回か大統一の話もしたこともあるけど
統一も分離も曖昧にするのもやっぱり問題が出るんだよね
やっぱり俺のワガママだったわ、これまでのレスは無視してくれ
すまなかった >>54
「君のつらい経験」や「君のやりたいこと」で煙に巻くのはどうかと思うけど…
主観的な考えが多い人だねえ 実用厳禁★独自拡張、草案段階のJavaScriptについて
https://mevius.5ch.net/test/read.cgi/hp/1495948526/
純粋に仕様等について語りたい・空中戦をしたいならコッチだろ
このスレは理論のためのスレじゃない >>59 俺はそういうことが言いたかったんじゃないよ >>57
多分、自覚症状がないようだから、あえていうが、君の考えは「客観性」がまるでないから、受け入れられないんだよ
「俺はこうしたい」「俺はこうだった」「俺は無理だと思う」
これは全部、君の個人的な考えで他人を説得できる根拠じゃない(君を信頼している人なら受け入れるかもしれない)
100スレ前から受け入れられなかった原因も、その辺にあるのではないかと思うぞ >>52
> 過去ここで古くはWinメトロの話題からNode上でのStreamの話題や
> 様々なプラットフォームの質問が足蹴にされてきたのを見てきた
そんな大昔のことは知らん
直近2か月程度では、形式的に足蹴なんてあった覚えがない
あったというなら具体的にリンクを挙げたまえ >>60
それでは
どういうことが言いたかったのか、具体例を挙げつつ論理的に述べてくれまいか
貴殿が言いたいこと、具体的にところが把握できない
他の人々にも、把握されているようには見えない
コミュニケーションなんだから、そこんとこ頼む Web のユーザーインターフェースとして第一義に考えられるのはブラウザ
具体的には、Chrome / Safari / Firefox（状況次第で IE11 またはそれ以前）
これが大前提として共有されないんだったら前提から色々崩れるんだけど
opera とか vivaldi とか含めるとカオスだからゴメン 「回答できる」と「質問していい」は別問題だと思うのです だとしても形式的に蹴られてる記憶が無い
昔のことは知らない 俺も記憶にないなあ
「Node.jsの回答なんてお前らできないだろ？」な煽りは昔、あったような気もするが、それかね 具体例挙げるなら
Q: オブジェクトのディープコピーをしたい
A1. jQuery 使え
A2. lodash 使え
A3. 「使える」ライブラリなりプラグインなりモジュールなり使え
A4. オレオレ関数なりメソッドなり作れ
他に何かあるかな（具体例でも第5の回答例でも） >>68
それはライブラリ質問を禁止する例じゃないのか？
実装系質問を禁止する例が来ると思っていたのだが
あと、ディープコピーなら JSON.parse(JSON.stringify()) が何度も出てたし、ライブラリしか回答がなかったかのような表現は改竄が過ぎる >>70
それは質問者の要件に依る
そもそも、質問者はいつも質問だけして回答を放置してるから、要件不明瞭でどれがマッチするか全くわからん >>68に関していうなら、「ライブラリ房」の存在が元凶だから、彼を排除する方針を決めるだけでいい
実装系質問が実質無理な理由ではない そうそう
新たな〇〇房が現れたらその都度対応するだけの話 >>44
だから実際のブラウザの話を抜きにするというのなら
実際のブラウザで動くことを前提として
質問が受け付けられなくなるんだよ。
Chromeで動きません。→実際のブラウザの話はしないでください。 ■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
これもなくさんとな。仕様の話しかしないんだから
OSやブラウザのバージョンなんか関係ない 実装無視の話なんてヨソでやってくれ
誘導
実用厳禁★独自拡張、草案段階のJavaScriptについて
https://mevius.5ch.net/test/read.cgi/hp/1495948526/ >>31 のリンク先の内容がカビ臭すぎ
どこから手をつけるのが良いか分からんけど、リンクしない方がマシなんじゃないかと（主観 >>37
前スレの運用からみて
無視 or ライブラリスレ誘導で良いかと ◆ HTML Standard (HTML5)
https://html.spec.whatwg.org/multipage/
リダイレクトがいつまで続くものやら
あえてテンプレから消すのも手かも知れず >>74
ちゃんと書いてあることを読んでよ
あくまでWebの仕様外の話に絞って言ってるでしょ
パフォーマンスとか、細かなセキュリティポリシーの違いとか、Web仕様で定義されてる以外の
そこはブラウザ開発者の考え方次第、実装のされ方次第の問題だよねっていう所を言ってるんだよ？ パフォーマンスや細かなセキュリティポリシーの違いは
Webの仕様で定義されてないって言ってる？ >>82
横から口挟むけど、続けるなら、「実質無理」の理由を明らかにしてよ
見る限り、誰も納得できてないよ > 見る限り、誰も納得できてないよ
というより理由はまだ出ていない
>>68は実装じゃなくてライブラリの質問だった ああ、ひょっとして、>>50か？
>>56で論破されてから反応がないが >>46
> Webというものがブラウザのためだけのものでなくなって久しいんだから
> 基本ポリシーとしてブラウザの話も受け入れるのならば
> ブラウザ以外のWeb技術を導入しているプラットフォームの話題も受け入れないとおかしいことになる
>
> 俺はそれが実質無理だろうと思ったから、ブラウザも含めてプラットフォームの話は無しにしたほうがいいと言ってる
「実質無理」の論点ってここ？
質問者が質問する分には、幅広く間口を取っておいていいとおもうよ
回答がつくかどうかは別問題
こんなのを論拠に「ブラウザというプラットフォームの話を無しにする」って方がありえんし誰も幸せにならないだろ
メリットあるなら教えて欲しいもんだが 50スレ前からいる俺は、>>74を「仕様の質問だけに限定するのは実質無理」と受け取ったが、100スレ前からいる彼には深い考えがあるのだろう。
- コードの動作確認が出来ない
- デバッガも使えない
- 仕様を読み取ってコードを書き、思考実験を繰り返す
この困難な状況をどうやって打開するのか、実に興味深い。
若輩者の私に、ご教示頂ければ幸いである。 実質無理と言ったのは
>>54で書いたようにそういう話題を完全に受け入れるというスタンスでもないし、
その逆でも今はないんだから、今までの様に穏やかにいられないんでしょという皮肉
そして>>82でも言ったが誰も仕様の話しかしてはいけないとは言っていない
仕様から離れたプラットフォームの話、つまり具体的に言うなら
普遍的なWebというものから離れたブラウザ固有の仕様の話は受け入れるべきかという話
デバッガは開発ツールなので今までWeb仕様とは別の体感できる動作についてて主に話してたのとは
ちょっと系統は変わるが、それでいうとそういう開発外部ツールの話を受け入れるのであれば、
同様にトランスレータだったり、オーサリングツールの話も受け入れるようにしないと
それこそ好き嫌いのとくに理由のない恣意的な差別になる
別に俺はどちらでもいいんだが、俺が一番言いたいことはそのどちらと決まってないことで
スレチだの何だのと不毛に荒れるのが嫌だから、せっかく今テンプレ議論がされてるから
この際にそういうスタンスもある程度決めて明記しておこうということ
まあそれで荒れなくなるかどうかは分からないが、少なくともどういう質問・回答の仕方をしたらいいのかの目安にはなる >>91
長文ご苦労様だが、
> 今までの様に穏やかにいられないんでしょという皮肉
根拠があなたの頭の中にしかないから、以降の話が全く頭に入って来ない
何度言われても根拠を出さないのだから、「根拠が全くない」か「感想が根拠だと思っている」のどちらかなんだろうな… 「俺はこう思う。お前らもそう思うだろ？」
→「そんなわけないだろ」(反対者多数)
→「なんで俺の思い(イメージ)を分かってくれないんだよ！」
今のところ、こんな印象 勉強中のものです。
「そこに何を代入しても何も起こらない、メモリも食わない、エラーにもならないオブジェクト」ってないものなんでしょうか。
例えば var element にDOM要素が入っているとして element.value="piyo"; という命令があるのはよくあるパターンですが、
このelementに中身が入ってないとエラーが出たりしますよね。
私は、いちいち if (element) element.value="piyo"; というふうな中身の確認をせずに、代入をできるようにしたい
（element の中身が「それ」なら、何も起こらず、エラーも出ない）んです。
こういうブラックホールみたいな値やオブジェクトみたいな存在ってないんでしょうか。 >>94
> このelementに中身が入ってないとエラーが出たりしますよね。
> 私は、いちいち if (element) element.value="piyo"; というふうな中身の確認をせずに、代入をできるようにしたい
例
https://developer.mozilla.org/ja/docs/Web/API/Document/getElementById
> 文書内に一致する要素がなければ null です。
.getElementById の返値をチェックすれば？ >>94
jQueryがそういう設計になってる。
例えばその例ではvalueを設定しているが、
jQueryの設計では「"0個以上の要素"に対してvalueを設定する」という書き方をする。
だから要素が見つからなくてもエラーにならないし、複数見つかれば複数設定できる。
いまだにブラウザ間の互換性問題が解決したからjQueryはいらないなんて言ってるやつがいるが
こういう設計がDOM APIとは異なってる（使いやすい）ライブラリなんだよ。
で話を戻すと、jQueryでは $('.foo').val('piyo') みたいにセレクタで指定することが多いが、
$(elemment).val('piyo') みたいに単一の要素を指定することも可能。
この場合、elementの中身が入っていなくてもエラーにならない。
（elementの取得だけDOM APIを使うこともないだろうから普通にセレクタ使えばいいだろうけど） >>94
変数にする以上はメモリを消費するので、メモリを消費しない方法はない
変数にしなければ、当然、メモリは消費しない
if (typeof element !== 'undefoned' && Object(element) === element)
element.value="piyo";
メモリを度外視するなら、Object.create(null) でラップオブジェクトを作って、setterかnew Proxyでプロパティを監視する事で実装可能 jQueryってメモリ消費しないんですね。ありがとうございました。 >>92,>>93
なんか勘違いしてるのかもしれないけど
思いを分かってもらいたいわけではなく
何か揉めたときに、テンプレに「自ら学ぶため」という言葉があれば
まあそれを持ち出して決着を付ける事が本当に良いことかは置いといて、
一応このスレのスタンスだからと言えるでしょ
でも今のままでは、俺が折角マニアックな質問を色々調べて回答してあげても
それにスレチだなんだケチがついたときにどっちが正しいとも言えず永遠喧嘩になるでしょ
それはどちらが悪いとかじゃなくて俺と彼とで考えるこのスレで扱うものの基準が違うという事で、それが何処にも示されていない以上、個人の好みになっちゃうんだから
それで俺も彼も質問者も不幸になることはもうやめたいんだよ
俺はpart20かそこらから質問回答してきて、自分だったり他人だったり実際そうやって嫌な思いを沢山してきたから
不幸になる人が少しでも減るようにテンプレに基準を入れてほしいと言ってるの
別に崇高な一般論を理解してもらおうと主張してるわけではない
最初からそういう俺の小さなお願いのつもりだったのに
なんでこんなに突っ込まれて話が大きくなったんだろうね?
もう俺のことはスルーしていいよ >>94
falsyな時だけ「空のオブジェクト」を代入するなら、こういう書き方はある
>>97は一つのオブジェクトで一元管理する
var element = document.getElementById('foo') || Object.create(null);
>>98
そんなわけない
変数にする以上は、メモリを消費する(>>97) コードは長くなるけど変数使わないからメモリ消費しないんだぜ！
↑
そのコードを入れておくメモリが消費される >>100
この質問の本質は、そういうコードを書きたくないということでしょう？ 結局何をしたいのか分からん
C言語だって char *a = "abc"; と書いたとき、ポインタ a の分だけメモリ喰うわけだしな
したいことと、典型的なコードでなってしまうことの差が
具体的に分からないと何ともいえない
https://jsbin.com/yemedon/edit?html,js,console
こういうのとは違うみたいだし 無理矢理いえば test() の返値は必ず入る
アセンブラのときにレジスタに必ず入るかどうかは知らない
0 との比較の場合はアセンブラ的には即値0が必要とならないケースが多い、はず
RISCでどうなるか等は知らない
サボリのためCASLの仕様書は読んでない 変数は必ずしもメモリを消費しない
インライン化とエリミネーションで半分程度削減される
だからデバッガを有効にしてるとメモリを食う > 私は、いちいち if (element) element.value="piyo"; というふうな中身の確認をせずに、代入をできるようにしたい
そもそも、これって vanilla JS で実現できるの？ 入力があって、出力対象となるべき要素がなければ
parentNode に appendChild() するのが自然な考え方にもおもえる
無視して良いという仕様なのだろうか（そうだとしたら while で終わりか？）
メモリどうこうより仕様が気になるな
それとも「じつはライブラリ房でした」というオチなのか Rubyには通称ぼっち演算子っていってね、
a=nil
a&.foo
# =>nil
みたいに、値がnilでもエラーにならない方法があるんだよ。
どうせこれのこと言ってるんっでしょ？
でもね、コード上メモリを使ってないように見えても、
アセンブラレベルで見れば「if nil だったら nil を返す」って
コードになってて、コードの分のメモリ使ってますからｗ >>107
いつものRuby厨がしたり顔をしにやってきたが、
言いたいことを先に言われ、良い所を
jQuery厨に持っていかれたという流れｗ イケてる言語のNull条件演算子：
C#
?.
Swift
?.
Kotlin
?.
イケテナイ言語のNull条件演算子：
ﾌﾞﾋﾞｨ
&.
ムダな認知負荷の大きいクソ言語。 ■ このスレッドは過去ログ倉庫に格納されています
