時代は既に what's next for VS

[ufcpp]

配信URL: https://youtu.be/7-E3GYiQU9o

https://twitter.com/davkean/status/1453327616316895232 やっぱ最近どんどん重たくなってる自覚ありそう ＜ started planning what's next for VS performance and responsiveness.

久しぶりに話題に登ったの:

• Defaultable Value Types (csharplang 5337)
  • Nullable<T> で使っちゃってるから T? 使えないという (提案中では仮に T~)
  • これがないと default(T) だけで NRT 解析に穴ができる
• UTF8 String Literal
  • 最近「もう UTF8 使いたいときは ROS<byte> で」が既成事実化しており
  • 文字列リテラルの ROS<byte> への暗黙的変換として UTF8 リテラル用意するだけでよさげな雰囲気に
  • ただ、オーバーロード解決問題があり、 1L とか 1.2f とかと同様、 ""u8 みたいなオプションな接尾辞は用意しそう

割かし最近配信で話題にしてたのののちゃんとした提案出た:

• Collection literals (csharplang 5354)
  • []
  • 配列、Span, ROS、コレクション初期化子対応の型(List<T> とか)向け
  • ImmutableArray<T> みたいな現在のコレクション初期化子未対応な型向けの新仕様も足したい
  • [1, ..anotherList] みたいに、.. で spread もしたい
• ROS<T>.CreateSpan<T> (runtime 60948)
  • 今 byte, sbyte 以外の ROS 最適化(配列アロケーションなしで data セクション生で読む)が効かないの、やっぱエンディアンの問題とのこと

関連 LDM:

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-20.md https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-25.md https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-27.md

前述のもの以外に:

• デリゲートのref型引数とか、「タプル名同様、属性で引数名残すか」話
• (record 以外の) primary constructor と required property の話

[ufcpp]

https://twitter.com/ufcpp/status/1450316471595196416 これも前回の配信以降の話だった。

[ufcpp-live]

using System.Reflection;

ReadOnlySpan<byte> t = new byte[] { (byte)'t', (byte)'r', (byte)'u', (byte)'e' };
ReadOnlySpan<byte> f = new byte[] { (byte)'f', (byte)'a', (byte)'l', (byte)'s', (byte)'e' };
ReadOnlySpan<byte> n = new byte[] { (byte)'n', (byte)'u', (byte)'l', (byte)'l' };

Dictionary<byte[], PropertyInfo> d = new();

d.TryGetValue(new byte[1], out var p); // ここの new[] がいやだから専用辞書も持ってる

[ufcpp-live]

// デファクトスタンダード化してる Span/ROS<byte> に対して "" で UTF-8 化する提案。
Span<byte> m = "mutable";
ReadOnlySpan<byte> t = "true";
ReadOnlySpan<byte> f = "false";
ReadOnlySpan<byte> n = "null";

C.M("どっちを呼ぶ？"); // 当然 string
C.M((ReadOnlySpan<byte>)"どっちを呼ぶ？"); // 明示すればもちろん行ける予定。
C.M("どっちを呼ぶ？"u8); // 接尾辞付けるか案。

var s = ""u8; // 接尾辞があるのであれば var で受けられる。

//long l = 1; // 別に OK。
//var i = 1; // int になっちゃう。
//var l1 = 1L; // long を強制。

class C
{
    public static void M(string s) { }
    public static void M(ReadOnlySpan<byte> s) { }
}

// 日に日に可能性下がってはいるものの、
// まだ可能性 0 ではない。
// 将来追加されても UTF-8 リテラルが破綻しないようにだけはしないとダメ。
class Utf8String { }

//System.Text.Unicode.Utf8
//System.Buffers.Text.Utf8Formatter.TryFormat

[ufcpp-live]

[ufcpp-live]

// double.Parse に依存してコンパイラーを作ってたら、
// .NET が仕様変更して「破壊的変更」になりかけた。
// (.NET 5 のとき、IEEE 準拠のための変更)
// double.Parse 使うのやめて、自前 Parse に切り替えたらしい。
double x = 1.111111111111111111111111111;

// これはさすがに Encoding.UTF8.GetBytes 依存を認めようか？
// みたいなの議論中。
ReadOnlySpan<byte> s = "a あ 亜 ☺";

[ufcpp-live]

var d = new D { Name = "abc" };

Console.WriteLine(d.Name.Length);

d = default;

// VS 2022 でちゃんと警告になった！
// (いつからかは覚えてない)
Console.WriteLine(d.Name.Length); // ぬるぽ

if (d.Name is not null)
{
    Console.WriteLine(d.Name.Length);
}

static void m(D d)
{
    Console.WriteLine(d.Name.Length); // これは警告出なくなる
}

m(default); // これも怒られない(これがまずい)

// D? はもはや使えない。
// 初期の提案では D?? だったけど… (null coalescing の ?? と区別つかないから却下)
// 提案ドキュメント上は暫定 ~ で説明。
// (下手な文法足すに足せなくて属性になる可能性もある)
static void m1(D~ x)
{
    Console.WriteLine(x.Name.Length); // ここに警告を出す予定
}

m1(default); // これは OK (予定)
m(default); // ここに警告を出したい。

struct D
{
    public string Name;
}

[ufcpp-live]

// 現状、非 null 参照型に代入があるかで default かどうかを判定。
// ただ…
struct PositiveInteger
{
    public int Value;

    // カスタム defaultability
    public static bool operator default(PositiveInteger x) => x == 0;
}

// こういうカスタムなやつがいるということは…
// 非 null の癖に == null を自称する参照型な輩にも対応要る？
// (主に UnityEngine.Object)

[ufcpp-live]

int[] array = [ 1, 2, 3 ];

// ついでに spread 対応。
Span<int> span = [ 0, ..array, 4 ];

// 対となるパターン。
if (span is [ .., 4 ])
    Console.WriteLine("true になるはず");

if (span is [ 0, .. ])
    Console.WriteLine("true になるはず");

[ufcpp-live]

// 検討には上がってないけども…
// JavaScript とかではできるやつ
m(..array);

var t = (1, 2, 3);
m(..t);

void m(int x, int y, int z) { }

[ufcpp-live]

using System.Collections.Immutable;

int[] array = [1]; // 配列OK
Span<int> s = [1]; // Span OK
ReadOnlySpan<int> rs = [1]; // ROS OK
List<int> rs = [1]; // 既存のコレクション初期化子対応の型は OK

// 追加の文法が必要。
// Immutable コレクション初期化子が求められる(やりたい)。
ImmutableArray<int> i = [1];

//↓
Span<int> temp = [1];
ImmutableArray<int> i = default;
i.Init(temp); // 「init メソッド」が別途必要。

struct ImmutableArray<T>
{
    // init メソッドを用意させたい。
    // (init プロパティ同様 modreq 実装の予定。)
    public init void Init(ReadOnlySpan<T> buffer) { }
}

[ufcpp-live]

int[] a = [1, 2, 3];
List<int> b = [0, ..a];

// これは foreach (var i in a) b.Add(i); であるべきか、
// a.AddRange(a); であるべきか。
//
// a.GetEnumerator() の時点でアロケーションあるので、AddRange の方が遅い。

[ufcpp-live]

natural type 問題

// これを認めるべき？
// デリゲートですら natural type を持った昨今。
// 何がいいか決まらない…
// List しか全要件を満たす型がないけど、List はアロケーション的に不利。
// 昨今の immutable ブームを考えると ROS か ImmutableArray/ImmutableList にしたい…
var a = [1, 2, 3];

[ufcpp-live]

[] VS {} 問題

if (a is { }) ; // プロパティパターンとの弁別的に、これを List パターンにはできない

var b = { 1, 2, 3 }; // これは Block expressions にとっておきたい。

// 今でも、block bodied lambda との区別厳しい。
var f = x => { };
var f = x => [];

[ufcpp-live]

「」『』〈〉【】《》〔〕

[ufcpp-live]

// もし Unicode 任意演算子を認めたら…
var Σ = new[] { 1, 2, 3 };
int operator ∑(IEnumerable<int> list) => list.Sum();
var sum = ∑Σ; // 原理的には合法になっちゃう…

// Σ ギリシャ文字のシグマ
// ∑ 数学記号のシグマ
// 別のコードポイント。

[ufcpp-live]

tuple element name, VB も対応してた

[ufcpp-live]

次回(というか正式リリースタイミングで):

• タイトル: C# 10.0 正式リリース記念
• 内容: C# 10 の機能一覧を乗せといて「何か質問ある？」「雑談しようよ」