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.
