Sorry, I was thinking that Foo was an interface (rather than an existing
contract), so the second example couldn't be written non-generically.
In the third example you could also merge the two contracts into one:
contract MapFoo(K, V) {
Comparable(K)
union{ int, float64,
Just going through how xingtao zhao's examples would look under my own
proposal:
The first one would be:
contract Foo(T) {
union{ int, float64, complex128 }(T)
interfaceA(T)
}
Note though that this could only be satisfied by defined types based on
int, float64 or comple
On Tue, 18 Sep 2018 09:51:03 -0700 (PDT)
xingtao zhao wrote:
> contract Foo(T) {
> int(T) || float64(T) || complex128(T) // underlying type: int, float64,
> complex128
> InterfaceA(T)// at the same time, it
> should satisfy InterfaceA
> }
CGG https://gi
I have the similar thought as the thread. In terms of a contract, it is
mainly to express these:
1. Methods set: this could be easily expressed by interface
2. Operators set: In go, we could not add or remove the existing
operator set for a given type, which is completely inherited from
Thanks for your comment, Patrick.
Although I've relied on compiler magic for my previous proposals, I believe
we should keep it to a minimum if we can, The 'union' and 'except' idea
would allow us to compose any group of types we want from the basic
built-ins and, even within the standard libra
I think your idea of creating standard contracts to represent similar types
is a good one. However, you don't have to say how those contracts are
written, just what they do. No need for typecheck, union, except, etc. For
example,
Integer(T) - T is an integer type
Float(T) - T is a floating point t
Small, but important, correction re #5:
5. Any contract could contain at most one 'union' or 'except' assertion *for
each type parameter*.
Alan
On Monday, September 17, 2018 at 11:07:26 AM UTC+1, alan...@gmail.com wrote:
>
> Jonathan,
>
> The problem with just 'OR'ing complex64 and complex128
Jonathan,
The problem with just 'OR'ing complex64 and complex128 together is that the
resulting contract wouldn't encompass any defined types with the same
underlying types. So 'mycomplex' wouldn't be included:
type mycomplex complex64
However, I'm pleased you mentioned it as it's given me
On Friday, September 14, 2018 at 8:06:31 PM UTC-4, alanfo wrote:
>
> Thanks for your comments, Jonathan.
>
> I did in fact deal with all the cases you mention in my 'fuller' proposal:
>
> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
>
> where I'd used a device to restrict the b
Thanks for your comments, Jonathan.
I did in fact deal with all the cases you mention in my 'fuller' proposal:
https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
where I'd used a device to restrict the built-ins to just one following
criticism by Ian that an earlier proposal I'd ma
I'm sympathetic to the general idea, but I don't think this quite does it.
In addition to introducing a bunch of new names, it's not expressive enough:
- You can't express "string or []byte", as you note. There are many
algorithms where this would be useful. See the strings and bytes packages
f
Well, I can't speak for the other simpler proposals but for my own there's
very little to learn - just six built-ins where it's pretty obvious what
they mean from their names and the rest is (in effect) just checking that a
type satisfies a certain interface or, if it's a struct, has certain
fi
On Fri, Sep 14, 2018 at 10:47 AM, wrote:
>
> The problem is that many people think the current draft design is too
> complex and I haven't seen a plausible suggestion from anyone (myself
> included) which would be appreciably simpler but as comprehensive, or nearly
> so.
>
> This is why I'd concl
Ian,
Ian,
Well, if a simple comprehensive solution can be found, then I'm sure we'll
all be in favor of it.
The problem is that many people think the current draft design is too
complex and I haven't seen a plausible suggestion from anyone (myself
included) which would be appreciably simpler
I think you hit the nail on the head, Go already uses a 90% solution in many
areas, and that is why it is both simple and useful.
In the case of generics programming though, it is 0% (unless you count
interface{} as being generic - I don’t)
Java went for over a decade without generics, and many
On Fri, Sep 14, 2018 at 3:32 AM, alanfo wrote:
>
> 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, an
alanfo :
> Any comments or constructive criticism are of course welcome.
I applaud this step in the direction of simplicity.
I've left a more specific comment on the issue.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institu
Well, it's easy enough if you check that it's a non-negative integer to
start with :)
If it's negative, you'd have to decide what to do - return an error, panic
or circumvent the problem in some other way.
Alan
On Friday, September 14, 2018 at 1:40:41 PM UTC+1, ohir wrote:
>
> On Fri, 14 Sep 2
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 th
19 matches
Mail list logo
