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 problem with the assignment forms of basic operators: +=, *=, |= and the
like. If the basic operator were overloaded then I think it should follow
automatically that the assignment form should be overloaded as well.
Opinions will, of course, differ on which operators should permit
overloading. My problem with the channel operator is that firstly it has
two forms, send and receive, and secondly it is not a standard operator
within the C family of languages - it's a Go special - and I think I'd find
it very confusing if it were overloaded to perform other duties even if
they were channel related.
The equality operators really are a thorny problem. If, for example, you
decided to overload a struct so that it implemented the < operator based on
the value of a single numeric field, this would then be inconsistent with
the existing meaning of == where *all* the fields need to be equal. On the
other hand, if you decided to allow == to be overloaded to be consistent
with <, you might end up with a definition which was at odds with the
standard use of this operator in map keys.
I don't think there's really a satisfactory answer to this apart from
introducing new operators for 'ordered equality' outlandish though it may
seem :)
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
compiler all sorts of problems and anyone reading the code would wonder
whether T, Node, Edge etc. were concrete types defined elsewhere in the
package or type parameters of a generic function.
Alan
On Tuesday, October 16, 2018 at 1:05:20 PM UTC+1, Eric Raymond wrote:
> 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 even write-only code.
>>
>
> Strongly agreed. I too would be OK with only allowing a simple subset of
> operators to be overloaded - excluding && and ||, notably; I wrote up that
> possibility as a way of exploring the edges of the proposal. not as a
> serious amendment.
>
> On the other hand, I think it's important as a matter of good interface
> psychology not to be arbitrary. That is, having introduced "implements",
> the question "why can't I overload operator foo" should always have an
> answer that is principled and specific to a given operator. For example,
> we might disallow / because the relationship between its operand types and
> result type is not obvious by inspection.
>
> That criterion might also be a principled way to knock out short-circuit
> use of && and || on non-booleans. On the other hand, I don't know that I
> want to be quite that austere. If someone said to me "I want to overload
> <- for a struct wrapping a channel type, why is that excluded," I don't
> think I'd have a satisfactory answer
>
> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and
>> yes - equality operators - as well because I believe to do otherwise would
>> be very confusing.
>>
>
> I wouldn't exclude ==. Even if we have to have a special exclusion for
> pointer types, any generic/overloading system that didn't support that is
> something most people who want generics would regard as a cruel tease.
>
> := is not an operator at all in Go (and nor is =), unless I'm missing
> something basic. I don't usually think of [], {}, () as operators either,
> though one could make a case for [] as a dyadic indexing/mapping operator.
> I wouldn't be hostile to including that in the allowed set, but I wouldn't
> cry if it were excluded either.
>
> Another possibility would be to introduce two new ordering operators,
>> perhaps >< (for ==) and <> (for !=), which *could* be overloaded though
>> the first of these would take some getting used to!
>>
>
> This is not keeping it simple. Excuse me, but I think you are now making
> the sound of someone getting lost in the weeds. ;-)
>
> As for Eric's proposal - using an 'implements' keyword - I like it for the
>> following reasons:
>>
>> 1. It avoids the need to make up a long list of names for the operators
>> which folks either have to remember or look up in the spec.
>>
>> 2. It makes it easier to retrofit operator overloading to existing types
>> for which suitable methods have already been defined.
>>
>> 3. As 'implements' would only be used in contexts which don't exist at
>> present, it needn't be a 'full' keyword and would therefore be backwards
>> compatible.
>>
>
> These points had occurred to me, though I did not make them explicit in my
> proposal. In my invention process, the idea of using operator signatures
> as implied contracts came first. I was then searching for a way to restrict
> the parse context in which new syntax might collide with identifiers in
> existing code and came up with the "implements" clause and its location
> just before a method's leading { as a way to accomplish that restriction.
>
>
>> One area that hasn't been addressed so far is conversions. To convert to
>> say, int64, I'd suggest 'implements int64()' and to convert from int64
>> perhaps 'implements T(int64)' where T is the method's receiver type. TBH, I
>> don't particularly like the idea of user-defined conversions at all but
>> they're probably inevitable if you want to have unified generic constraints
>> and at least they'd always be explicit.
>>
>
> I am neutral on whether the contract system should support conversions.
> If the consensus is that they're needed, fine by me; if not, also fine by
> me. I do not regard either position as a hill that "implements" should die
> on.
>
>
>> Subject to all this, I think it might well be possible to get rid of
>> contracts and just use interfaces for generic constraints.
>>
>
> That was more or less my goal. All the contract proposals I have seen
> struck me as clever but overweight.
>
>
--
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.
