1樓：HumJ
還是沒吃到我最想要的，能把
value = dictionary.TryGetValue(key, out var v) ? v : default;
簡化為value = dictionary[?key];的糖
2樓：Ben Lampson
C#越來越像C++了..不覺著麼...()瞅了瞅微軟的Issue,除我的uniontype自己實現的之外,貌似還有3個同型別實現.
話說微軟當年不是自稱要有實現麼
然而貌似我們3個人把自己的uniontype推到issue以後.都沒有回音了,慘烈~
3樓：
看完C#的新特性，我感覺是時候放棄了
對這門語言越來越失望。太多華而不實的語法糖，看似把這種語言的便利性提高到了極致，但是可讀性也成了一坨屎。
C#失敗就失敗在，大家希望它越來越強大，越來越便利，越來越。。。。。這些都具備了，但是使用者卻早流失完了。
一門語言就像是一粒種子，把它埋進土裡，任它主要生長，它會長成自己想要的樣子。而不是由乙個公司控制著它的未來，就像被人扼住咽喉。
致我懷念的C#
4樓：皮皮關
由於Unity的推動，C#現在是遊戲開發領域的主力語言。不僅Unity引擎，新引擎比如Godot也加入了對C#的支援。
雖然許多遊戲開發者長期使用C#語言，但絕大部分對C# 7.0以後的新語法不太關心。以下說明不針對C# 9.0，僅供日常使用C#的遊戲開發者參考。
為什麼遊戲客戶端不太關心C#的新語法？原因大概有這麼幾點：
1、Mono等第三方虛擬機器對新版本的跟進比較慢。（因為跨平台問題，一般不用微軟的.net虛擬機器）
2、一些高階語法，例如事件event、用於非同步的await/async在遊戲客戶端用不到。
3、語法糖之類的東西可用可不用。
為什麼在Unity中，event關鍵字用不到？
在遊戲引擎中，事件的通知機制是從引擎層到應用層、自底到頂貫穿的。沒必要也不應該由開發者自己設計事件系統，應該交給引擎設計，所有人按照規範使用即可。
遊戲引擎對事件的設計，一是要符合實際需求；二是要保證所有事件的執行順序，次序對於遊戲邏輯來說至關重要。
這麼一想你會發現——語法上C#提供的委託足夠用了。為了規範事件機制，同時也滿足引擎底層（C++層）和C#的互通，Unity設計了UnityEvent，足夠嚴謹足夠好用。
為什麼在Unity中，非同步語法async/await用不到？
非同步邏輯對遊戲來說非常重要，動畫、網路、資源載入都會涉及到非同步邏輯。而且，和一般的應用程式不同，遊戲極為強調時序的重要性——包含邏輯順序和真實時間兩方面。
Update、FixedUpdate、LateUpdate等等，每個更新事件都有精心設計的呼叫時機。另外，不同的元件也有穩定的先後順序，打亂很容易造成BUG。
正因如此，不建議把與時序有關的任何問題交給C#處理，而是由Unity統一接管。結果就是，非同步、等待和同步的功能還是要借助Unity提供的非同步方法。
而幾乎所有的非同步操作都要借助「Unity協程」實現。其中Unity協程只是C#迭代器的封裝而已，還是用不到C#本身的非同步語法。
補充：C#提供的一些高階語法，特別是非同步語法對遊戲伺服器開發來說非常有用，只是目前C#遊戲伺服器並不算主流。
5樓：我想飛的更高
說些自己的看法。
1、微軟的產品都是好產品，特別是被它自己搞死的產品更是精品。
2、大概率下一步要推core，所以.net去死吧。
3、muck ficrosoft。
6樓：
不要失望，我相信這就是微軟的策略，故意把語言弄壞。
還有別的問題，比如
Visual Stduio telemetry不知偷了多少個人敏感資訊，我相信檔名應該上傳了。問題是，就算知道，要避免還是有困難的，比如改用vscode，同樣有telemetry，改用vscodium，那微軟的C++外掛程式不讓你除錯，前段時間改用manjaro，卡得不行，wayland這麼多年進步不大膝蓋想想都覺是有問題
manjaro也不行，沒什麼好說的，只能犧牲一點便利性，自己定製，必須買標壓CPU了：
需要編譯很多東西
Linux影象介面要流暢配置還是要高點
7樓：Caspar Cui
從2.0開始一路走來的老程式設計師。
覺得新的語法糖很多我都不會立即換用新的，因為老的方法已經足夠熟練了。
這裡面的Top-level programs這個。。我只能說一言難盡的。
Target-typed expressions這個。。。哎喲我滴媽。。。
但是 init 和 with表示式看起來會很好用。
其實輪子哥說的沒錯，語法糖加的太多，語言特性就被破壞了。逐漸會背離c#的初心。
8樓：星風雪月
就個人而言，除了data class期盼已久外，別的感覺也就是錦上添花吧。
野雞程式設計師，英語也不行，Issue看得吃力，不知道我想要的特性有沒有機會，咱也不敢說，咱也不敢問。
元組拆包（解構？）
將元組拆成引數列表。
void
Foo(
intp1
,stringp2,
DateTimep3,
floatp4,
stringp5,
stringp6,
intp7
,int
p8){};
(intp1,
stringp2,
DateTimep3,
floatp4，
stringp5,
stringp6,
intp7
,intp8,
doublep9)
FooDto
;Foo
(params
FooDto
);// 不知道用什麼符號/關鍵字好，就暫時用這個params吧。
可以編譯成
void
Foo(
intp1
,stringp2,
DateTimep3,
floatp4,
stringp5,
stringp6,
intp7
,int
p8){};
(intp1,
stringp2,
DateTimep3,
floatp4，
stringp5,
stringp6,
intp7
,intp8)
FooDto
;Foo
(FooDto
.Item1
,FooDto
.Item2
,FooDto
.Item3
,FooDto
.Item4
,FooDto
.Item5
,FooDto
.Item6
,FooDto
.Item7
,FooDto
.Item8
);配合即將到來的data class，可以將data class先解構成元組再拆包成引數列表。
這我還在題主的文章下面提過。
泛型引數型別推斷
類似TS中的型別推斷，C#中用using可以宣告型別
using
ItemOf
:List
K>?K :never ;// 這裡的extends冒號不知道會不會有什麼問題 class Container IEnumerable >}string bar= Container >>. Foo; 作用於巢狀的泛型可以少宣告乙個型別引數。 如果bottom type不會有的話，我覺得也可以用下劃線單純得讓編譯不通過。 說到這個，C#現在值型別的協變也是個大坑！值型別不能協變的話Container>都沒法用，還得給很多有泛型的整個沒有泛型的父類/父介面。 這我好像也在題主的文章下面提過。 9樓：Ivony 嘛？UnionType還沒有，乙個模式匹配要多少個版本才完整？ 都不說ExpressionTree這是被遺忘了嗎？ ExpressionTree好像到現在都還不支援?.這種基本的運算子…… 你不想新增新的運算子節點型別可以理解，那你好歹編譯期展開啊，直接不支援是什麼鬼？語法越來越強大，ExpressionTree就越來越殘廢…… data這玩意兒你都發明了with語法了，為啥不強制不可變啊？（據說是強制不可變的） 匿名型別又被忘了麼？with語法不打算支援匿名型別？真是個後娘養的…… 相容性其實沒問題，因為匿名型別都是internal的，所以你改改實際的實現，加點什麼拷貝建構函式進去沒啥關係…… Attribute初始化這個算不算init也沒說…… 確實感覺現在C#開始拼KPI了，真正有意義的事情好像都沒人管了…… 10樓： data class；when；is not Kotlin + Python = C# 9.0 很Python，很Kotlin 公尺菟 個人感覺吧，這次的的夢想夏鄉終於把故事開始展開了，不過我在想，如果真的這麼四年四年下去，還能不能火 這一作畫風感覺水彩畫的感覺比前幾集還要嚴重，也許是要襯托劇情吧劇情上，就是我第一段說的那樣 總的來說，特別給人想看的感覺，願幾個四年之後能看到異變的元凶 雖然說4年一集容易忘劇情，不過你把3去... 大家大部分都在說135mm這只長焦移軸，我就不說了，說說很少談到的50mm這只標頭移軸吧。這隻頭很重要，一定程度上終於補全了佳能移軸的焦段，當然如果有乙隻35mm移軸那就更好了。50這只標頭移軸的視角非常平靜和克制，在建築攝影中，特別是商業建築攝影，很多人都喜歡用17和24這兩隻超廣角移軸，但是這樣... CARay 延續了強大的周邊配件生態，硬體效能繼續top級別，雙肩鍵帶來全新玩法的同時外觀更加低調。這波是保守戰術無功無過，能帶來這些創新就算用心。 LX白 說到ROG那就不得不提起比他前一天發布的聯想拯救者手機。外觀就憑第一眼的感覺來看，聯想拯救者給我帶來的視覺衝擊更大，logo更為炫酷。細看之下...如何評價於C90發布的《夢想夏鄉3》？
如何看待佳能即將發布的三款50mm 90mm 135mm微距移軸鏡頭？
如何評價即將發布的 ROG遊戲手機3？