Hi Patrick,
I guess it's largely a matter of taste but one of the reasons why I prefer
contracts to interfaces is precisely because you only need one contract for
the type parameters as a whole.
This keeps the type parameter section of the generic function/type
relatively brief when you have
On Fri, Oct 19, 2018 at 10:48 AM alanfo wrote:
> In the light of all the feedback there's been, I've put together a
> proposal which sticks closely to the original design and only changes what
> most people consider needs to be changed in some way. Some recent ideas
> which seemed plausible but
I've thought of some other ways of excluding 'string' so that one could
restrict an 'exclude' constraint to just numeric types.
At the expense of adding another line, you could do:
int(T)
or if (say) T * T implied T + T, T - T and T / T (which would certainly be
true) then you could use
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
Quoting alan.f...@gmail.com (2018-10-20 16:59:52)
>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
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
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
>
Alan, like your approach and nearly all your solutions (any quibbling I have
isn't worth mentioning).
And best of all, I think it would make excellent godoc documentation.
Thanks for taking the time to write this up.
--
You received this message because you are subscribed to the Google
alan.f...@gmail.com :
> I also don't think that Eric was being disrespectful to Ian LT and Robert.
> He simply has a profound dislike for the draft generics design and believes
> in expressing himself forcibly and at times, comically :)
True dat!
Your grasp of this nuance is appreciated.
--
Ian Denhardt :
> Second, I agree with Tristan that Eric's sibling comment is a bit sharp;
> let's be careful to keep this civil, as it's clear that some of us are
> feeling a bit tense.
I was serious when I said I meant no insult, and apologize to any who
felt insulted.
> Ultimately however I
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!
It's simply a realization
I think we need to focus this thread on comments just about alanfo's
suggestion. Let's not start debating how to debate. And, of course,
let's remember the code of conduct: https://golang.org/conduct .
Thanks.
Ian
--
You received this message because you are subscribed to the Google Groups
First, I find the introduction to this condescending; it amounts to "the
Go developers know what they're doing, stop questioning them plebians!"
It is phrased more politely, but the content is basically there. This
is:
1. Insulting to those of us who also have put serious thought
into the
My head has been spinning lately after reading the various generic
counter-proposals and suddenly the original draft design seems a lot more
attractive than it did :)
In the light of all the feedback there's been, I've put together a proposal
which sticks closely to the original design and
14 matches
Mail list logo
