3 ポイント 投稿者 GN⁺ 2025-03-28 | 6件のコメント | WhatsAppで共有
  • Go 1.18でジェネリクス(generics)機能の導入とともに、新しい概念である コアタイプ(core type) が追加されたが、1.25で削除することが決定
  • コアタイプは、コンパイラ実装を容易にするための抽象的な概念であり、ジェネリック型オペランドを扱う際に従来の基底型(underlying type)を置き換えるものだった
  • 言語仕様でも、従来の「基底型」を「コアタイプ」に置き換えて使用していた

型パラメータと型制約

  • 型パラメータは、将来決定される型のためのプレースホルダーとして機能し、コンパイル時に確定される
  • 型制約は、そのパラメータ型で可能な演算を決定する
  • Goでは、メソッド要件と型要件を組み合わせて型制約を定義し、それによって型集合(type set)を形成する
  • 型集合は、特定のインターフェースを満たすすべての型の集合を意味する
    type Constraint interface {  
      ~[]byte | ~string  
      Hash() uint64  
    }  
    
  • この型集合ベースの方式は、ジェネリック型の演算を定義するうえで非常に柔軟かつ強力である
    func at[bytestring Constraint](s bytestring, i int) byte {  
      return s[i]  
    }  
    

コアタイプ導入の背景と限界

  • コアタイプは、一部の演算でジェネリック型の使用を簡単にするためのルールとして定義された
  • コアタイプの定義方法:
    • 通常の型である場合、コアタイプはその型の基底型と同じ
    • 型パラメータである場合、型集合内のすべての型が同じ基底型を持つときにのみコアタイプが存在する
  • しかし、この方式は次のような問題を引き起こした:
    • 言語仕様が複雑になり、単純なルールでさえ理解しにくくなる
    • 非ジェネリックコードにも不要にコアタイプの概念が持ち込まれる
    • コアタイプ概念のある一部の演算は過度に制限的となり、実際には安全な演算まで許可されなくなる
    • コアタイプを使わないルールとの不一致により、言語設計全体の一貫性が損なわれる

Go 1.25でのコアタイプ廃止

  • Go 1.25リリース(2025年8月予定)では、コアタイプ概念を言語仕様から削除することが決定された
  • 各演算ごとに必要な制約を明示的な文で記述する方式へ移行する
  • 変更の主な効果:
    • 概念の数が減り、Go言語の学習が容易になる
    • 非ジェネリックコードがジェネリックの概念に依存せず、より明確になる
    • 特定の演算ごとに、より柔軟なルール設計が可能になる
    • 将来の機能拡張に向けた土台が整う(例: 共通フィールドへのアクセス、スライス機能の強化、型推論の改善など)

主な適用事項と期待される効果

  • コアタイプに言及していたすべての仕様文は削除されるか、明示的な文に置き換えられる
  • コンパイラのエラーメッセージでもコアタイプという用語が削除され、より具体的な説明が提供される
  • 既存のGoプログラムの動作には影響しない
  • 言語仕様はより簡潔になり、ユーザーにとってGo言語はさらに直感的で明確なものになる

6件のコメント

 
GN⁺ 2025-03-28
Hacker Newsの意見
  • Goチームが仕様変更を非常に慎重に扱っている点が良い

    • Goのジェネリクスは大きな変更であり、使いこなすのが難しいこともある
    • 制約がジェネリクスの過剰な使用を防いでくれると思う
    • JavaやTypeScriptのプロジェクトで型システムを過剰に使い、コードが不明瞭になるケースを見てきた
    • Goチームには言語に対して保守的に取り組んでほしい
  • Go開発チームのこの10年は、機能と単純さのバランスを探る過程だった

    • ジェネリクスはこの力学をよく示している
    • Goの上にRustのような型システムを実装するのは複雑すぎる
    • 単純さを重視する方向へのわずかな回帰は良いことだ
    • Goは中堅エンジニアのチームにとって、より良いJavaになることを目指している
  • Go 1.25は実際の言語機能を追加しない

    • 1.30ではsum typesが追加されるかもしれない
  • Windowsビルド以前からGoを追ってきた

    • 2011年に学んだことが今でもすべて有効だ
    • Goで作業する機会はなかったが、小さなプロジェクトで学習してきた
    • Go開発者インタビューで、ジェネリクスはGoに導入されなさそうだという発言に失望した
    • 今はジェネリクスが導入されたので、Goでサイドプロジェクトを始めるつもりだ
  • close の引数が型パラメータである場合、すべての型が同じ要素型のチャネルでなければならないというのは事実ではない

    • 要素型は close に影響せず、異なる要素型を持つ型セットを使っても問題なくコンパイルできる
    • ドキュメントの改善が必要だ
    • 共有フィールドのような柔軟性拡張が加速してほしい
  • Goをゆっくり学んでおり、C++のバックグラウンドがある

    • テンプレート特殊化に似たものなのか気になる
    • これをサポートする言語がもっと増えてほしい
  • [dead]

  • いまや生成AIがコードを書けるようになったが、それでもガベージコレクタは必要なのだろうか

 
aer0700 2025-03-28

今では生成AIがコードを書けるようになったのに、ガベージコレクタが依然として必要なのか気になります。
> 示唆的ですね……

 
galadbran 2025-03-29

ほお……AIがそのレベルのコード(メモリ管理を完璧に行うコード)を書ける水準になったら、人間の開発者が今のような役割のままでいるのは難しいでしょうね

 
kandk 2025-03-28

1+1=2 を数学で解けるのに、わざわざ AI で解く理由が……

 
jeiea 2025-03-28

人間が読むボイラープレートや追うべきコード文脈を減らすという点では、GCにも意味があるのではないでしょうか。
コードを読む必要すらなくなると予測しているのなら、それはまた別かもしれませんね。
元のコメントもぼかし処理されているのを見ると、あまり共感は得られていないようです。

 
savvykang 2025-03-28

メモリの割り当てと解放の時点をコンパイル時に計算できるなら、参照カウントを取り除けるのではありませんか? Hacker News の元コメントの投稿者は、メモリ再利用の問題を理解していないように見えます。