On Friday, September 21, 2018 at 5:51:37 PM UTC+1, alanfo wrote: > > 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.
