Ngôn ngữ Go chính thức đề xuất hỗ trợ Generic Methods

Ngôn ngữ lập trình Go đang đứng trước một thay đổi lớn với đề xuất chính thức về việc hỗ trợ Generic Methods (phương thức Generic). Vấn đề này đã được thảo luận rộng rãi trong cộng đồng trong nhiều năm qua, và gần đây, nhóm phát triển Go đã chấp nhận đề xuất mang số #77273, nhằm đưa tính năng này vào ngôn ngữ trong phiên bản Go 1.27.

Bối cảnh và Thay đổi quan điểm

Hiện tại, đặc tả của Go quy định rằng một phương thức cụ thể (concrete method) về cơ bản là một hàm có receiver (người nhận). Tuy nhiên, tồn tại một sự thiếu nhất quán: trong khi các hàm có thể là generic, thì các phương thức thì không. Chúng không thể tự khai báo các tham số kiểu (type parameters) của riêng mình, mà chỉ có thể sử dụng các tham số kiểu từ kiểu của receiver.

Lý do chính cho sự hạn chế này xuất phát từ quan điểm cũ rằng vai trò chính của phương thức là để triển khai (implement) một interface. Việc cho phép tham số kiểu trên phương thức cụ thể sẽ đồng nghĩa với việc phải cho phép tham số kiểu trên phương thức interface — một tính năng rất khó để triển khai hiệu quả trong Go do tính chất động của việc kiểm tra kiểu tại thời gian chạy.

Tuy nhiên, nhóm phát triển Go đã thay đổi quan điểm. Họ nhận ra rằng các phương thức cụ thể hữu ích riêng biệt, không chỉ để triển khai interface mà còn để tổ chức mã nguồn và tận dụng lợi thế cú pháp (ví dụ: x.a().b().c() dễ đọc hơn c(b(a(x)))). Do đó, việc hỗ trợ generic cho phương thức cụ thể là cần thiết ngay cả khi chúng không thể được gọi thông qua một interface.

Đề xuất kỹ thuật

Đề xuất mới cho phép các khai báo phương thức cụ thể trông giống hệt như các khai báo hàm, nhưng có thêm receiver. Cụ thể, cú pháp của phương thức sẽ được chấp nhận các tham số kiểu giống như hàm.

Ví dụ về cú pháp mới:

type S struct { ... }

// Phương thức m của S có tham số kiểu P
func (*S) m[P any](x P) { ... }

Khi gọi phương thức generic, người dùng có thể cung cấp đối số kiểu một cách rõ ràng hoặc để trình biên dịch suy luận (type inference):

var s S
s.m[int](42)    // Cung cấp rõ ràng kiểu int
s.m(x)          // Trình biên dịch tự suy luận kiểu P từ x

Tương thích với Interface và Reflection

Một điểm quan trọng cần lưu ý là các phương thức generic cụ thể sẽ không khớp với một phương thức interface có cùng tên và chữ ký. Điều này là do cú pháp của phương thức interface hiện tại không thể có tham số kiểu khớp.

Ví dụ, một kiểu H có phương thức generic m sẽ không được coi là triển khai interface I yêu cầu phương thức m(string):

type I interface {
    m(string)
}

type H struct { ... }
func (H) m[P any](P) { ... }

var h H
var _ I = h // Lỗi: H.m có chữ ký m[P any](P), không khớp với m(string)

Ngoài ra, các phương thức generic cũng sẽ không thể truy cập thông qua reflection (bằng tên hoặc chỉ mục) tương tự như các hàm generic chưa được khởi tạo (uninstantiated).

Triển khai và Tác động

Thay đổi này được đánh giá là hoàn toàn tương thích ngược (backward-compatible) vì nó chỉ thêm tính năng mới bằng cách gỡ bỏ các hạn chế cũ.

Về mặt triển khai:

• Trình phân tích cú pháp (Parser): Chỉ cần thay đổi tối thiểu vì hiện tại parser đã chấp nhận tham số kiểu cho phương thức nhưng báo lỗi.
• Trình kiểm tra kiểu (Type checker): Cần điều chỉnh để loại bỏ các hạn chế hiện tại.
• Backend: Việc biên dịch các cuộc gọi phương thức generic có thể được chuyển đổi thành các cuộc gọi hàm generic tĩnh, giúp việc triển khai dễ dàng hơn về mặt khái niệm.
• Công cụ: Các công cụ phát triển và thư viện bên thứ ba sẽ cần thời gian để cập nhật và bắt kịp với thay đổi đặc tả ngôn ngữ này.

Đề xuất này đánh dấu một bước tiến quan trọng, giúp các nhà phát triển Go viết mã gọn gàng, linh hoạt và dễ bảo trì hơn trong tương lai.