Constraints in Go

1. go

   1 2,197 125,108 10.0 Go

   The Go programming language

   

   The difference between types.Implements and types.Satisfies is mainly a history reason, a tradeoff between keeping backward compatibility and theory perfection.

   It is pity that Go didn't support the "comparable" interface from the beginning. If it has been supported since Go 1.0, then this tradeoff can be avoided.

   There are more limitations in current Go custom generics, much of them could be removed when this proposal (https://github.com/golang/go/issues/70128) is done.

   I recommend people to read Go Generics 101 (https://go101.org/generics/101.html, author here) for a thoroughly understanding the status quo of Go custom generics.

2. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

3. go-sumtype

   2 12 431 2.7 Go

   A simple utility for running exhaustiveness checks on Go "sum types."

   

   No, you have created "a type that allows you to do all the things that int, uint, and string can all do". That includes >, and since that's the only thing you used in Max, everything works fine. You don't have a sum type; you have "a type that is either an int, a uint, a string, or something that backs to them".

   For one thing, as you've specified it, you don't even have a closed set of types. Off in another package I can declare a "type MyInt int" and use your Max on it, so if you tried to type switch in your Max function, you would not know about my type, and it is arguably the defining characteristic of a sum type that you can know all the branches it has.

   You can fix that by knocking off the tilde, but then you still have the problem that it is not legal to use "switch val := a.(type)", which is basically the level of deconstruction of a type that Go permits, because when the Max function is running, it is not running on a value of type "Ordered"; it literally has a value of the type you passed in. That's the whole point of generics, to have values of the concrete type that was passed in, and not a sort of "sum type".

   https://go.dev/play/p/MGhRjwvpdTh

   Max doesn't get "a sum type of int, uint, and string"; it gets specifically an int, uint, or string, directly, literally, actually, not any sort of sum type.

   There literally isn't a sum type to be seen here, as in, a type. Ordered isn't functioning as a type here.

   If you want a sum type in Go, use closed interfaces: https://github.com/BurntSushi/go-sumtype If you're willing to accept what you've written as a sum type, you should be even more willing to accept this method, which actually produces a reasonable approximation of one.

4. bob

   3 33 860 9.1 Go

   SQL query builder and ORM/Factory generator for Go with support for PostgreSQL, MySQL and SQLite (by stephenafamo)

   

Suggest a related project