Ian D,
I'm sorry that we had a mis-understanding regarding the introduction to my
paper but I hope you now understand why I made the remarks I did.
To turn to the technical issues.
I haven't checked them all but I did notice one example which your paper
doesn't appear to cover, namely the add1K example which has been a
stumbling block for a lot of proposals including my own though I did
eventually find a way of dealing with it.
Perhaps I could go through the reasons why I have concluded that it is
better to stick with contracts rather than interfaces even though the two
approaches are not completely orthogonal:
1. If interfaces were used, a way would need to be devised to express that
a type supports a particular operator or operators. To be compatible with
methods something like the following seems best:
+(T, T) T
However, this would mean that someone writing an interface to be used for
generic constraint purposes would have to know and write out the signature
for each operator used.
In contrast, when writing a contract, it doesn't matter whether the syntax
we use is compatible with methods or not as it's a new concept. So writing
something like T + T is fine and the writer doesn't even need to know what
the signature of '+' is.
How to express operators was, of course, identified in the draft design
paper itself as a difficulty with interfaces and it was mentioned that
there was a subtlety with the == operator which returns an untyped bool
rather than a typed bool.
2. As your own paper clearly shows, it is possible to deal with multiple
type parameters which refer to each other using an interface based approach
and even the draft design paper itself admits this is possible. However, it
seems to me to be less elegant than a contract based approach.
An interface can only express the methods which a single type needs to
satisfy and so a separate interface is needed for each mutually referential
type parameter. A contract on the other hand doesn't have this constraint
and, indeed, the type parameters as a group have to satisfy a single
contract which, to my mind, ties the whole thing together in a much nicer
way.
3. Interfaces don't deal with fields at all and so would need to be
extended to cope with a struct constraint. To be fair, some people have
questioned whether such constraints are important enough to be catered for
at all but the draft design does nevertheless deal with them and so does my
own paper.
4. There are a number of minor (though tricky) issues which interfaces
can't currently deal with but contracts can and which I listed in my paper.
To take one in particular - excluded types - it is difficult to see how
interfaces could deal with something like that though, as it's a novel idea
anyway, perhaps some other way could be found to achieve the same result.
5. Finally - and you might think this is a bit silly - but there are a lot
of people who don't like the idea of generics at all and will probably try
to avoid them if they can. Now, hopefully they will change their minds when
they see how convenient generics can be to use. Nevertheless, I still think
it's important to cater for such people and leaving interfaces as they are
and confining the generic stuff to contracts should help here.
On your last point about unification of generic methods (or the lack of it
without operator overloading), I suspect that the Go team will prefer your
option 1 (two generic methods, one for the built-ins and the other for
types which satisfy an equivalent interface) as far as the standard library
is concerned - at least where slices and maps are concerned.
Option 3 (operator version only) is clearly an incomplete solution and I
doubt whether they'd be keen on option 2 either (method based version
only) because wrapping and unwrapping non-scalar types is such a pain.
Alan
On Saturday, October 20, 2018 at 4:31:09 PM UTC+1, Ian Denhardt wrote:
>
> Quoting alan...@gmail.com <javascript:> (2018-10-19 16:19:36)
> > Ian D,
> > The introduction is certainly not intended to be insulting to those
> who
> > have put serious thought into the problem. If it were, then I'd be
> > insulting myself as I've put serious thought into at least two other
> > proposals which are nothing like the current one!
>
> I apologize if I've interpreted things less charitably that I should
> have.
>
> > It's simply a realization I've come to that there's a lot of mileage
> in
> > the original draft which is the culmination of what two very smart
> > people have been working on for years and should not therefore be
> > dismissed too readily.
>
> I certainly agree with this. My own proposal left type parameters
> basically untouched, though I have specific criticisms I and many others
> have made elsewhere regarding contracts.
>
> The original draft was indeed *very* thorough, and provided many useful
> motivating examples that act as some tests for alternatives. The
> discarded ideas section also provides a justification for each. (This
> makes it very easy to see that your own square brackets suggestion
> handles the original objection to this idea, which brings it back into
> the realm of discussion).
>
> On to more technical issues.
>
> ---
>
> Your post mentions:
>
> > However, the problem is that contracts can do a lot more things than
> > interfaces currently can and it is not easy to extend the latter to
> > meet this shortfall.
>
> My own proposal addressed every single example in the examples section
> of the draft design, as well as the graph example. Can you describe what
> you think is missing? It's been linked before, but for reference:
>
> https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d
>
> (You mention that the graph example is "awkward" to express. This is a
> bit subjective, but the thing I feel more strongly about is that a single
> slightly subtle encoding does not justify adding an entirely new
> non-orthogonal construct to the language).
>
> > Stepping back a little, is it really such a big deal to have two
> > functions for anything involving operators - one for the relevant
> > built-ins and another for user-defined types which satisfy an equivalent
> > interface?
>
> I talked about this in my original proposal, which left out operator
> overloading, curious to your thoughts:
>
>
> https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#operators
>
--
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.
