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.

Reply via email to