Hi all, I have been wondering about the following for quite a while.
In Go when assigning or passing values we all know we need to type-cast between two values whose types are derived from the same base type, and I assume most (all?) of us view that as good software engineering. For example: type Name string type Code string var name Name = "Hello" var code Code = Code(strings.ToLower(string(name))) However, we do not have to cast in some cases, and AFAIK no one sees this as a negative e.g.: fmt.Printf("%s: %s\n", name, code) Given this I am now pondering why it would not be possible and acceptable it Go could allow relaxing of the need to type cast — on an opt-in basis — when going from a derived time to its base type? For example, if `~` allowed us to opt-in to relaxed type casting and the signature in the standard library was `strings.ToLower(s ~name)` then we could drop the need to cast with `string(name)` for the prior case, like so: var name Name = "Hello" // var code Code = Code(strings.ToLower(string(name))) ==> the current requirement var code Code = Code(strings.ToLower(name)) The reason I am asking for this is that I really like to define derived types for scalar types to allow for more type safety in my programs. But doing that in many cases results in a lot of added complexity when I have to constant case back to the derived types when using generic function, especially for functions in the standard library. And most teams I have worked on have pushed back on using types in this way because they would rather have the simplicity of not having to constantly cast types instead of the type safety provided by having bespoke types for each different type of values stored in a built-in type. Is there a reason I am missing why it would be problematic if Go allowed developers to relax the need for type casting when going from a more specific type to a more general type? Os is there some way in which this might cause backward compatibility issues that I am not seeing? To be clear — if you are just scanning this email before replying — I am only suggesting that type relaxation is opt-in for type declarations so it would not change the behavior of any of your existing bespoke code. However, I am hoping as part of such a change that the standard library functions could be updated to opt-in where applicable, as that is where I would see the biggest benefit. -Mike P.S. I created a simple example showing a use-case how such relaxation might be used: https://go.dev/play/p/yllJ0CNZaAI -- 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 visit https://groups.google.com/d/msgid/golang-nuts/6F37DA0C-B8D3-4B0F-A4D2-F02CA8E3E068%40newclarity.net.