C#, C♯, C＃相談室 Part94

1 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 15:36:53.26 ID:S+KK7a41.net] ■Visual Studio 2015 Community & Express (無償の統合開発環境)等はこちら www.visualstudio.com/downloads/ ■コードを貼る場合はこちら ideone.com/ ■前スレ C#, C♯, C＃相談室 Part92 （実質93） echo.2ch.net/test/read.cgi/tech/1485589613/ ■次スレは>>970が建てる事 建てられない場合は他を指定する事。 74 名前：67 mailto:sage [2017/05/17(水) 23:19:09.78 ID:SKu/yZ4u.net] なんで叩かれてるのか知らないけど、Mavenリポジトリと言えば満足? 75 名前：デフォルトの名無しさん mailto:sage [2017/05/18(木) 00:04:10.18 ID:JYcaMM6T.net] web系の自動化ツール充実度に嫉妬 76 名前：デフォルトの名無しさん mailto:sage [2017/05/18(木) 03:52:39.26 ID:nv0hNXKv.net] >>70 具体的に 77 名前：デフォルトの名無しさん mailto:sage [2017/05/18(木) 06:54:17.24 ID:Zif2rhHO.net] >>71 Web系はやっつけだろうが早くリリースするのが至上命題だからテストを自動化しないとカオスになる 78 名前：デフォルトの名無しさん mailto:sage [2017/05/19(金) 23:40:22.50 ID:K2XF16mV.net] クラスのメンバー� 79 名前：ﾌ型を動的に変更するなどは可能ですか？ 例えばMyClassのメンバーに public string name { get; set; } が有るとして、それを一時的に public List<string> name { get; set; } に変えるなど可能ですか？ [] [ここ壊れてます] 80 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 00:19:20.01 ID:/WJez+wG.net] >>74 できない 何のためにそんなことをしたいのか 81 名前：デフォルトの名無しさん [2017/05/20(土) 00:28:41.92 ID:lbI4YU5N.net] public string|List<string> name { get; set; } じゃ駄目？ 82 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 00:44:05.60 ID:I6OViHCS.net] >>74 そのメンバーに色々な型のデータを突っ込みたいなら dynamic 型を調べるがよろし 83 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 01:21:14.87 ID:aMCzC0+r.net] >>76 ありがとうございました。うまく行きました。 こんな手法があるんですね。 84 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 02:50:37.33 ID:/vBlyS11.net] え、なにそれは 85 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 03:36:45.84 ID:XoWVmAv8.net] >>76 このテクニックなんか名前ついてるの？ 86 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 04:31:41.03 ID:DT+L3BmX.net] アンカーの付け間違い 87 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 06:41:31.55 ID:hBo0eJTZ.net] コンパイル通らねーよｗ意味不明 88 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 10:23:12.61 ID:wDlYVPvY.net] 素直にgenerics使え 89 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 11:05:10.16 ID:NUOkmiRN.net] nameとnamesの区別がついてないクソPG 90 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 11:05:32.94 ID:lbI4YU5N.net] あっTypeScriptと勘違いしてた C#じゃ出来なかったわ すまん 91 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 11:08:01.58 ID:NUOkmiRN.net] いつどこからアクセスするかわからないプロパティの型を可変にする意味は何？ 実際バグ出したいだけだろ？ 92 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 12:26:52.90 ID:pKHKYg56.net] 静的に型付けされてるメンバーを動的に変更することは出来ないに決まってるねw 逆に出来たら困る なんか静的に型付けされているってことの意味が分からない人が時々いるよね 型Bと型Cの両方を受け入れるプロパティが欲しいならプロパティーの型を共通のベースクラスAにして、 プロパティの値はプログラマの責任で適切にキャストして使うしかない あとはBとCの間で相互に暗黙変換できるようにするとか 93 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 12:28:59.33 ID:Lw3rlvDI.net] 初心者は制約があるより自由にかけるほうが良いと思う時期があるものさ 問題があった時にどこからでもさわれたほうが対処しやすいからフィールドは全部publicにしたほうがいいとかね 94 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 17:55:46.01 ID:lhYW/664.net] ふらっとでやろう 95 名前：デフォルトの名無しさん [2017/05/20(土) 22:16:05.31 ID:tNlWtPh8.net] class A { public int i; public virtual void storeNumber(int arg){ i = arg; } } class B : A { public new int i; public override void storeNumber(int arg) { base.storeNumber(arg); i = arg; } } A typeA = new B(); typeA.storeNumber(1); System.Console.WriteLine(typeA.i); //1 B typeB = (B)typeA; System.Console.WriteLine(typeB.i); //1 typeB.storeNumber(2); System.Console.WriteLine(typeA.i); //2 System.Console.WriteLine(typeB.i); //2 new キーワードのメンバは変数の型で参照先が決まると書いてあったんですが A型の変数から呼び出しても、オーバーライドしたクラスBのメソッドから代入すれば new が付いてるint i でも値を代入できるということでいいんでしょうか？ 96 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 22:22:56.23 ID:spqPzklw.net] いまいち言いたいことは分からんがそうだよ 97 名前：デフォルトの名無しさん [2017/05/20(土) 22:49:49.46 ID:tNlWtPh8.net] >>91 ありがとうございます。オーバーライドとbaseのことを調べてコード書いてたら これでひっかかってたので助かりました。 98 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 23:36:54.63 ID:PmwbqNDX.net] 隠蔽した本人から隠蔽後のメンバーじゃなくて 隠蔽したはずのベースクラスのメンバーが見えるなら何のための隠蔽よww まあでも、どうせ隠蔽なんてまず使わないw 俺が使ったのはたぶんWindows Formのコントロールをカスタマイズするときに virtualになってないメンバーを苦し紛れになんちゃってオーバーライドする時ぐらいだ 99 名前：デフォルトの名無しさん mailto:sage [2017/05/20(土) 23:56:17.91 ID:/WJez+wG.net] 隠蔽は後から他の奴が基底クラスに同一シグネチャのメンバを追加しやがったときに 派生クラスが壊れないようにするための仕様だよ 積極的に使うものではない 当時のMSは極度の互換性パラノイアに陥っていたため、C#はバージョニングに関しては異常に神経質設計されている 100 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 12:03:34.57 ID:+V9bC4xn.net] ヌル許容のdatetimeだとyear関数とか使えないんですか？ 入力必須じゃない項目なので困っています。 101 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 12:15:28.78 ID:jI6oRZ6H.net] >>95 dt?.Year 102 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 12:17:58.62 ID:F7+6VHDt.net] ヌル許容のdatetimeってわからない。．NETのは構造体なのに 103 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 12:21:51.82 ID:3W0XlzKr.net] 大分前からヌルが基本的に無いintとかにヌル入れられるヌル許容型ってのがあるが。。。 int? x = 123; int? y = null; 104 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 13:22:43.56 ID:edjbow2J.net] >>95 つかえるよ コード間違えてないか？ 105 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 14:04:03.15 ID:A3vGR0ii.net] stringですら?付けてstring?にしようという時代に 細かいことをごちゃごちゃと 106 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 17:45:15.21 ID:PJIONmxy.net] stringは参照型だから元からヌル許容してたのに、なぜヌル許容型をわざわざ？ 浦島太郎で申し訳ないが説明頼む。 107 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 18:27:41.35 ID:Ph34uzkO.net] >>101 https://github.com/dotnet/csharplang/blob/master/proposals/nullable-reference-types.md 108 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 18:33:56.97 ID:LMlAaHk/.net] https://gist.github.com/olmobrutall/31d2abafe0b21b017d56 これだろ string?じゃなくて、nullを許容しないstring!を導入したらどうか?という話 stringをstring!に変換しようとしたときにコンパイラがnullチェックを入れればいいだけだから悪くないアイデアだとと思う 109 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 18:49:06.30 ID:UZ2qE6DF.net] >>101 よく知らんけど、DateTimeとかDB側でNULL許容として扱われている値型を同等に扱うためじゃないのかね じゃないとEFとか破綻しそう 110 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 18:52:36.71 ID:yWN+qtCg.net] >>104 .Net1.0から実装されていて欲しかったけどな つかDataSetっていうウンコがあったからNULL許容型の生まれが遅くなった可能性があるな 111 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 18:53:40.67 ID:LMlAaHk/.net] >>104 そうじゃなくて逆にnon-nullableが欲しいというのが趣旨だよ で102で紹介されてるstring?の案は「いっそ参照型もデフォルトでnull非許容にしようぜ」という超過激なトンデモ案 112 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 18:57:42.54 ID:HT5KxiNP.net] 是非そうすべきだ 113 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 19:06:32.73 ID:X2XHKUCb.net] TypeScriptがそういう風に仕様変更されたけどさすがにC#には不可能でしょ TypeScriptとは違って過去の資産があるし書捨てプロジェクトばかりじゃないんだから やるならstring!しかないけど!だらけでソースが見苦しくなるのが難点だな 114 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 19:11:34.18 ID:J4QCEXrr.net] https://www.infoq.com/jp/news/2017/04/CSharp-Nullable 近いうちに実現するっぽいよね こういうところがC#って凄い。 115 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 19:13:26.09 ID:HT5KxiNP.net] いつまでもVBを引きずって瞑想していたMicrosoftとは思えないな ヘジたんは偉大だ 116 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 19:19:42.67 ID:QProx2es.net] >>96 ありがとうございました。 単純に理解不足で参照側に？をつけていないだけでした。 117 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 19:23:28.74 ID:SHq3YOvL.net] またnullの話w null非許容が欲しいなんて問題の原因を取り違えているだけであって、 そんなもの導入してもnull例外が初期化忘れに置き換わるだけだっていう 簡単な事実が分からんアホが多すぎで呆れるよ 118 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 19:25:29.82 ID:5hEoQuZK.net] >>103 ありがとう。 逆なら納得だわ。 119 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 19:27:51.33 ID:5hEoQuZK.net] >>112 そこまで単純化されたら大助かり。 120 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 20:14:30.69 ID:AM37HZZ1.net] >>112 何言ってるのかわからん 初期化忘れって何よ 121 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 20:31:14.27 ID:HT5KxiNP.net] またJavaに大きな差を付けてしまうな あとはエコシステムも充実させてくれ 122 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 20:57:28.99 ID:Swob9G4V.net] >>112 null結合演算子も超嫌ってたしね〜君 123 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 21:35:09.71 ID:SHq3YOvL.net] >>117 そっちは何も問題ない 124 名前：デフォルトの名無しさん [2017/05/23(火) 21:48:39.96 ID:VdgHftUV.net] varの話してもいいですか？ 125 名前：デフォルトの名無しさん mailto:sage [2017/05/23(火) 22:57:25.70 ID:MQkBzlkR.net] 命が惜しくないならどうぞ 126 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 02:20:31.18 ID:IRME+Rk/.net] TypeScriptとかSwiftとかKotlinの先例があるのにnull非許容の意味が理解できない>>112　みたいのが社会の進歩を妨げてるんだよなぁ nullの代わりに空文字を入れることになるみたいな意味不明なことを言ってるやつもいたし、英語の議論が読めないにしても他の言語の例ぐらいは確認してからしゃべってほしい 127 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 02:27:23.98 ID:k5coCCFX.net] またしょうもないのが現れたな 意味も意図も理解できるが、意図した通りの機能は発揮しないと言ってるんだけど だからその「先例」とやらで現に意図した通り間違って自分の足を撃たない機能を発揮してるのかと。 してやしねえよw 128 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 02:32:41.30 ID:k5coCCFX.net] 要するに、nullを許容することに起因する問題が存在するので nullを許容しなければそれは解決するのだ、なんていうのはただの愚か者の錯覚であって、 そんなものは問題Aをより発見が困難な問題Bに置き換えることにしかならない 129 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 03:32:06.26 ID:5B8IqCyj.net] nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編） www.buildinsider.net/column/iwanaga-nobuyuki/011 C#でのnull参照問題への取り組み ― null参照問題（後編） www.buildinsider.net/column/iwanaga-nobuyuki/012 読もうな 130 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 04:54:25.97 ID:f/qUGphe.net] nullpoを許容 131 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 05:52:55.01 ID:SWY45HoB.net] ポインタじゃなくていいところでは(nullを許容しない)参照をつかう C++では当たり前にやっていた事でその威力は皆が知っていた C++から派生したC#やJavaがこれを捨て去った意味が逆にわからない C#はあるべき姿に戻ろうとしているだけ 132 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 07:19:29.94 ID:OFlbMgow.net] >>122-123 レス古事記乙 133 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 08:19:55.11 ID:gnZYpDQN.net] Int f(int x) ならxで例えば小数の事を考えなくて済む。 同じく f(hogeClass y) でyがnullの可能性を 考えなくて済むならそのほうが良いだろう。 そう思わないならプログラマーは 早々にやめたほうが良いと思うの。 nullチェック忘れてヌルポだすコードを 量産するバカが減るのは助かる。 134 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 08:56:56.79 ID:2RBb7Y8v.net] 135 名前：なんで馬鹿は馬鹿を説得しようとするんだろう？ 馬鹿は馬鹿なんだから自分が馬鹿だなんて認める分けねえだろ だからお前も馬鹿だと言うんだ 馬鹿は死ね [] [ここ壊れてます] 136 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 09:20:10.02 ID:CWb9U0nP.net] >>128 少数のことを考えなくて済むように、nullがあった方が助かる場面もあるだろ そう思ってないようなおまえは早々にやめたほうが良いと思うよ 137 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 09:38:54.50 ID:dFpq1SmP.net] ついでにundefinedも導入してほしい 138 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 10:29:24.60 ID:4XHCBZ7H.net] ぬるぽ 139 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 10:36:49.92 ID:0w0qPph2.net] どうしてnull非許容型を導入するって話をnullの根絶なんて話に持っていこうとするんだろうね？ 140 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 10:46:19.73 ID:xvW9RZ2K.net] >>128 間違ってるよその発想 その発想って>>1254の記事にもあるけど、メソッドが引数にnullを受け入れる 確信もないのに意図してnullを渡すプログラマなんかいません。 nullを受け入れないメソッドにnullを渡してしまう事態が起こるのは、 バグによってプログラマの意図に反してそうなるからだよ。当たり前でしょ。 だからnull非許容型を導入したところで、「プログラマの意図の反して変数の能がnullであるバグ」が 「プログラマの意図に反して変数の値が不適切であるバグ」に置き換わるだけ。 そして後者は前者より発見が困難な分、悪性度はより高い。 こんな簡単なことが分からん奴ってアホだろほんっと。 141 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 11:09:16.07 ID:PQqcAP89.net] >>133 一つより二つ覚える方が大変だろ 未開人だと三つ以上は沢山だぞ そんなにプログラミングの要素を増やすな 覚えきれない 142 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 11:32:23.53 ID:fJwJIEtw.net] 変数がnullである　は　変数が不適切である　に含まれる 変数が不適切なケースのうち変数がnullであるケースを言語仕様として排除できるって話じゃないの？ 確かにこのnullのケースを排除しても他に不適切なケースがある設計なら完璧な対策ではないだろうけど有用なケースも認められるなら検討の価値はあるんじゃないかな？ 143 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 11:40:03.52 ID:lmoDZ3Fc.net] >>134 意図してNull値を渡すつもりがないなら Null値が入る可能性があることがコンパイル前に判明するほうが あきらかに修正もしやすいだろ なに言ってんだ 144 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:07:37.15 ID:xvW9RZ2K.net] >>137 何を言ってるのか意味が分からんね 145 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:11:17.02 ID:QZczTL/V.net] >>138 お前がな 146 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:23:14.46 ID:Em+sDdPu.net] 全部Object型でやってろってのと変わらんがな 147 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:55:24.52 ID:cF0VKHZde] Linux上でC#を使ってAndroid開発って出来ますかね？ 今までC/C++やJavaでやってきたのですが、 C#で上記が可能ならC#に移行したいなと考えてまして。 148 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:17:32.97 ID:IRME+Rk/.net] >>134 ただの理解不足。具体的にTypeScriptとかのコードでその状況を示して見てよ。 多分、nullが入れられなくなるので初期値に別に値(stringならstring.Empty的なもの)を入れるもんだと思ってるんだろう。 それは間違った考え ・nullの考慮忘れ ・過剰なnullチェック というのを防ぐのが目的 <従来> void Hoge(string arg){ 〜 } //listが要素を持っていなければfirstはnull string first = list.FirstOrDefault(); //何らかの処理 //nullの考慮忘れ。実行時例外 Hoge(first); <null非許容型> //Hogeの引数はnull非許容 void Hoge(string! arg){ 〜 } //ここは「何らかの処理」の都合でnull許容とする string first = list.FirstOrDefault(); //何らかの処理 //nullの考慮忘れ。コンパイルエラー Hoge(first); 149 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:28:42.02 ID:9Gf4SnqN.net] 実行時例外でるならそれでいいじゃんｗ 150 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:34:09.87 ID:xvW9RZ2K.net] >>142 具体的で 151 名前：素晴らしい 確かにその例で示されているような「nullの考慮忘れ」を防ぐ一定の効果は 期待できることは認める。 でもそれ、よく考えると机上の空論でしょ。 普通のプログラマならある変数やコレクションが仕様上nullを持ちうるかどうかは 常に気にしながらコーディングするので、そこに例示されている「nullの考慮忘れ」は 実際にはそんなにありがちな問題ではないと思う。 ありがちなのは、その例でいえばリストに値を入れる段階で プログラマの意図に反してnullが混入する問題だよね。 [] [ここ壊れてます] 152 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:55:01.74 ID:fJwJIEtw.net] 実行されるまで気づかないならインタプリタと一緒じゃん 153 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 16:07:24.68 ID:IRME+Rk/.net] >>144 ＞ありがちな問題ではない ありがちかどうかではなく、その機能を導入するメリットとデメリットの釣り合い。 エラーが未然に防げたり、記述が簡潔で見やすくなるならメリット。 文法が複雑になったり、別のバグの原因になったり、動作が遅くなったり、実装に手間がかかるならデメリット。 現状は「新バージョンではnull許容はstring?にしろよ」から「文法は変更せずフロー解析でどうにかしようぜ」までいろんなアイデアがある 個人的には、標準ライブラリの頭nullチェックをしてArgumentNullExceptionを出すようにしているところがいらなくなってライブラリ作者にはメリットがデカそうかなとはおもってる null入れてArgumentNullExceptionがでるテストも書かなくて良くなる 154 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 16:22:43.45 ID:IRME+Rk/.net] >>144 >リストに値を入れる段階でプログラマの意図に反してnullが混入する nullを含まないリストならList<null非許容型>にすれば意図に反してnullが混入しうる状況ではエラーや警告にしてくれるようになる List<null許容>から変えられないなら、取り出す時にnull非許容にすればその場でエラーが確認できる フロー解析で検出が無理な状況も当然存在するけど、多分こんなことをするのかな <現状> string A(){ string a = Hoge();//Hogeの戻り値はnull 別の処理 return a;//意図せずnullを返してしまう } これだと、別の処理中にぬるぽになったり、戻り値がnullになるかも。 Hogeの戻り値が不適切なのに、別の処理中でエラーが起こるのでスタックトレースとかではバグが探しにくい。 <null非許容> string! A(){ string! a = Hoge().ToNull非許容;　//null非許容に変換 別の処理 return a; } これが以下のようにコンパイルで展開される string A(){ string a = Hoge(); if( a == null)throw new Null非許容型変換例外(); 別の処理 return a; } 例外発生箇所が確定するので、バグの位置がすぐにわかる この例だとnull比較のコストが入ってるけど、俺の知識が浅いだけなのでもっとうまいやり方も多分あると思う 155 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 17:14:59.24 ID:rw+7fc+A.net] そうだねーPHPから出てこないでね 156 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 18:01:59.69 ID:9Gf4SnqN.net] null許容にするメリットを実感できないんだろうな 157 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 19:54:58.94 ID:wmLMN2ht.net] 使えとは言ってないのにな 親でも殺されたか？ ゴミムシの親なんか区別がつかないだろうが 158 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 23:36:34.45 ID:a2/m6a7T.net] >>147 コンパイル後の出力にnullチェックが入ってるってことは string! aにnullが入る可能性が出来てしまうってこと！？ そこはコンパイルエラーにしてもらおうよ >>142の > ・nullの考慮忘れ > ・過剰なnullチェック > というのを防ぐのが目的 （＋テスト） は、防ぐというより無くしたい 159 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 01:11:21.81 ID:lqQtAs3j.net] >>151 nullチェックはNull許容型からNull非許容型にする際の話 nullの可能性があるならタイプマッチとかで消すほうが素直だけど、kotlinとかでは例外を投げる変換を用意してるみたい 修正されてない古いライブラリとかだとnullにはならないけどnull許容型みたいのが存在せざるを得ないので、そういう機能もほしい 160 名前：ということじゃないかな [] [ここ壊れてます] 161 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 03:16:43.36 ID:ezJU1k3U.net] 今のところ超過激なトンデモ案が優勢なのかな？ 採用されたら仕事が捗りそうなので、とても期待しているww 162 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 03:37:28.50 ID:XcDeaOpm.net] null非許容型が追加されるならconstメソッドも 追加してほしいもんだ。 163 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 03:38:41.10 ID:K8EeLAYg.net] いまだに2.0とか3.0やってる化石には全く関係のない話だから 足引っ張らないで欲しいわ 164 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:11:39.41 ID:raX4nowj.net] Linqすら使えない自分の職場の悪口は止めてくれないか 165 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:17:54.20 ID:TdXNYUaP.net] 職場？お遊戯会の間違いだろ 166 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:41:19.09 ID:OZ9w4Yf7.net] ロック問題で、価値ないつまらんネタ書いている奴こっち来い 適当にあしらってやるよ 167 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:44:07.67 ID:raX4nowj.net] >>158 向こうに行ってやれよw 168 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:50:35.84 ID:OZ9w4Yf7.net] 最近は、こっちではnull非許容ネタやってるのか・・・ これ導入されたらガベージコレクタの性能落ちたりしないかな 4G越えのでかいツリー構造とか作っていると、参照つなぎ替えだけで色々やばいことが起こるんだよな できるかぎり、用のないフィールドに参照ぶら下げたくないと最近しつこくnull入れてたりするんだが。 あと、event関係、弱参照で全部作り直さないとヤバないかな。 Taskとかと相性悪くて簡単にメモリーリーク起こすし、 WeakEventManagerでWPFは変態回避してただでさえコード変態状態だし。 VMごと作り直さないと色々噴き出しそうだ 169 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:51:39.74 ID:OZ9w4Yf7.net] >>159 ここはキチガイの建てたゴミ箱、ちょうどいいんだよ。 170 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 12:35:35.78 ID:KYr+IXo2.net] >>160 そんな場合はnull許容型を今迄通り使えばよろし 171 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 12:39:51.97 ID:doyjLZp2.net] なんで択一の考えしか出来ないんだろうな 頭悪いのか？ 頭悪いならゴミ回収みたいなルーチンワークしてろよ 172 名前：デフォルトの名無しさん [2017/05/25(木) 12:40:36.41 ID:OZ9w4Yf7.net] >>162 統一性のないコードになりそうだw ここまで破壊的変更をするなら同じVM上で動く別言語として全く新しく設計した方が良い気がしてきている。 C#と混合してプロジェクトに登録できるようにすればシームレスにつながると思う。 今のC#には、アクロバテックな予約語追加とかも増えてきているし、いろいろ限界が来ていると思うんだ。 173 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 13:22:25.50 ID:OZ9w4Yf7.net] どうせならC#を改造するのではなく、新規言語にして、ここにあるパターンをサクっと言語仕様として実装してみてほしいな。 https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2) >一部のデザインパターンは、プログラミング言語（例: Java, C++）の機能の欠損の印であると主張されることがある。 >計算機科学者のピーター・ノーヴィグは、GoFによるデザインパターン本の23パターンのうち16パターンは、 >言語によるサポートによって単純化または除去できることをLispやDylanを用いて実演した。 あと、マルチスレッドプログラミングに関するパターンも、C#で書いていて本当に冗長と感じる。 文法は、Pythonみたいにインデントでネストを書けるようにしてくれれば、Pythonと交互に書くときに {} 忘れで判りにくいバクにならなくて済む。 174 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 13:37:43.42 ID:Gj1BXJi/.net] >ID:OZ9w4Yf7 基地外こっちでも大暴れかwww

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef