Sorry for interfering. I've gathered statements and expressions which look like candidates for interface-based generalization. Interface and method names are just placeholders. Generic interfaces for collections like slice or map are different beasts. Will post thoughts on them later.
I personally think that most used interface wrappers for predefined types would be range support and generalized collections. Maybe custom key types for maps and custom map hasher. *Comparison operators* "==", "!=", "<", ">", "<=", ">=" These can be split into two groups - equatable and ordered. Not all types which may be compared equals can be ordered type Equatable[T] interface { Equals(T, T) bool } type Ordered[T] interface { Compare(T, T) int // < 0 if less, > 0 if greater, 0 if equals } Equals can be easily implemented through Ordered via func[T] (Ordered[T]* self) Equals(left, right T) bool { return self.Compare(left right) == 0 } Possible application for default interface methods but off-topic here *Arithmetic operators* *Unary operators "+", "-", "^"* type UnaryOp[T] interface { Op(T) T } where Op can be Plus, Minus, BitwiseComplement *Binary operators "+", "-", "*", "/", "%", "&", "|", "^", "&^"* type BinaryOp[T] interface { Op(T, T) T } where Op is "Add", "Sub", "Mul", "Div", "Mod", "BitAnd", "BitOr", "BitXor", "BitAndNot" Bit-shift operators look almost the same except having different second argument type BinaryOp[T] interface { Op(T, uint) T } where "Op" is "ShiftLeft" or "ShiftRight" *Assign-op operators "+=", "-=", "*=", "/=", "%=", "&=", "|=", "^=", "&^="* type BinaryOpAssign[T] interface { OpAssign(T) } where Op is "Add", "Sub", "Mul", "Div", "Mod", "BitAnd", "BitOr", "BitXor", "BitAndNot" Default implementation through normal operation would look like func[T] (BinaryOp[T]* self) OpAssign(right T) { *self = self.Op(*self, right) } Except shift operators which would look like type BinaryOpAssign[T] interface { OpAssign(uint) } where "Op" is "ShiftLeft" or "ShiftRight" *String concatenation* Uses interfaces "BinaryAdd" and "BinaryAddAssign" *Logical operators* Applied only to booleans, so I see no good reason to add generic interfaces for them *Address operators* Should not have their own interface since they don't assume any kind of type-specific behavior *Receive operator and send statement* May be considered in future. ATM I don't see good application for channel-like types except channels themselves *Increment and decrement* type Incrementable[T] interface { Increment() } type Decrementable[T] interface { Decrement() } *Assignment* Not subject for generalization since it shouldn't be overridden *For statements with range clause* type Range[K, V] interface { Next() K, V, bool } Slice's or string's key would be respective index Channel looks more like exception here since it introduces asynchronous iteration and produces single value. On Saturday, August 15, 2020 at 3:14:30 PM UTC+3 rog wrote: > On Sat, 15 Aug 2020 at 04:57, Patrick Smith <pat42...@gmail.com> wrote: > >> On Thu, Aug 13, 2020 at 11:25 PM Patrick Smith <pat42...@gmail.com> >> wrote: >> > I tried out a few different implementations, evaluating the polynomial >> > instead of finding roots, >> > at https://go2goplay.golang.org/p/g8bPHdg5iMd . As far as I can tell, >> > there is no sensible way to >> > do it with an interface that is implemented directly by *big.Float; we >> > need to wrap *big.Float >> > in a wrapper type in any case. >> >> After looking at the draft again, and seeing the Settable example >> there, I realized we can do it using big.Float directly, but it needs >> two interfaces, one matching big.Float and one matching *big.Float. I >> have updated my examples at https://go2goplay.golang.org/p/auSkvhWSNHn > > > I think that works pretty well, and seems to be the direction that things > are going in. > Here's your example cleaned up a bit to show just that latest example, and > also > showing how it looks when adapting a built-in type: > > https://go2goplay.golang.org/p/eFIvHocOC75 > > It's possible to build a generic adaptor type from the value-style > interface to the pointer-style interface, which you might find interesting: > > https://go2goplay.golang.org/p/NiQY_-kWvu8 > > This could *almost* work on image.Point, except that Point.Mul has the > wrong signature. > > cheers, > rog. > >> >> . > > >> >> -- >> 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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAADvV_vxU7nUJ16X5xwBYhiOPVrzp%3DzrX%3DU4UTgBsOQJ2RnMuQ%40mail.gmail.com >> . >> > -- 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/a5eb1222-d1f5-4f73-8ad7-5efc05f7a96bn%40googlegroups.com.