This works:
n, _ := strconv.ParseInt(string(x), 10, 64)
Go intentionally does no automatic type conversion, not even this:
var a int32 = 1234
var b int64 = a // error: use int64(a) instead
It would be inconsistent if passing "mystr" to a function which accepts
"string" were performed automatically.
On Friday, 25 March 2022 at 22:41:15 UTC sam.a....@gmail.com wrote:
>
> My workaround like is something like `type <Purpose>String struct{string}.
> It can be reasonably treated as a string for most cases in which as string
> is needed, and it lets you convert back conveniently from any scope in
> which it's reasonable for your program to know the difference.
> On Friday, March 18, 2022 at 12:46:34 AM UTC-5 Henry wrote:
>
>> My own preference is to have a small number of methods and put the
>> general functionalities into functions. By putting the general
>> functionalities into functions, you allow code reuse. In object-oriented
>> programming, you normally attach as many functionalities as possible to
>> their corresponding types and achieve code reuse via inheritance. Since Go
>> does not have inheritance, you can achieve a similar effect with standalone
>> functions.
>>
>> On Friday, March 18, 2022 at 11:26:51 AM UTC+7 Ian Lance Taylor wrote:
>>
>>> On Thu, Mar 17, 2022 at 7:17 PM Zhaoxun Yan <yan.z...@gmail.com> wrote:
>>> >
>>> > I just came across this taboo in golang - new methods cannot be added
>>> to an existing type:
>>>
>>> Yes. If we didn't have this prohibition, then the set of interfaces
>>> satisfied by a type would depend on which package was using the type.
>>>
>>> See the discussion at https://go.dev/issue/21401.
>>>
>>> Ian
>>>
>>
--
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/2f37fcfa-06d8-4c75-952d-7d1be5757b29n%40googlegroups.com.
