- 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が建てる事
建てられない場合は他を指定する事。
- 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
- 175 名前：デフォルトの名無しさん [2017/05/25(木) 13:39:20.53 ID:OZ9w4Yf7.net]
- >>166
ようキチガイ、ここは、お前が建てたスレだろ。
向こういくなや、あっちはマジ質問なんだから。
お前とは、ここで遊んでやる。
- 176 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 16:36:05.73 ID:Wjjn5VOT.net]
- まじで基地外だからな・・・
- 177 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 17:37:12.65 ID:KYr+IXo2.net]
- >>164
swiftもkotlinも同じ感じの仕様だから適切に使い分けられれば良いんでないのかな
それがスキルだし
- 178 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:24:15.44 ID:6uvmeYQm.net]
- c#がもし最初から作り直せるとしたらどんなふうにする？
俺は
yield returnじゃなくてyieldにする
ジェネリックをsystemに入れる
- 179 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:31:48.41 ID:ISg+EccP.net]
- 取り敢えずintは64ビットでstringはnull無し
- 180 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:55:20.09 ID:QWlkLrx5.net]
- switchのbreakは省略可能にする
- 181 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:57:08.84 ID:yV0yCNuL.net]
- Nodeが快適すぎる
C#ってなんだったの？
- 182 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:57:54.98 ID:6uvmeYQm.net]
- >>173
言語と動作環境比べられても…
- 183 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:21:56.48 ID:KYr+IXo2.net]
- immutable保証の構文は欲しい
if forは文でなくて式でありたい
副作用隔離文法も欲しい
- 184 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:24:16.19 ID:BYkVp2J8.net]
- ジャップなんて99%素人に毛が生えたレベルなのに使い分けとか酷だ
- 185 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:36:21.23 ID:6uvmeYQm.net]
- ダック・タイプの問題も最初からすっきり仕様作る
- 186 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:39:01.89 ID:1nEgUyka.net]
- constとreadonlyの整理
c++のconstが好きだった
- 187 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:56:07.17 ID:KYr+IXo2.net]
- デフォルトでconst
キーワード指定した時だけ非const
が良いなあ
- 188 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:07:38.18 ID:ZdIAUNK0.net]
- 何が嫌かと言えばVMだな。最初からネイティブコードコンパイラーならC++すら凌駕したかもしれん
- 189 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:09:09.51 ID:lGDY6SHI.net]
- 少なくともC#のconstとreadonlyは機能的に違うし、
どちらを無くされても困ると思うけど...
- 190 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:10:14.40 ID:VSmfM+8N.net]
- >>173
フレームワークって知ってる？
- 191 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:18:46.47 ID:6uvmeYQm.net]
- 名前空間の分割をもっと簡素にする
今はusing増えすぎでめんどい
あと一ファイルに名前空間一つに限定で
ファイル先頭で指定、｛ ｝なしにする
namespace Hoge.Hoge :
これでwebからのコードのコピペが楽になる
- 192 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:24:26.30 ID:vS0Oxp45.net]
- switch の最後の節の break は不要にする
ってかこれぐらいすぐやれ
毎回モヤモヤするんだよ
- 193 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:26:15.77 ID:1nEgUyka.net]
- >>181
だから整理って書いたんだけど…
統合って意味じゃないよ
- 194 名前：デフォルトの名無しさん [2017/05/25(木) 20:28:33.23 ID:SU7CE5fr.net]
- readonlyは長すぎる
javaのfinalもだけど頼むから多用する奴は3文字以内にしてくれ
scalaなら定数も変数も同じ3文字だから揃って見やすいのに
- 195 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:29:42.51 ID:lGDY6SHI.net]
- >>185
では整理とは具体的にどういう意味でしょう
- 196 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:33:29.10 ID:OZ9w4Yf7.net]
- 細かい機能系だと == オーバーロードが割と収集つかない感じなっているので
object.ReferenceEquals object.Equals を毎回書く羽目になり始めている
これは無駄なので == オーバーロードは廃棄して
object.ReferenceEquals object.Equals の糖衣構文として === !== == != という形にして欲しい。
Java屋がC#登場時に==オーバーロードはヤバイと警告していたが、今のC#は本当にそうなってしまった。
当初は気にしすぎと思っていたが、これは良くなかったな。
<= >= なんかも最低1個書けば残りは自動的に実装してほしいな。
== != はobject.Equalsは必須なので、あとは < <= >= > のいずれか一個を定義すれば残りは全部生成可能。
IComparable<A>を実装したのなら、逆にそこからobject.Equalsを実装してほしい。
object.ReferenceEquals に対応する GetHashCode() は簡単に利用できるべきだ。
LINQを使うときに、Distinct()などで、object.ReferenceEqualsを使いたいケースは多い。
どの比較を使うのか簡単に指定できるようになって欲しい。
比較演算子は、三引数の演算子にして、比較方法、比較対象1、比較対象2という感じにして
a ==[比較方法] b のような感じで扱えるようになると見通しが良くなると思う。
今のC#は、ラムダ式と比較用interfaceが入り混じって混沌の世界と化している。
|
 |
