On Tuesday, October 16, 2018 at 12:16:16 AM UTC-4, Beoran wrote:
>
> For niw, I don't see what complelling benefits allowing operators in
> generic contracts would bring.
>
Consider Ian Lance Taylor's smoke test for generics. It is: can we
implement min() and max() on a generic type.
What
Well, you could certainly implement min or max generically without operators in
contracts if you use a wrapper type for primitives and pointers. A bit more
verbose perhaps, but that is also how it is now.
I can only speak for myself and say that I would not be disappointed at all
with such simp
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
One other advantage of Eric's proposal that has just occurred to me is that
folks who dislike operator overloading wouldn't have to use it at all -
they could just use the named methods.
The only people who would need to use it would be those writing unified
generic functions/methods who would
On Tuesday, October 16, 2018 at 6:33:26 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 e
I'm not sure whether the likes of = and := would be classed as operators or
punctuation in Go though the former is certainly an operator in C++ where
(very confusingly IMO) it can be overloaded and sometimes is.
Although I wouldn't like to see these symbols overloaded in Go I don't have
a probl
On Tuesday, October 16, 2018 at 12:24:59 PM UTC-4, alanfo wrote:
>
> With regard to your reply to Ian, I'm afraid I can't agree with you that
> the type parameters shouldn't be specified 'up front'. That's just too
> 'dynamic' for me and not very go-like. I'd imagine it would give the
> compil
On Tuesday, October 16, 2018 at 6:05:56 PM UTC+1, Eric Raymond wrote:
>
>
>
> On Tuesday, October 16, 2018 at 12:24:59 PM UTC-4, alanfo wrote:
>>
>> With regard to your reply to Ian, I'm afraid I can't agree with you that
>> the type parameters shouldn't be specified 'up front'. That's just too
>
After reading his proposal, I think you should help Burak Sedar work out
his proposal in the other thread. It is conceptually a lot easier than the
idea of contracts, but likely to be more powerful even. To me it has the
ideal Go-like feel and it solves the problem with operator overloading in
On Thursday, 18 October 2018 08:00:56 UTC+2, Beoran wrote:
>
> After reading his proposal, I think you should help Burak Sedar work out
> his proposal in the other thread.
>
Where is Burak Sedar's proposal?
> It is conceptually a lot easier than the idea of contracts, but likely to
> be
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 do otherwise would
> be very confusing.
>
If overloading [] were disallowed, how would one write a generic function
ta
The easiest solution is that []int IS A IntList by definition, no ? Meaning
that an “slice” has defined methods Len(), and At(). I would personally define
other methods on slice too for convenience (like, Insert, Delete). The []
notation is just syntactic sugar for slice.At(). When used as a lef
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 do otherwise would
>> be very co
Operator overloading seems completely antithetical to what most seem to
value in Go. Readability is key. Go mostly avoids syntactic sugar (and
where it has it, it is often acknowledged as a mistake).
To me, the existing contracts design makes it clear when a generic is
being used. It should also
Quoting Patrick Smith (2018-10-16 19:21:35)
>If overloading [] were disallowed, how would one write a generic
>function taking a single argument of type either []int or a
>user-defined type with similar behavior, and returning the sum of the
>elements? Sort of the marriage of these
On Wednesday, October 17, 2018 at 11:12:19 AM UTC-4, Ian Denhardt wrote:
>
> My instinct here is to be conservative; we've got a boatload of use
> cases for < and ==, a few obvious ones for +, *, / etc, and a long-tail
> for operators after that. Eric's proposal makes it trivial to add more
>
On Tue, Oct 16, 2018 at 5:44 PM robert engels wrote:
> The easiest solution is that []int IS A IntList by definition, no ?
> Meaning that an “slice” has defined methods Len(), and At(). I would
> personally define other methods on slice too for convenience (like, Insert,
> Delete). The [] notatio
On Wed, Oct 17, 2018 at 3:13 AM alanfo wrote:
> On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote:
>>
>> If overloading [] were disallowed, how would one write a generic function
>> taking a single argument of type either []int or a user-defined type with
>> similar behavio
Yes, that's a fair point.
As I was wobbling anyway, I'll give way on that one :)
Alan
On Wednesday, October 17, 2018 at 6:47:25 PM UTC+1, Patrick Smith wrote:
>
> On Wed, Oct 17, 2018 at 3:13 AM alanfo >
> wrote:
>
>> On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote:
>>>
Patrick Smith :
> Sorry if I was unclear. I wanted to know, not how it could be done under
> some other proposal (such as adding methods to built-in types), but how
> Alan or Eric would do it in their proposals for operator overloading.
I don't see any intrinsic problem with allowing "implements [
Patrick Smith :
> If I understand correctly, you would make a copy of the entire list in
> order to be able to iterate over it? This seems inefficient.
This actually references something that has been a pain point in my
Python translation: absence of iterators.
I have a very simple idea about how
On Sun, Oct 28, 2018 at 7:00 AM Scott Cotton wrote:
>
>
>
> On Thursday, 18 October 2018 08:00:56 UTC+2, Beoran wrote:
>>
>> After reading his proposal, I think you should help Burak Sedar work out his
>> proposal in the other thread.
>
>
> Where is Burak Sedar's proposal?
https://gist.github.co
22 matches
Mail list logo
