So, my point is that operator naming should be standardized, or we might've
introduce an additional construct like
```
type Neg operator - func() Neg
type Compare operator <=> func(Compare) int
```
On Friday, May 10, 2019 at 9:15:30 PM UTC+3, Yuriy Yarosh wrote:
>
> So, there were plenty of generics proposal, and hopefully I'll get some
> constructive feedback about this one.
>
> Syntax Example:
>
> ```
> type MyGeneric interface {
> int32
> uint32
> float32
> float64
> ANumber
> }
>
> type ANumber interface {
> Plus(ANumber) ANumber
> Minus(ANumber)
> Compare(ANumber) int
> Neg() ANumber
> }
>
> func ConstrainedFunc(gen MyGeneric) interface{uint32, int32} {
> return gen - 1; // will work only for uint32 and int32 as gen, because
> return generic type will match the generic, the return type will get a type
> constraints
> }
>
> func GenFunc(gen MyGeneric) MyGeneric {
> return gen - 1; // will work only for every type in MyGeneric, because 1
> and -1 can be casted to any of the respective types
> }
>
> func ConstrainedFunc(gen interface{uint32, int32}) MyGeneric {
> return gen - 1;
> }
>
> ```
>
> If type or an interface implements all the respective methods it will
> trigger the implicit codegen for a type cast.
>
> So, unary/binary type operators could be represented with the respective
> interface methods, and their naming should be standartized.
> Of course, it's a point of a separate discussion.
>
> But for now it's the most viable solution, as for me, which could've
> replace existing reflection and switch interface{} boilerplate and
> respective codegen...
> The other strong point is that it could be cached and built incrementally
> too.
> Such generics impl will not break any of the existing code, or
> conventions, will not introduce any overhead, and will be able fail at
> compile time when any of the target types do not impl the respective
> methods and operators.
>
> Operator names could've been plain + - <=> but I've seen companies
> switched from Scala to Golang just because of "wtf is a spaceship operator"
> situation... so, meh.
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/28ee5338-7251-46c7-86ae-f2b4e6b5bfee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
