Thanks to all those who have had the patience to read this proposal and made comments on, or criticisms of, it.
Having carefully considered the points made, I have concluded that the current proposal falls short in two important respects: 1. It doesn't deal adequately with numeric precision and/or signed-ness. 2. It's incomplete in that it doesn't deal with types based on string or bool. Nor does it deal with the inter-convertible types: string/[]bool or string/[]rune which would be useful in practice. Now a combination of my 'union' and 'except' assertions would address both of these criticisms. However, I have decided that these are too complicated and could lead to some difficult scenarios for the compiler or human reader to sort out. Although I still subscribe to the view that: "a simple to use and understand solution that covers 90% is better than a complex one to cover 100%", I think this proposal can (and should) do much better than that - close to full coverage of *realistic* scenarios - while retaining its essential simplicity. I have therefore decided to make the following changes to the proposal: 1. The 'union' assertion idea has been dropped completely. 2. Instead, the number of built-in contracts has been augmented by the following: * Boolean - any boolean type * String - any string type * Bytes - any string type or byte slice. * Runes - any string type or rune slice This brings the number of built-in contracts up to 10 which is a lot but worthwhile, IMO, because of the extra expressiveness it will bring. I continue to take the view that complex types are best segregated from the other numeric types for the reasons I originally gave in the proposal and also because to do otherwise would require, for completeness, the addition of 3 more built-in contracts (Numeric, NonInteger and Addable). 3. The 'except' constraint idea has been adopted but in a much restricted form: it will only be able to list built-in numeric types which are to be excluded from the contract. To be consistent with the built-in contracts, excluded types will be deemed to include defined types with the same underlying type. The name will be changed to 'omit' which I think expresses its intent more clearly. 'omit' will enable us to deal properly with numeric types and, in particular, it will now be possible to build both 'Unsigned' and 'Signed' contracts from the Integer contract and also to disallow smaller integer types (such as int8 and uint8) where necessary. So that's a summary of what's changed and the revised proposal is still available at the same link: https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab As I said earlier, I hope Ian can make the draft design work (possibly with some simplifications in the light of feedback) but, if he can't, then I believe this proposal - which addresses the problem of operators/conversions in a different way - would be a plausible alternative. I'll shut up now (where have I heard that before)! Alan On Friday, September 14, 2018 at 11:32:29 AM UTC+1, alanfo wrote: > > It's now more than a fortnight since the Go 2 Draft Generics Design was > published and, like many others, I have spent considerable time: > > 1. Steeped in discussions about the draft. > > 2. Reading feedback papers by others (Roger Peppe's are particularly > illuminating) most of whom share my opinion that 'contracts' are > unsatisfactory and should be replaced, amended or simplified in various > ways. > > 3. Attempting to devise a workable alternative to contracts (as envisaged > in the draft) myself. > > I was then brought back to reality by this post by Robert Engels in the > 'Generics - Why contracts?' thread: > > "As I’ve said elsewhere, a SIMPLE to use and understand solution that > covers 90% is better than a complex one to cover 100% IMO, and fits in well > with the rest of Go design. Go leaves out a lot - and it's a good choice." > > This convinced me that the draft design itself and many third party > proposals (including my own) were too ambitious and what we needed was > something much simpler that gave us 90% coverage and which everybody could > understand. > > So I've added a simplified proposal to the feedback page which I feel > meets this more limited aim. For anyone interested, here's the link: > > https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab > > Although the new proposal is largely a simplified version of my 'full fat' > proposal, the paper itself is much more comprehensive as I've included > notes on why I think certain contracts should be built-in (but not others) > and have also tried to address the problems that were raised in the draft > design and overview papers themselves. > > Any comments or constructive criticism are of course welcome. > -- 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. For more options, visit https://groups.google.com/d/optout.
