はてなブックマーク

以下の ~Class1 のこと、（C# の言語機能名として)なんと呼びますか？ class Class1 { public Class1() { } ~Class1() { } } すごく今更ながら、8年くらい前からこれの呼び名が変わってたらしいというのを最近気づいたという話になります。 ちなみに結果だけ言うと、旧称がデストラクター(destructor)、今はファイナライザー(finalizer)です。 他の言語とかの話 C# がかつてこいつのことをデストラクターと読んでいたのは C++ 由来です。 ただ… 文法は確かに同じで、C++ も ~Class1 な文法がある これのことをデストラクターと呼ぶ ただし、挙動は C# のものと違っていて、呼ばれるタイミングは「変数のスコープを抜けるとき」 C# は文法こそ同じなものの、実際にはそれはファイナライザーだった Java の finali

「Rosly の Language Feature Status に並んでいるもののうち、すでに preview 提供済みのものシリーズ第3段。 field キーワード First-class Span nameof(T<>) ← 今日はこれ すでに今、LangVersion に preview を指定すれば利用可能です。 今日は最後の1個の nameof(T<>) の話です。 当初「3つまとめて1ブログにする予定」だった原因。 こいつだけ対して書くことがなく… 今日のやつは Visual Studio 17.13.0 Preview 2 (.NET 9 の正式リリースの次のアプデ)で merge 済みです。 nameof 演算子の中に unbound な型を書けるようになりました。 unbound (未束縛)というのは、List<> みたいに、型実引数を渡してなくて(<> の中に何も書か

「Rosly の Language Feature Status に並んでいるもののうち、すでに preview 提供済みのものシリーズ第2段。 field キーワード First-class Span ← 今日はこれ nameof(T<>) すでに今、LangVersion に preview を指定すれば利用可能です。 今日は First-class Span。 (これも昔1回取り上げてるんですが、案外書くことあり。) First-class Span C# 7.2 の頃に Span<T> や ReadOnlySpan<T> が導入されて以来、 これらの型を使った高パフォーマンスな API がたくさん提供されています。 また、C# 12 で入ったコレクション式や、 C# 13 で入った params コレクションでは、 T[] や IEnumerable<T> よりも Span<T>

「Rosly の Language Feature Status にこの1・2か月で結構更新かかったね」という話題もたびたびあり、その辺りの話を。 Language Feature Status に並んでいるもののうち、いくつかは preview として現時点でもうすでに取り込まれています。 field キーワード ← 今日はこれ First-class Span nameof(T<>) 今(執筆時、Visual Studio 17.13.0 Preview 2.1)の時点でも、 LangVersion に preview を指定すれば利用可能です。 最初は3つまとめて1ブログにしようかと思ってたんですが、 案外長くなったので個別に。 今日は field キーワードの話になります。 (昔のブログを参照して「やっと入ったよ」だけ書いて終わりかと思ったら案外新規に書くことがあり。) プロパティ

今日は C# 配信をやっててちょくちょく話題になるやつの話。 using System.Text; using System.Text.Unicode; var buffer = (stackalloc byte[3]); Utf8.FromUtf16("abc", buffer, out var r, out var w); Encoding.UTF8.GetString(buffer[..w]); Utf8 なの？ UTF8 なの？ (昔1回同じ話題でブログ書いた気がしつつ、最近もまた話題に出たので。) .NET の命名ガイドライン .NET には命名規約に関するガイドラインがありまして、以下の場所にドキュメントとして残っています。 Capitalization Rules for Identifiers おおむね以下のようなルール。 クラス名などは PacalCase を使ってくださ

こないだにつづき、C# 言語機能としては没ネタ。 最終的な結論が「ライブラリでやれ」 → 「.NET 10 でメソッド追加を検討」です。 剰余の利用例 剰余演算(C# だと % 演算子)の用途として、 「配列の範囲内に収めるために index % array.Length する」とかがあると思います。 例えば以下のような感じ。 var table = new Table([1, 2, 3, 4, 5]); for (var i = 0; i < 5; i++) Console.WriteLine(table.Next()); // 引数で受け取った配列の中身を1個ずつ返す。 struct Table(int[] values) { private int _index; public int Next() { var i = _index; var x = values[i]; _inde

今日のは、C# 言語機能としては否決されたものの、ほぼ同等のものがライブラリと JIT 時最適化で実現されたという話になります。 ちなみに今日のこの話は .NET 8 の頃の話で、「そういえば去年書いてなかった」ネタになります。 UTF-8 リテラルがあるなら C# 11 で UTF-8 リテラルが入って、 C# プログラム中に UTF-8 なバイト列を ReadOnlySpan<byte> で直接埋め込めるようになりました。 ReadOnlySpan<byte> hex = "0123456789ABCDEF"u8; 割かし何度も書いてたりはしますが、 もう今となっては世の中の多くの文字列が UTF-8 でやり取りされています。 .NET の string が UTF-16 ベースなので、UTF-16 ⇔ UTF-8 の変換がそれなりのコストになっていたりします。 そこで、いろんなものを

かなりのレアケースを踏んだので酒の肴程度にその話を。 破壊的変更の内容: 浮動小数点数 → 整数の飽和変換 破壊的変更の告知ページ: Floating point-to-integer conversions are saturating 最小再現コードは以下の通り。 var x = int.MaxValue; var y = (float)x; var z = (int)y; Console.WriteLine(z); z の値は、 .NET 8 では -2147483648 (int.MinValue) になって、 .NET 9 では 2147483647 (int.MaxValue) になります。 (注意: float の精度の問題で、y の値は int.MaxValue よりも大きい扱いを受けていそうです。 double では2行目を var y = (double)x + 1;

概要 Ver. 2.0 C# 2.0 で、partial 修飾子を付けることで、クラスや構造体、インターフェイスを複数のファイルに分けて型を定義できるようになりました。 この partial によるファイルの分割は、 「片方のファイルを手書き、もう片方のファイルを開発ツールなどによって自動生成」みたいな状況を想定しています。 (それ以外の用途でむやみに複数のファイル分けると、どのファイルに何のメソッドがあるのか探しにくくなるので、 通常は、むしろ、クラス定義を複数のファイルに分割しない方がいいです。) 背景: ツール生成のソースコード Visual Studio などの統合開発環境を利用していると分かると思いますが、 ソースファイルの一部分はプログラマーの手書きではなく、 開発ツールが自動的に生成してくれる部分があります。 例えば、データベースのテーブル定義から C# のクラスを生成するみ

概要 複合型(クラスや構造体)では、フィールドをメモリ上にどうレイアウト(layout: 配置)するかという問題があります。 通常、メモリ上のレイアウトがどうなっているのかをプログラマーが気にする必要はありません。 大体はコンパイラーが最適な仕事をしてくれます。 それでも、時々、レイアウト方法を明示的に指定したい場合があります (おそらく、そのほとんどはC++などで書かれたネイティブ コードとの相互運用です)。 そこで、プログラミング言語によってはレイアウトをカスタマイズするための機能を提供しているものもあります。 C#では、クラスと構造体に対してレイアウトのカスタマイズ機能を提供しています。 StructLayout属性を付けることでカスタマイズ可能です。 アラインメント 「最適なレイアウト」について説明するためには、まず、メモリのアラインメント(alignment: 整列、調整)につい

執筆予定: C# 13.0 トラッキング issue params コレクション コレクション式で使える型であれば何でも params にできるようになりました。 static void M1(params List<int> x) { } static void M2(params IEnumerable<int> x) { } static void M3(params Span<int> x) { } static void M4(params ReadOnlySpan<int> x) { } M1(1, 2); M2(1, 2); M3(1, 2); M4(1, 2); 需要が高いのは ReadOnlySpan で、 params T[] を params ReadOnlySpan<T> に変更すればそれだけでパフォーマンスの改善が見込めます。 実際、 .NET 9 では、stri

今日は、 .NET 9 で Lock クラスというのが入る予定で、 それに伴って C# コンパイラーにも対応が必要そうという話。 一応雰囲気的には C# 13 に入りそう。 任意のオブジェクトを lock C# はなぜか任意のオブジェクト インスタンスを使って排他制御ができます。 ロックを掛けるために以下のようなコードを書くことになります。 class MultiThreadCode { private readonly object _syncObj = new object(); public void Run() { lock (_syncObj) { // いろんなスレッドから同時に呼ばれるコード。 } } } Java からの習慣(= 1995年頃の発想)ですかね。 Java の synchronized ブロックも同じ仕様のはず。 本来の思想としては「lock() の () 内

C# 3.0 から拡張メソッドが使えるわけですが、 もうちょっといろんな「拡張」をしたいという話が前々からあります。 例えば以下のような要求。 既存の型に静的メンバーも足したい プロパティや演算子も足したい インターフェイスの後付けもしたい 今では Extensions とか呼ばれていまして、以下の issue でトラッキング中。 Exploration: Shapes and Extensions #164 ここからさかのぼって、かつては Extension everything とか呼ばれていたり、 個別に「インターフェイスを実装したい」「演算子を拡張したい」など個別の issue がありました。 Extension Everything Extension classes with Interfaces Extension operators 2015年(Roslyn が GitHu

C# 13でのコレクション式関連、量が多いのでちょっとずつ取り上げシリーズ。 [Proposal]: Collection Expressions Next (C#13 and beyond) 今日はディクショナリ式の話を。 ディクショナリ式 ← 今日はこれ 自然な型 インラインなコレクション式 コレクションに対する拡張メソッド 現状でコレクション式に対応してない型 非ジェネリックなコレクションのサポート 制限の緩和 C# 12 でコレクション式が入りましたが、Dictionary<TKey, TValue> などのディクショナリ系の型に対しては使えませんでした。 // C# 12 でも空っぽのディクショナリは作れるのに… Dictionary<string, int> d = []; // 要素があるものは書く手段がない(以下はいずれもエラー)。 // スケジュールの都合で意図的に「C#

C# 12 でコレクション式が入ったわけですが、 スケジュールの都合で「C# 12 後に改めて検討する」ということになった機能がたくさんあります。 C# 12 リリース(2023/11)直後から再検討が始まっていて、先月にはある程度まとまった計画が出ています。 [Proposal]: Collection Expressions Next (C#13 and beyond) 量が多いのでちょっとずつ取り上げ… ディクショナリ式 自然な型 インラインなコレクション式 コレクションに対する拡張メソッド 現状でコレクション式に対応してない型 非ジェネリックなコレクションのサポート 制限の緩和 ← 今日はこれ 今、コレクション式の要素の型は IEnumerable<T> の T で判定しています。 using System.Collections; foreach (var x in new A(

.NET が長らく抱えている「なぜ IList<T> は IReadOnlyList<T> ではないのか」問題、 .NET 9 で解消するかもしれないみたい。 ちなみに、問題を抱えるに至った原因は IReadOnlyList<T> が後付けということです。 1から作り直すのであれば、誰がどう考えても IList<T> は IReadOnlyList<T> から派生させるのが自然です。 それがかえって、IReadOnlyList<T> 導入以降に .NET 利用を始めた人に混乱を招いているというのが現状になります。 当初設計: インターフェイスは増やしすぎない インターフェイスを増やすというのは、 型情報で DLL サイズが増えるとか、 実行時にインターフェイスを検索するコストが増えるとか、 多少なりともコストを生じます。 一方で、.NET Framework の最初のβ版が出たのは2000

ほぼ1年ぶりの params の話。 params を配列以外のコレクションに対して使えるようにするという話ですが、 雰囲気的に C# 13 でついに 入りそうです。 なので、最近そこそこ高頻度で Language Design Meeting の議題に上がっています。 Params Collection C# Language Design Meeting November 15th, 2023 January 29th, 2024 January 31st, 2024 February 21st, 2024 まあ、割かしもう詳細を詰めている感じの話題が多めですね。 params ‘コレクション’ 去年には「ReadOnlySpan<T> 以外需要低め」、「他はコレクション式を使って M([a, b, c]) でいいのでは」などという話も出ていましたが。 コレクション式を実装した今改めて

ラムダ式で、ref 引数などに対して ref x => { } みたいに書けるようにしたいという話が出ています。 ラムダ式での ref 引数、out 引数 ラムダ式は、状況が許すなら、x => { } などといったように非常に簡素に書けます。 ところが、ref や out が絡むとそうもいかなくて、型推論が効く状況でも型名を省略できません。 // 通常、ラムダ式は型推論が効く限り、引数の型を省略できる。 Action<int> a = x => { }; // ところが ref, out などの修飾が付いた引数は省略不可。 // これなら OK。 RefAction<int> r = (ref int x) => { }; OutFunc<int> o = (out int x) => x = 1; // ダメ。CS1676 エラー。 RefAction<int> r1 = x => {

C# 13 向けに検討されている機能の一つに、 「半自動プロパティ」とか「field キーワード」と呼ばれているものがあります。 元々は C# 12 向けに考えられていて、去年、うちのブログでも書いているやつです。 【C# 12 候補】半自動プロパティ 簡単におさらいすると、 プロパティの get/set アクセサー内で、field を使って バッキング フィールド(自動プロパティの値を保存するためにコンパイラーが生成するフィールド)に明示的にアクセスするというものです。 class A { // 手動プロパティ (manual property) // (と、自前で用意したフィールド)。 // こういう、プロパティからほぼ素通しで値を記録しているフィールドを「バッキング フィールド」(backing field)という。 private int _x; public int X { ge

今日は「負の遺産整理で消したいけども消せないメソッド対処」の話。 紆余曲折合って、現状、OverloadResolutionPriority 属性でオーバーロード解決に優先度をつけて、 優先度の高いものだけを見るようにするという案になっています。 最近のわかりやすい例だと、「パフォーマンス改善のために配列引数を ReadOnlySpan 引数に変えたい」というのをやりたいとします。 元々、配列引数で作っていたとして、 int[] x = [1, 2, 3]; C.M(x); // 元コード。 public class C { // これの引数を変えたい。 public static void M(int[] x) { } } 暗黙的型変換があるものであれば、多少型を変えても「再コンパイルすれば大丈夫」という状態になることはあります。 int[] x = [1, 2, 3]; // int[

C# のジェネリック型引数の推論を賢くしたいという話は、issue として記録されている分に限っても5年くらい前からあります。 Champion: "Partial Type Inference" 現状の C# の型推論は割と "All or Nothing" で、 new() みたいに型全体の省略はできても、new List<>() みたいな「一部分だけ省略」ができません。 // 型全体の推論は可能。 // 左辺から型が決定されて、new() は new List<int>() と解釈される。 List<int> x1 = new(); // 一方、型引数だけの省略というのができない。 List<int> x2 = new List<>(); // 要は Java のダイヤモンド演算子みたいなのとか、 List<int> x3 = new List<_>(); // あるいは「ここは推論

今日は「Span<T>、ReadOnlySpan<T> をコンパイラーで特別扱いしたい」という話。 C# 7.2 の頃、Span<T> 型が追加されて、 安全性を損なわずに unsafe コード並みにパフォーマンスのよいコードが書けるようになりました。 それ以来、.NET の標準ライブラリでもいろんな場面でSpan<T> 型が活用されています。 いまや結構重要なポジションを担う型なわけですが、 現状の扱いはあくまで「普通の構造体の1つ」です。 そのため微妙にオーバーロード解決とかで困り気味。 例えば直近では、C# 12 でコレクション式を導入するにあたって「普通にやってたら使い勝手が悪いので Span を特別扱い」みたいなことをやっています。 // 普通にやると IEnumerable と Span の優先度はつかなくてコンパイルエラー。 EnumerableVsSpan.M(new in

「最近動きがあったもの」ブログをいくつか書いてて、 「続報」みたいなものも書いてるわけですが。 今日のも「まあ、去年から動く実装すでにあるんだけど」という意味では続報なものの、 今日のインターセプターはあまりうちのサイトで取り上げておらず、初めて説明を書く話。 (ライブ配信では時々話に出てるんですが。) 今日話すインターセプターは、まあ、Source Generator向けの機能です。 既存の Source Generator でも、 クラスを丸ごと生成するとか、メソッドの中身を生成とかはできます。 .NET が標準で提供しているやつだと GeneratedRegex とか。 partial メソッドに属性を付けて、メソッドの中身をコード生成しています。 partial class Reg { // この属性を付けた partial メソッドに対して、 // Sytem.Text.Regu

ref 構造体で説明しているように、 Span<T> 型など一部の型は「スタック上にないといけない」という強い制約があります。 この制約を守るため、これまで、ref 構造体は インターフェイスを実装できなかった ジェネリック型引数に使えなかった という制限が掛かっていました。 C# 13 では、この制限を緩和するため、 ジェネリック型引数に「allows ref struct」という「アンチ制約」を追加する予定です。 こういう案自体は ref フィールドが追加された C# 11 (2022年)の頃から温められてはいたんですが、 いよいよ C# 13 で本格的に取り組むみたいです。 .NET 8/C# 12 がリリースされた後くらいからちらほら提案ドキュメントの更新あり。 Add draft for demonstrating ref-struct-constraint soundness