My apologies for the link. Google groups on mobile isn’t really working. https://girhub.com/Skarlso/tuple
On Friday 9 August 2024 at 07:57:33 UTC+2 Gergely Brautigam wrote: > 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/8237baf9-f60f-47c4-b1b3-f43019592992n%40googlegroups.com.
