Instead of giving one-off answers to one-off questions, I would suggest to write a detailed design doc, so we can talk about *that*. The design draft by Ian and Robert is the culmination of over a decade of thinking and talking about generics in Go and it goes to great lengths to shed light on all aspects of the design - from syntax, over type-checking and type-inference to actual implementation considerations. That is, why it is so long - its length doesn't reflect the complexity of the design, but it reflects the complexity of the discussion.
It certainly is possible to come up with a simpler design and it might even be possible to come up with a simpler design that does more. But if the premise you are coming into the discussion with is "let's just assume that the last ten years of discussion did not happen and start from scratch", you are *highly* likely to duplicate effort that has already been done. And if you walk through your design on a mailing list, instead of putting in the work of writing a full design doc, you are forcing others to do this duplicate effort - in the form of exactly such one-off question and answers. Please take a note of the evolution of this generics design. For a long time now, the progression has been a) Ian writes down a design, b) the benefits and merits of this design where then discussed *holistically*, under consideration of all aspects of the design and c) Ian came back a year later with a new design, taking the discussion of the previous one into consideration. This means that at every stage, we could talk about a specific design in its entirety, without the danger of forgetting the implications of changing one aspect of it has on the other aspects. It's easy to come up with simpler syntax. It's also easy to answer questions about how specific problems of that syntax would be addressed. But often this means changing aspects of the design - for example, you are now suggesting, changing the syntax to allow new type-literals using new keywords or predeclared identifiers. The obvious follow-up is then "how about the second parameter? Or the nth?". And, of course, you can change the suggested syntax again. But every time you do a change like that, you are flushing the entire previous discussion down the drain, because we now have to re-consider all aspects of the design, from tokenization, over parsing to type-checking and implementation etc. So, I strongly urge y'all to either a) work with the rest of the community on the draft posted by Ian and Robert, trying to improve on it, or b) write your own design, in a detailed document about all aspects of it, or c) do neither and stick with a pure thumbs-up/down expression of opinion - which doesn't help to address your concerns, but at least counting those is scaleable. On Tue, Jan 19, 2021 at 12:50 PM Kevin Chadwick <m8il1i...@gmail.com> wrote: > On 1/19/21 11:43 AM, 'Axel Wagner' via golang-nuts wrote: > > This is essentially the previous generics design > > < > https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md > >, > > where you implicitly use the function body as a contract - with the > exception, > > that you have no way to express that two arguments should be *different* > > firstInput[0] > firstInput[[]byte] > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/91fee76b-922c-fd1c-f177-65c9251c6992%40gmail.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGv8q3c8tXZha%2BVg1mO46WZqi_RTub%2BBGWT6OgrmPk7RA%40mail.gmail.com.
