Hello. I actually implemented a Tupke logic here https://github.con/Skarlso/tuple.
I find this a much better way to deal with tuples instead of the indexing logic. And it’s using generics as well. Feel free to borrow stuff. 😊 On Friday 9 August 2024 at 02:19:22 UTC+2 Jolyon Direnko-Smith wrote: > My $0.02 on this > > First, to address the use cases in your question, Golang does not have > custom operators so the value of tuples in assisting with their > implementation is moot. (and, IMHO, should resist incorporating them; > someone should not have to consult the source for a type to understand > whether what should be a standard operator works in an expected and > intuitive way or implements some exotic behaviour for the convenience of a > "clever" implementation). > > Second, you don't need to implement a custom == operator to compare custom > struct types; the implementation of == in Golang already covers the > comparison of structured value types in a logical, intuitive and type-safe > manner. > > []any could be a perfectly good representation of a tuple in some cases, > but context is king. Personally, I would resist the temptation to create a > "tuple type/package" to cater for all possible use cases. > > If a project requires tuples of any type with support for equality testing > then implement a tuple type (in that project) to support what that project > needs (and nothing more); it will be trivial (type tuple []any, with an > Equals(tuple) bool method to perform the equality tests). If a different > project requires tuples which support a mix of strings and ints and > "greater-than"/"less-than" comparison support then implement an appropriate > tuple type for that use case. The Equals() method for the latter will be > slightly more complicated than the first, but still far simpler to > implement than a fully versatile tuple type. > > If a project requires different tuple capabilities in different use cases > then implement appropriate, distinct tuple types for each use case. A > bonus feature of this approach: you won't be able to inadvertently use "a > tuple of any type supporting equality", where your code requires "a tuple > of string/int supporting gt/lt comparison". > > ymmv > On Friday 9 August 2024 at 07:41:00 UTC+12 Jan Mercl wrote: > >> On Thu, Aug 8, 2024 at 9:35 PM 'lijh8' via golang-nuts >> <golan...@googlegroups.com> wrote: >> >> > I try to use slice of any to imitate the tuple type, >> > and use this function to compare two slices: a, b. >> > >> > How can I improve it? >> >> Take a look at https://pkg.go.dev/slices#Compare if it can fit your use >> case. >> > -- 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/1a2eee74-56a4-404d-99c3-6430a3eff0ffn%40googlegroups.com.
