The Address type in crypto.gno and crypto.go have different types

[jefft0]

crypto.gno defines Address as a string.

crypto.go defines Address as a byte array.

It's not a show-stopper but it has caused me confusion as I switch between Go and Gno. If it's worthwhile to address this (pun intended), here's a suggestion. crypto.go also defines Bech32Address as a string. Maybe rename Address in crypto.gno to Bech32Address? (This is a nice, descriptive name.)

[thehowl]

crypto.Bech32Address == std.Address even internally within the GnoVM.

I understand your proposal of switching std.Address to Bech32Address but it seems to me to be quite long for what is a fundamental type used within realm programming, so I would actually be slightly more inclined to do the opposite. Looking for other opinions and arguments, though.

[jefft0]

I'm not sure what you mean by "crypto.Bech32Address within the GnoVM". The GnoVM runs *.gno code, right? There is no crypto package in the *.gno code. So, maybe you mean something like "std.Address within the GnoVM == crypto.Bech32Address outside the GnoVM"? (This is part of the confusion.)

[thehowl]

Apologies, I phrased it a bit confusingly without context.

To understand what I'm talking about see these two snippets:

gno/gnovm/stdlibs/stdlibs.go

Line 17 in 846956f

store.AddGo2GnoMapping(reflect.TypeOf(crypto.Bech32Address("")), "std", "Address")

gno/gnovm/stdlibs/std/context.go

Lines 15 to 16 in 846956f

	OrigCaller crypto.Bech32Address
	OrigPkgAddr crypto.Bech32Address

What I'm trying to say is that the two types in the two languages are effectively equivalent. ie. GetOrigCaller retrieves the value in the ExecContext (second snippet) which is a crypto.Bech32Address, not an Address. So a bit confusing, but what I'm saying is that even in the ways the GnoVM generates std.Address values they are always Bech32Addresses in Go.