alanfo

Proposed changes to the Go draft generics design in the light of feedback received

Introduction

Since the draft generics design was published in late August, there has been a great deal of feedback and counter-proposals.

This document re-examines the draft design in the light of this feedback and proposes that some changes be made. It also discusses some of the major criticisms that have been levelled but which I think should nevertheless be dismissed.

It is often forgotten that the Go team have spent years thinking about how generics could be implemented and have probably rejected many of the alternative ideas which are now being floated either because they fall short of the desired goals in some respects or are simply unworkable. I think this previous experience should be respected and that one should therefore only depart from the draft design where there is a very good reason for doing so.

alanfo

A simplified generics constraint system.

Introduction

Although the constraints system (contracts) in the draft generics paper is very powerful and can deal with virtually anything (albeit sometimes in a circuitous fashion), many commentators feel that it is not a good fit for a simple language such as Go and that it may prove difficult for the community at large to write, read and use contracts in practice. Although a tool could be provided to help deal with writing contracts, this still won't help with reading and understanding them.

I posted an earlier proposal for dealing with the perceived shortcomings of contracts here. For convenience some of what I said in my earlier paper is repeated here.

However, I have come to the conclusion that even this proposal is too complicated and what we really need is something simple which everybody can understand and use but which can still cope with nearly all the cases where a constraint is

alanfo

A suggested amendment to the Go 2 generics draft design.

Introduction

As many others have said, a lot of thought has obviously gone into the Go 2 draft design for generics and, personally, I'm very happy with the basic syntax both at the declaration and call sites. However, I'm far less happy about the use of 'contracts', as currently envisaged, to constrain the types which can be used to instantiate a generic function or type. This is because:

1. Contracts seem a rather amorphous concept and it is not at all clear to me how the compiler is going to check that a contract is sufficient to satisfy what the function/type is doing in all circumstances. If a very complex algorithm is required, then this is going to slow down compilation.

2. There seems to be too many problem cases for comfort. Dealing with untyped numeric constants looks to be a particularly unintuitive area and not being able to fully determine method signatures (without casting to an interface) or to distinguish value receivers (without