For those who don't agree that complex numbers should be segregated from
the other numeric types, I'll briefly suspend my vow of silence to say that
I've found a way to do this which doesn't involve adding more built-in
contracts or fancy syntax to the contract body. In fact, it's as simple as
this:
contract Numeric(T) {
Real(T)
Complex(T)
}
How this would work is described in the gist.
Alan
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.
