Quoting alan.f...@gmail.com (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.
