This idea has similarities to feedback
<https://gist.github.com/alanfo/2298656cbe19dfa95472bfbbf421ff69> I've
provided myself on the Go 2 generics draft design.
However, I've tried to marry it with interfaces and have used the
expression 'type group' rather than 'typeclass' so nobody
I've never been able to understand why 'go fmt' allows you to add the
function body (apparently of any length) on the same line as its
declaration but doesn't allow a one line 'if' or 'for' statement even if
the body consists of a single short statement.
So, if you write this:
if
Ian,
Thanks for taking the time to read through my feedback on this matter.
You'd didn't miss much by not reading the earlier version as I'd tried to
marry the 'type group' idea with interfaces and ended up with something
which was not really coherent.
It is, of course, unfortunate that one
Sorry to have duplicated your idea, rog, particularly as I did read your
feedback what now seems "years" ago!
Frankly, there has been so much feedback and so may lengthy threads on this
topic that I'm losing track of what's been suggested and by whom :(
Alan
On Monday, September 10, 2018 at
in with this.
The link is the same as before but is repeated below for those who are
interested:
https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
Alan
On Thursday, September 6, 2018 at 5:54:24 PM UTC+1, Ian Lance Taylor wrote:
>
> On Thu, Sep 6, 2018 at 8:20 AM, > wrote:
> >
> &
Sorry, the proposed new keyword is 'typecheck' not 'keycheck'.
Alan
On Monday, September 10, 2018 at 6:01:12 PM UTC+1, alanfo wrote:
>
> I've revised my feedback on this topic yet again in the light of
> criticisms made by Ian which I thought were justified.
>
> Briefly, I'
As it's clear now that Ian wants to stick with 'full-blooded' contracts if
it can be made to work, I've been trying to think of ways to make them
easier to work with and to solve some of the issues they currently have.
Reading through the draft for the umpteenth time, one point that
OK, fair enough, but the only way you could have a standard package on
those lines without the compiler doing more inference would be to list
expressions for every single operator or conversion that the relevant types
support. That should be doable but I'm not sure whether a particular
Hehe, no problem Axel ;)
Just glad to see that there are at least 3 of us on roughly the same page
with the 'typeclass' idea.
I was impressed that you'd managed to come up with a solution to the Graph
example by using an intermediate type, AdjacencyList, to implement both the
Nodes() and
Well, firstly, I think it would be perfectly reasonable for the compiler to
disallow a generic type if one (or more) of its type parameters were not
used in the generic type's definition. However, I couldn't see anything
about this in the design document itself which is why I said I wasn't
I think you're right that (assuming x isn't a pointer type), the following
would tell the compiler that 'String() string' is a value method of T.
contract stringer(x T) {
var _ string = T.String(x)
}
However, in the following case:
contract stringerp(x T) {
var _ string = (*T).String()
Robert,
I suspect that you could achieve 90% coverage with just 4 built-in
contracts:
1. integer (any integer type)
2. real (any integer or floating point type)
3. ordered (any integer, floating point or string type)
4. comparable (any type which supports == and !=)
If you had just one
Well, whatever you may think of it, there's no doubt that a lot of the
problems we currently have with generic constraints would go away if
operator overloading were introduced into Go 2.
Personally, I wouldn't be dismayed if this were to happen. A lot of my
stuff is mathematical in nature and
probably be a minority of users in any
case.
Of course, all users would need some familiarity with the concept as they
might need to read code written by others which did use it.
Alan
On Tuesday, October 16, 2018 at 11:33:26 AM UTC+1, alanfo wrote:
>
> Well, whatever you may
AM UTC-4, alanfo wrote:
>>
>> However, I think it's important to learn the lessons of the past and not
>> follow languages such as C++ or Scala where you can overload virtually
>> anything or even make up your own operators which can result in confusing
>> or even write
and only changes what most
people consider needs to be changed in some way. Some recent ideas which
seemed plausible but which I felt had little chance of adoption have been
rejected.
It's not too long so give it a read and see what you think.
Here's the link:
https://gist.github.com/alanfo
I think it's fair to say that dealing with untyped numeric constants is one
of the most opaque areas of the draft design and I remember thinking when I
first read it that a clearer and more intuitive solution would have to be
found.
As far as the 'excluded types' idea is concerned, I can't
thoughts on these and
would be interested to know what you guys think about them.
Alan
On Friday, October 19, 2018 at 6:48:36 PM UTC+1, alanfo wrote:
>
> My head has been spinning lately after reading the various generic
> counter-proposals and suddenly the original draft design seems a
On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote:
>
> On Tue, Oct 16, 2018 at 3:33 AM alanfo >
> wrote:
>
>> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and
>> yes - equality operators - as well because I believe to
May I remind those who are in favor of Go standardization that Java and
Python have never been standardized by ISO/ANSI/ECMA but that hasn't
prevented them from becoming extremely successful languages.
I find it hard to believe that there are large organizations in this day
and age who eschew
A problem with the draft generics design (and with most of the alternative
proposals including my own) is that, without operator overloading, there
appears to be no way to unify the sorting functions.
This is because only the numeric and string types support the ordering
operators (<, <=, >=,
An interesting and (for me at least) novel approach to contract-free
generics.
Despite the suggestions towards the end, it's still too verbose for my
taste but I did find it reassuring that, even without operator overloading
(Eric's proposal), there would still be a plausible way to write
I quite like the draft error handling design and haven't (so far) suggested
that any changes be made.
However, one aspect I don't like is 'check' and 'handle' having to be
keywords which means that the design is not Go 1 compatible. Also, whilst I
agree that these words are probably the best
I didn't know that Ian had written this proposal so thanks for linking to
it.
Although I haven't had time to read it in detail, I certainly agree with
the tenor of what he's saying.
I know more about C# than Java and the language team there have always been
paranoid about not breaking
with imported names would never be a problem because they'd
>>>> usually be qualified by their package name and would begin with an upper
>>>> case letter anyway.
>>>>
>>>> Although other symbols such as $, %, @ or ? could be used in place of*
>>>> !
As a general principle, Ian, that makes sense to me and perhaps it's
something we could all unite on.
The remaining problem is how to distinguish between the two cases - new
keywords used as such or as ordinary identifiers.
Your suggestion is to leave it to the compiler to figure that out from
Mandolyte,
Pleased you liked the approach :)
That's four of us now who favor changing the type parameter section from
parentheses to square brackets, so we're building a bit of a consensus on
that particular aspect.
Alan
On Saturday, October 20, 2018 at 2:31:29 PM UTC+1, Mandolyte wrote:
>
>
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 pr
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.
Some languages which don't support the conditional operator or if/else
expressions have an Iif function (or similar) instead.
If generics are added to Go, it might be worth including something like
this in the standard library to cut down on boilerplate for simple cases:
// in a package called
, 2019 at 11:33:47 PM UTC, Milan Zamazal wrote:
>
> alanfo > writes:
>
> > Some languages which don't support the conditional operator or if/else
> > expressions have an Iif function (or similar) instead.
> >
> > If generics are added to Go, it mig
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
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
Even if it were possible to eliminate the built in generic stuff, I think
it would be a bad idea to do so.
For better or for worse it's now part of the fabric of the language and
just about every program ever written in Go 1 would have to be fixed if it
were replaced.
Also there are many in
ed, 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
Yes, adding methods to instantiated generic types would have some
similarities to (partial) template specialization in C++.
Having concluded that it was a bad idea anyway from the earlier discussion,
I'm glad it's not going to be allowed :)
On Tuesday, September 11, 2018 at 6:45:29 PM UTC+1,
Michal,
Without wishing to over-complicate your proposal, I think you should at
least consider adding "gen int" to the mix.
The reason I say this is because the integer types support a lot more
operators than the floating point and complex types do, namely:
1. The remainder operator (%).
2.
Yes, it should be contracts.Ordered to justify the use of the '<' operator.
The proposed new built-in comparable contract will only permit one to use
'==' or '!='.
I agree that the revised design is very good, contracts are now far more
intelligible than they were and the whole thing just
This in fact is correct behavior.
As 100 is an untyped integer constant, 1e2 can not be implicitly converted
to the same type and so the % operation fails.
You can fix it with:
func main() { println(int(100) % 1e2) }
Now 1e2 is converted to 'int' and all is well :)
Alan
On Thursday, October
39 matches
Mail list logo
