Movatterモバイル変換


[0]ホーム

URL:


信之 岩永, profile picture
Uploaded by信之 岩永
PPTX, PDF85,257 views

Deep Dive C# 6.0

2015/4/11dotNetConf 2015 Japan with JXUGhttps://atnd.org/events/63844にて登壇。

Embed presentation

Downloaded 57 times
C# 6.0C# とともに祝15周年岩永信之
数年待った新仕様• async/awaitの情報が出始める• Visual Studio 2012でC# 5.0正式リリース• C# 6.0の情報が出始める• C# 7.0の提案が始まる• Visual Studio 2015でC# 6.0正式リリース201020112012201320142015潜伏期• 裏でRoslynを作ってて、言語的な新機能何もなし久しぶりに楽しい時期
Roslyn (潜伏の理由)• 新コンパイラー(製品名 .NET Compiler Platform)• 作り直し• C++コンパイラーの保守がもうつらい• Visual Studio拡張と、コンパイラー用のコード2重開発がつらい• C#チームが作っているコンパイラーの力を、Visual Studio拡張を作っているサードパーティ企業・個人開発者が活用できないのがつらい• C#でC#コンパイラーを、VBでVBコンパイラーを• 単一コンパイラーでコンパイルとVisual Studio拡張を• コンパイラーの内部データをとれるAPI公開
.NET 2015とRoslynlanguage toolruntime library ecosystemC# 6.0/VB 14 Ryu JIT.NET Native.NET Fx 4.6.NET Core 5Visual Studio2015NuGet.NET 2015新しいコンパイラーcsc.exe/vb.exeコード解析ライブラリMicrosoft.CodeAnalysis Roslynそれぞれ独立• C# 6.0で.NET Framework 2.0開発とかも可能• .NET 4.5以上をインストールすればMicrosoft.CodeAnalysis利用可能• Visual Studio 2012は最初から.NET 4.5
C# 6.0• テーマ(?): Just-do-it (いいからやれよ)• Roslyn化で手いっぱい → 大きなものが入らない• 潜伏期間が長すぎた。これ以上待たせたくない• 大きなものはC# 7.0行き• Roslynにしたからこそ → 細々とした機能を保守できる• コンパイラー自身がC#製になったから本気出す• 「よくあるパターン」のめんどくささを改善
C# 7.0 (提案開始、ディスカッション中)• テーマ• データ• Null• パフォーマンスと信頼性• コンポーネント化• 分散コンピューティング• メタプログラミングhttps://github.com/dotnet/roslyn/issues/98この辺りのテーマはC# 6.0でいくつか簡単なものが入ってる
本日はC# 6.0の方のみ• C# 6.0の新機能• Deep Dive• 用途・効能(実測)• 背景・裏話自動プロパティの改善 式形式の関数メンバーusing static null条件演算子 文字列挿入nameof 式 インデックス初期化子catch/finally内でawait 拡張メソッドでコレクション初期化子例外フィルター
プロパティやメソッドの改善• プロパティやメソッドがだいぶ書きやすく• 式形式の関数メンバー(expression bodied function members)• メソッド/演算子(expression bodies on method-like members)• プロパティ/インデクサー(expression bodies on property-like members)• 自動プロパティの改善(auto-property enhancements)• 自動プロパティ初期化子(auto-property initializers)• getter-onlyな自動プロパティ(getter-only auto-properties)
背景: よくあるコード(1)• 割と単純な計算class Calculator{public double Square(double x) { return x * x; }}
背景:よくあるコード(2)• 子オブジェクトに丸投げclass Sample1 : Sample{Sample _inner;public override string X() { return _inner.X(); }}
背景:よくあるコード(3)• readonlyにするためだけにフィールド定義class Immutable{private readonly int _x;public int X { get { return _x; } }public Immutable(int x) { _x = x; }}
背景:よくあるコード(4)• 初期化するためだけにフィールド定義class Root{private List<string> _items = new List<string>();public IList<string> Items { get { return _items; } }}
背景: 共通していえること• { return ; } うざい• しかも頻出public double Square(double x) { return x * x; }public int X { get { return _x; } }public IList<string> Items { get { return _items; } }public override string X() { return _inner.X(); }特にこいつなんて、書きたいもの(_x)に対してノイズ({ get { return ; } })が多すぎ
式形式のメソッド/演算子• returnステートメント1つだけの場合、=> を使って短縮可能• ラムダ式と同じルールpublic override string X() { return _inner.X(); }public double Square(double x) { return x * x; }public override string X() => _inner.X();public double Square(double x) => x * x;
式形式のプロパティ/インデクサー• getter-onlyな場合だけ、同様に => を使って短縮可能• { get { return ; } } を消せるpublic int X { get { return _x; } }public int X => _x;
自動プロパティ初期化子• 自動プロパティに対して初期化子が書けるように• 明示的なフィールド定義が不要にclass Root{private List<string> _items = new List<string>();public IList<string> Items { get { return _items; } }}class Root{public IList<string> Items { get; private set; } = new List<string>();}
getter-onlyな自動プロパティ• コンストラクター内でだけ初期化できる自動プロパティ• { get; } だけ書くclass Immutable{private readonly int _x;public int X { get { return _x; } }public Immutable(int x) { _x = x; }}class Immutable{public int X { get; }public Immutable(int x) { X = x; }}
没案: プライマリ コンストラクター• 当初予定では、もう1つ文法が提案されてた• C# 7.0で、より高度な新機能に統合予定• プライマリ コンストラクター(没) → レコード型(7.0)class Immutable(int x){public int X { get; } = x;}class Immutable{public int X { get; }public Immutable(int x) { X = x; }}プライマリ コンストラクター(没)未
効能• どのくらいのインパクトがあるか実測• 計測用のプログラム:• https://github.com/ufcpp/UfcppSample/tree/master/Scribble/FindSingleStatementBody• せっかくなのでMicrosoft.CodeAnalysisライブラリを利用• 今仕事で使っているソリューションを1個、集計してみた
効能: メソッド統計全体, 162600% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%式1つだけ, 8343 それ以外, 79170% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%全体のうち51.3%が => 化の恩恵を受ける
効能: プロパティ統計全体, 53850% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%getのみ, 2225 自動実装, 1690 14700% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%式1つ, 2101 自動実装, 1690 14700% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%243 1858 372 1318 14700% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%フィールドの値を返すだけ private set全体のうち39%getのみのプロパティの94.4%が => 化の恩恵を受ける
効能: プロパティ統計全体, 53850% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%getのみ, 2225 自動実装, 1690 14700% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%式1つ, 2101 自動実装, 1690 14700% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%243 1858 372 1318 14700% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%フィールドの値を返すだけ private set合計615個(全体の11.4%)※が自動プロパティの改善の恩恵受ける※ public setなものの多くがJSON化の都合でpublic。実際には書き替えしてない
using static• 静的メソッドを、メソッド名だけで呼べるように• using static構文を使うusing System;public class Program{static void Main(){Console.WriteLine("hello");}}using static System.Console;public class Program{static void Main(){WriteLine("hello");}}System.Console.WriteLine が呼ばれる
using staticの用途(1)• クラスにあまり意味がないもの• グローバル関数の代わり• Mathとかが好例using static System.Math;class MathSample{double F(int x) => x * Log(x);double G(int x) => Sin(x) * Exp(x);}数学関数ばっかり使うような文脈で、1個1個 Math. を付けたくない
using staticの用途(2)• ファクトリ メソッド• 諸事情あってコンストラクターを公開せず、メソッド越しに作るもの• Expressionとかが好例using System.Linq.Expressions;using static System.Linq.Expressions.Expression;class ExpressionSample{static ParameterExpression x = Parameter(typeof(int));static ParameterExpression y = Parameter(typeof(int));static Expression ex = Lambda(Add(x, y), x, y);}Expressionクラスの静的メソッドでインスタンス生成
元々はC#スクリプト用• Roslynの最終目標には「C#スクリプト」も入っている• (手が回っていなくて未実装)• 自作アプリに組み込んでマクロ実行• REPL上で1行1行C#ステートメントを実行• スクリプト実行時限定のつもりで機能を追加した• あまりにも要望多すぎて、通常のC#にも実装
静的プロパティ/非静的クラス• 静的プロパティ可• 静的クラスである必要ないusing static System.DateTime;using static System.Console;public class Program{public static void Main(){WriteLine(Now);}}普通の(static が付かない)クラス(こっちは静的クラス)静的プロパティ
拡張メソッド• 拡張メソッドは、静的メソッドとしては呼べない• 拡張メソッドとしては使えるLINQでおなじみのEnumerableクラスEnumerable中の拡張メソッド拡張メソッドを静的メソッドとしては呼べない
staticが付く理由• もし、staticを付けないと• 当初提案では付けなくてもよかった• 結構極悪なコードを書けてやばかったから修正using System.Linq;namespace System{public static class Linq{public static string nameof(Action x) => "";}}既存の名前空間と同名のクラス元とは別の定義を紛れ込ませられる没
null条件演算子(null conditional operator)• ?. で nullチェック + メンバー アクセス• 左辺が null だったら戻り値に null 伝搬• ?? と組み合わせるのも有効string name;if (unit == null) name = "空欄";else name = unit.Master.Name;var name = unit?.Master.Name ?? "空欄";var name = unit == null ?"空欄" :unit.Master.Name;あるいは
インデクサー/多段チェック• ?[] でインデクサーに対しても null チェック可能• 1つの式で多段チェック可能var m = team.Units?[0]?.Master;var unit = team.Units != null ?team.Units[0] :null;var m = unit != null ?unit.Master :null;
デリゲート/イベント呼び出し• ?() とは書けない• 条件演算子 ? : との区別が構文上難しい• デリゲートなら、?.Invoke で代用可能void OnPropertyChanged(string propertyName)=> PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
用途• null許容な文脈と、非null許容な文脈ははっきり分かれる• 許容する方で活躍するはず例一覧画面A B(順序・位置などに意味があるような)一覧画面では「空欄」があり得る空欄をnullで表したりC詳細画面Cweight : 327dimension: 14.6×14×3.5詳細画面では無効な項目の表示は想定しないタップで画面遷移null許容(nullable) 非null (non-nullable)
没案: null非許容• より重要なのは非nullの方• 現状のC#ではnullを認めないコードを書くのが大変• C# 7.0で検討中void ShowDetail(Unit! unit){...}(現状の案)! で非nullを明示※ 既存のC#コードを壊さないように非null対応するのはかなり大変で妥協が必要• 古いコードが混在すると100%の非null保証は無理• ! を付ける必要あり未
文字列挿入(string interpolation)• 文字列整形がだいぶ楽に• $ から文字列を始める• {} の中に任意の式が書けるstring.Format("({0}, {1})", x, y);string.Format("数値: {0:n}, 通貨: {0:c}", x);$"({x}, {y})"$"数値: {x:n}, 通貨: {x:c}"書式設定も使える
複数行• $@ から始める• ちなみに逆(@$)はダメ(コンパイル エラー)Console.WriteLine($@"x: {x}y: {y}");
string.Format化• コンパイル結果• 要望多かったのに今まで入れなかった理由は単純に「ライブラリでできることはライブラリでやれ」• まさに「just-do-it」の代表格• Roslynになって保守コストが下がったから入れれたstring.Format("({0}, {1})", x, y);$"({x}, {y})"まんま、string.Formatが生成されるだけ
IFormattable• IFormatProviderを指定したい場合• (カルチャー指定などをしたい場合)• stringじゃなくてIFormattableで受ける• .NET 4.6/.NET Core 5を必要とする唯一の機能• FormattableStringは新しく追加された型• (他は、await除けば.NET 2.0で動く)IFormattable f = $"{x:c}, {x:n}";var s = f.ToString(null, new CultureInfo("en-us"));FormattableString型のインスタンスが作られるカルチャー指定して文字列化
nameof式(nameof expression)• 識別子(変数名、メンバー名、クラス名…)を文字列リテラル化if (x < 0)throw new ArgumentException("x must be positive");if (x < 0)throw new ArgumentException(nameof(x) + " must be positive");リファクタリングの対象にならないリファクタリングの対象になる• 「リネーム」できる• 「定義に移動」できる• 「参照の検索」できる
nameof式(nameof expression)• 結構複雑な式も書けるvar now = DateTime.Now;var x1 = nameof(now.AddHours);var x2 = nameof(IList<int>.Count);var x3 = nameof(System.Text.RegularExpressions.Regex);AddHoursCountRegex
補足: CallerMemberName• PropertyChanged用途だと、こんな方法も• ただし、これでは不十分場合ありprivate int _x;public int X{get { return _x; }set { _x = value; OnPropertyChanged(); }}void OnPropertyChanged([CallerMemberName] string propertyName = null)=> PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));自動的に"X"の名前が渡る
補足: CallerMemberNameでは不十分• パフォーマンス考えるとよりよい書き方があってpublic int X{get { return _x; }set { _x = value; PropertyChanged?.Invoke(this, XProperty); }}private static readonly PropertyChangedEventArgs XProperty= new PropertyChangedEventArgs(nameof(X));同じインスタンスを使いまわす方がメモリ効率がいいこの場合、CallerMemberNameでは役に立たない
補足: CallerMemberNameでは不十分• 他のプロパティに依存したプロパティpublic int X{get { return _x; }set { _x = value; OnPropertyChanged(); OnPropertyChanged(nameof(Sum)); }}public int Y{get { return _y; }set { _y = value; OnPropertyChanged(); OnPropertyChanged(nameof(Sum)); }}public int Sum => X + Y;X, Y の一方でも変化したらSumの値も変化するこの場合、CallerMemberNameでは役に立たない
インデックス初期化子• オブジェクト初期化子内にインデクサーを書ける• 利点• オブジェクト初期化子で、プロパティと混ぜれる• 式になる• => で使える、フィールド初期化子で使える、式ツリー化できるvar d = new Dictionary<string, int>{["X"] = 1,["Y"] = 2,};
light weight dynamic• 裏にあるストーリーは結構壮大• 場合によっては、辞書的にプロパティ アクセスしたい• ライブラリ内がリフレクションだらけになったり{"Id": 10,"Position": { "X": 1, "Y": 2 }}<TextBox Text="{Binding Id}" /><TextBox Text="{Binding Position.X}" /><TextBox Text="{Binding Position.Y}" />public int X{set{_x = value;OnPropertyChanged(nameof(X));}}プロパティ名がキーの辞書
light weight dynamic• プロパティ アクセスと辞書アクセスを近づける発想var p = new Point();p.X = 1;p.Y = 2;var d = new Dictionary();d["X"] = 1;d["Y"] = 2;var p = new Point{X = 1,Y = 2,};var d = new Dictionary{["X"] = 1,["Y"] = 2,};var d = new Dictionary();d.$X = 1;d.$Y = 2;var d = new Dictionary{$X = 1,$Y = 2,};没没一瞬、こういう文法が提案されてた(キモいって言うやつ多すぎるからやめた)
Working with data• C# 7.0の大きなテーマの1つ• light weight dynamicはそのはしり• 7.0にご期待ください• レコード型、タプル型「データ」が主役var d = new Dictionary{["X"] = 1,["Y"] = 2,};低コスト、低リスクなこいつだけが6.0に残った
例外フィルター• 例外 catch に条件を付けれるように• ちなみに• C#的には新機能だけど、.NET的には1.0のころから持ってる機能• C#がそれに対応しただけtry{…}catch (Exception ex) when (ex.InnerException is IOException){…}
用途: inner exceptionでcatchstatic void Main(){try{RunAsync().Wait();}catch (InvalidOperationException){Console.WriteLine("ここを通ってほしい");}}static async Task RunAsync(){await Task.Delay(1);throw new InvalidOperationException("");}実際にここに来るのは AggregateExceptionもちろんcatchできない
用途: inner exceptionでcatchstatic void Main(){try{RunAsync().Wait();}catch (AggregateException ae)when (ae.InnerExceptions.Any(e => e is InvalidOperationException)){Console.WriteLine("ここを通ってほしい");}}
用途: 複数種の例外• 複数種類の例外に対して同じ処理try{…}catch (Exception ex)when (ex is AccessViolationException || ex is FileNotFoundException){…}
没案: if• 当初提案ではifキーワードだった• {} のちょっとした位置で意味が全く変わるとかちょっとtry{}catch (Exception ex) if (ex.InnerException is IOException) { … }try{}catch (Exception ex) { if (ex.InnerException is IOException) … }没
catch句、finally句でのawaitAsyncResource asyncResource = null;try{asyncResource = new AsyncResource();}catch (Exception ex){using (var w = new StreamWriter("log.txt"))await w.WriteAsync(ex.ToString());throw;}finally{if (asyncResource != null)await asyncResource.DisposeAsync();}catch句内でawait用途:• ログ記録(ファイル書き込みにしろサーバーに送るにしろ非同期)finally句内でawait用途:• 非同期Dispose
今までなかったのは• yield return• awaitの発想の元になっているのがyield return(awaitのコード生成結果はyield returnに近い)• yield returnはtry-catch-finally句内に書けない• 生成されるコードが結構複雑• 一度すべての例外をcatch→await→再throw的なコードに展開される• catch前のスタックトレースを保ったまま再throwする
拡張メソッドでコレクション初期化子• コレクション初期化子の結果として呼ばれるAddメソッドが拡張メソッドでもOKにvar points = new List<Point>{new Point(3, 4),};var points = new List<Point>();points.Add(new Point(3, 4));var points = new List<Point>{{ 3, 4 },};var points = new List<Point>();points.Add(3, 4);static class PointExtensions{public static void Add(this IList<Point> list, int x, int y)=> list.Add(new Point(x, y));}
今までなかったのは• コンパイル時間を気にしてのことらしい• 拡張メソッドの検索はノーコストではない• といっても、普通の拡張メソッドとそんなにコスト変わらないはず• VBは昔からできてた
まとめ• Just-do-it• Roslyn化に時間をかけすぎたのでコンパクトに• Roslynになったからこそ保守コストが下がって新機能入れやすく• ロー コスト・ロー リターンな機能ばかりだけど、確実に便利に• いくつかは、7.0の大きなテーマにつながる機能• データ:• null: null条件演算子インデックス初期化子拡張メソッドでコレクション初期化子
おまけ• ここから先、時間が残れば
その他小さな変更• これまでも、大々的に出てない小さな変更はあった• 特に、破壊的変更• Visual C# 2008 Breaking Changes• Visual C# 2010 Breaking Changes• Visual C# Breaking Changes in Visual Studio 2012• だいたいは以下の類• 新機能の余波でオーバーロード解決順序変わりました• バグだったのでなおしました• Roslynオープンソース化で、こういう小さな変更も見えやすくなった
C# 6.0の破壊的変更(1)• コンストラクターの再帰循環参照• 昔: 実行時にスタック オーバーフロー• C# 6.0: コンパイル エラーclass C{public C(int x) : this() { }public C() : this(0) { }}
C# 6.0の破壊的変更(2)• generic型インスタンスに対するlock• 昔: コンパイル通るものの、値型の場合lockの意味ない• C# 6.0: class制約が必須にpublic void DoSomething<T>(T data){lock (data) { } // << Generates CS0185}public void DoSomethingElse(SOptions data){lock (data) { } // << Works fine}public void DoSomething<T>(T data) where T : class{lock (data) { } // Works fine}
C# 6.0の破壊的変更(3)• generic型の静的readonlyフィールドに対する書き込み• 昔: 他の特殊化に対して初期化できる• C# 6.0: 自分自身だけを初期化できるpublic static class Foo<T>{static Foo(){if (typeof(T) == typeof(int)){Foo<int>.compute = x => (int)x;}}public static readonly System.Func<double, T> compute;}
日本人だけが気づく破壊的変更• Unicodeの変更の影響• 昔: カタカナ中点(中黒)OK• C# 6.0: Unicode側のミスでした。Unicodeが修正したらC#にも影響出ましたint x・y = 10;Console.WriteLine(x・y);
微妙な新機能(1)• enumの基底型• 昔: int, short, long など、キーワードでないとダメ• C# 6.0: Int32, Int16, Int64 など、System名前空間の型でもOKenum X : System.Int32{A, B, C,}
微妙な新機能(2)• オーバーロード解決ルールを改善• 昔: ラムダ式の型推論、1段は行けてたけど2段は無理だった• C# 6.0: 2段以上もOKusing System;class FuncOfFuncTypeInference{static void Main(){X(() => () => 10);}private static int X(Func<Func<int>> f) { return f()(); }private static int X(Func<Func<int?>> f) { return f()() ?? 0; }}int か int? か古いコンパイラーは判定できない
追悼• 一瞬、C# 6.0に入る予定だったもの• 互換性壊れるので取りやめたり• 引数なしの構造体コンストラクター• C# 7.0で改めて取り組むことになったり• プライマリ コンストラクター → レコード型• 変数宣言式 → パターン マッチング
追悼: 構造体の引数なしコンストラクター• 構造体にも引数なしのコンストラクターを定義できるようにするはずだった• .NETのランタイム レベルでバグがあることが発覚して断念• Activator.CreateInstance<T>() が new T() をnullに置き換えるstruct MyInt{public readonly int Value;public MyInt() { Value = -1; }public MyInt(int value) { Value = value; }}没
追悼: プライマリ コンストラクター• 型定義の型名の直後にコンストラクターを1個書けた• 7.0でレコード型に吸収予定class Immutable(int x){public int X { get; } = x;}class Immutable(int x) { } 未未
追悼: 変数宣言式(declaration expressions)• 式の途中で変数宣言できた• 7.0でパターン マッチングと合わせて作り直す予定while ((var line = Console.ReadLine()) != null)if (int.TryParse(line, out var x))(var y = Math.Sin(x)) * y;if (x is string s) { … }else if (x is int n) { … }未未

Recommended

PPTX
Orange Cube 自社フレームワーク 2015/3
PPTX
C# 9.0 / .NET 5.0
PPTX
.NET Core 2.x 時代の C#
PPTX
C# design note sep 2014
PPTX
C# 8.0 非同期ストリーム
PPTX
C# 8.0 Preview in Visual Studio 2019 (16.0)
PPTX
今から始める、Windows 10&新.NETへの移行戦略
PPTX
C#言語機能の作り方
PPTX
C# 7.2 with .NET Core 2.1
PPTX
C#/.NETがやっていること 第二版
PDF
基礎からのCode Contracts
PDF
今日からできる!簡単 .NET 高速化 Tips
PDF
今からでも遅くないC#開発
PDF
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
 
PDF
動的なILの生成と編集
PPTX
Modern .NET
PPTX
C#の書き方
PPTX
C#や.NET Frameworkがやっていること
PDF
Observable Everywhere - Rxの原則とUniRxにみるデータソースの見つけ方
PDF
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
PDF
Inside FastEnum
PDF
Boost.勉強会#19東京 Effective Modern C++とC++ Core Guidelines
PDF
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
PDF
知って得するC#
PPTX
Net fringejp2016
PDF
UniRx - Reactive Extensions for Unity
PDF
C++でCプリプロセッサを作ったり速くしたりしたお話
PDF
An Internal of LINQ to Objects
PDF
C#勉強会 ~ C#9の新機能 ~
PPTX
C#6.0の新機能紹介

More Related Content

PPTX
Orange Cube 自社フレームワーク 2015/3
PPTX
C# 9.0 / .NET 5.0
PPTX
.NET Core 2.x 時代の C#
PPTX
C# design note sep 2014
PPTX
C# 8.0 非同期ストリーム
PPTX
C# 8.0 Preview in Visual Studio 2019 (16.0)
PPTX
今から始める、Windows 10&新.NETへの移行戦略
PPTX
C#言語機能の作り方
Orange Cube 自社フレームワーク 2015/3
C# 9.0 / .NET 5.0
.NET Core 2.x 時代の C#
C# design note sep 2014
C# 8.0 非同期ストリーム
C# 8.0 Preview in Visual Studio 2019 (16.0)
今から始める、Windows 10&新.NETへの移行戦略
C#言語機能の作り方

What's hot

PPTX
C# 7.2 with .NET Core 2.1
PPTX
C#/.NETがやっていること 第二版
PDF
基礎からのCode Contracts
PDF
今日からできる!簡単 .NET 高速化 Tips
PDF
今からでも遅くないC#開発
PDF
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
 
PDF
動的なILの生成と編集
PPTX
Modern .NET
PPTX
C#の書き方
PPTX
C#や.NET Frameworkがやっていること
PDF
Observable Everywhere - Rxの原則とUniRxにみるデータソースの見つけ方
PDF
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
PDF
Inside FastEnum
PDF
Boost.勉強会#19東京 Effective Modern C++とC++ Core Guidelines
PDF
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
PDF
知って得するC#
PPTX
Net fringejp2016
PDF
UniRx - Reactive Extensions for Unity
PDF
C++でCプリプロセッサを作ったり速くしたりしたお話
PDF
An Internal of LINQ to Objects
C# 7.2 with .NET Core 2.1
C#/.NETがやっていること 第二版
基礎からのCode Contracts
今日からできる!簡単 .NET 高速化 Tips
今からでも遅くないC#開発
Hello, C++ + JavaScript World! - Boost.勉強会 #11 東京
 
動的なILの生成と編集
Modern .NET
C#の書き方
C#や.NET Frameworkがやっていること
Observable Everywhere - Rxの原則とUniRxにみるデータソースの見つけ方
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
Inside FastEnum
Boost.勉強会#19東京 Effective Modern C++とC++ Core Guidelines
What, Why, How Create OSS Libraries - 過去に制作した30のライブラリから見るC#コーディングテクニックと個人OSSの...
知って得するC#
Net fringejp2016
UniRx - Reactive Extensions for Unity
C++でCプリプロセッサを作ったり速くしたりしたお話
An Internal of LINQ to Objects

Similar to Deep Dive C# 6.0

PDF
C#勉強会 ~ C#9の新機能 ~
PPTX
C#6.0の新機能紹介
PPTX
復習も兼ねて!C#6.0-7.0
PDF
20141129-dotNet2015
PDF
C#の新機能勉強会 ~ C#7、8の新機能を活用して速く安全なプログラムを書こう~
PPTX
.NET Compiler Platform
PPTX
Visual basic14 の話
PDF
C#勉強会
PDF
Unity2015_No10_~UGUI&Audio~
 
PPTX
Live Coding で学ぶ C# 7
PPTX
Microsoft Learn で C# を学ぶとどんな感じ?
PPTX
C# 8
PPTX
Unity C#3からC#6に向けて
PPTX
C# 7 Current Status
PPTX
最速C# 7.x
PDF
C#coding guideline その2_20130325
PPTX
C#10
PDF
【Unite Tokyo 2019】Understanding C# Struct All Things
PPTX
C# 7・8 の復習
PPT
CLR/H No.35-2
C#勉強会 ~ C#9の新機能 ~
C#6.0の新機能紹介
復習も兼ねて!C#6.0-7.0
20141129-dotNet2015
C#の新機能勉強会 ~ C#7、8の新機能を活用して速く安全なプログラムを書こう~
.NET Compiler Platform
Visual basic14 の話
C#勉強会
Unity2015_No10_~UGUI&Audio~
 
Live Coding で学ぶ C# 7
Microsoft Learn で C# を学ぶとどんな感じ?
C# 8
Unity C#3からC#6に向けて
C# 7 Current Status
最速C# 7.x
C#coding guideline その2_20130325
C#10
【Unite Tokyo 2019】Understanding C# Struct All Things
C# 7・8 の復習
CLR/H No.35-2

More from 信之 岩永

PPTX
YouTube ライブ配信するようになった話
PPTX
C# コンパイラーの書き換え作業の話
PPTX
Unicode文字列処理
PPTX
C# 8.0 null許容参照型
PPTX
async/await のしくみ
PPTX
Unityで使える C# 6.0~と .NET 4.6
PPTX
それっぽく、適当に
PPTX
Code Contracts in .NET 4
PPTX
今から始める、Windows 10&新.NETへの移行戦略
PPTX
.NET vNext
PPTX
Coding Interview
PPTX
非同期処理の基礎
PPTX
C#とILとネイティブと
PPTX
プログラミング .NET Framework 第4版
PPTX
Anders Hejlsberg Q & A
PPTX
C#マスコット(公開用)
PPTX
広がる .Net
YouTube ライブ配信するようになった話
C# コンパイラーの書き換え作業の話
Unicode文字列処理
C# 8.0 null許容参照型
async/await のしくみ
Unityで使える C# 6.0~と .NET 4.6
それっぽく、適当に
Code Contracts in .NET 4
今から始める、Windows 10&新.NETへの移行戦略
.NET vNext
Coding Interview
非同期処理の基礎
C#とILとネイティブと
プログラミング .NET Framework 第4版
Anders Hejlsberg Q & A
C#マスコット(公開用)
広がる .Net

Deep Dive C# 6.0

Editor's Notes

  • #3 潜伏期:MSのWebへの投資が増えた → AndersがTypeScript方面にWin8で必死 → WinRT開発で手いっぱい将来への投資 → .NET CoreとかRoslynがほんと裏に潜伏してて、表立った話が全然なかった今まで、「2.0正式リリースの瞬間にもう3.0の話」みたいなのが普通だったのに、初めて、2年くらい空白開けた
  • #6 要するに、割かしローリスク・ローリターンな手堅いバージョン。
  • #7 機会があればまた
  • #14 頻出でなければ「それくらい耐えろ」って言うんだけど。さすがにものすごく多くて。
  • #23 それに、今までは面倒だから妥協して緩い書き方してたところを、ちゃんとした書き方に変える気が起きるって意味で、もっと増えると思う。
  • #24 この機能はそこまでインパクト大きくないんだけど。
  • #26 諸事情 = 静的なファクトリ メソッドがある理由は:・引数に応じて実際に作る型を変えたいとき・型推論かけたいとき (ジェネリック型のコンストラクターは型推論効かない)・1つの型にまとめたいとき(この例のExpressionみたいな)
  • #27 最近、やっと動き出してて、Roslynリポジトリをのぞくと実装が入り始めてる。ただ、VS 2015には間に合わないと思う。
  • #29 無駄にコード補完候補を増やしてもしょうがない。拡張メソッドを静的メソッドの記法で呼びたいこととかあまりない。
  • #30 これ、報告入れたら速攻で修正(using → using static)入ってた。
  • #37 interpolated string、複数行にはできないの? → すでにできるよ $@ で → すまん @$ で試してたみたいな会話見たことあり。
  • #38 ある意味、一番C# 6.0らしい機能かも。
  • #39 C# 6.0の中でも割かし最後の方に実装された機能。カルチャー指定の仕方で結構迷ってた。
  • #40 この手の、例外メッセージややトレース メッセージが一番の用途になるとは思う。
  • #49 ちなみに、これはC#的には新機能だけど、.NET的には1.0のころから持ってる機能。C#がそれに対応しただけ。
  • #50 非同期処理のせい。
  • #53 新しいキーワードを足す必要がないって意味ではよかったんだけども。
  • #60 互換性壊さないように注意を払ってるので、言語構文の破壊的変更によって既存コードがどのくらい影響受けるか、大量の既存ソースコードをビルドしてみて確認作業してるらしい。
  • #66 こういうのをbetternessルール(型がよりマッチした方を選ぶというルール)っていうこれ、仕様書のレベルで考慮不足があったらしくて、仕様書から書き替え(厳密化)したらしい
  • #71 オープンソースな人はずっと通ってきた道だと思うけども

[8]ページ先頭

©2009-2025 Movatter.jp