Re: [go-nuts] Re: why treat int and []int differently here?

> @all, thanks for the explanation! in my view, all the "details" come from reasoning about Go through the sieve of other programming languages. nothing wrong in doing that, as long as the original intention is understood. for me, Go will always be looked through the sieve of C, in particular the

[go-nuts] Re: why treat int and []int differently here?

@all, thanks for the explanation! Golang is a simple language full of details. On Sunday, July 17, 2016 at 4:15:12 AM UTC+8, T L wrote: > > > package main >> >> func fi(i int) {} >> func fis(is []int) {} >> >> type TI int >> type TIS []int >> >> func main() { >> var ti TI >> fi(ti) //

Re: [go-nuts] Re: why treat int and []int differently here?

In that code, there is no silent conversion. In AddOne, the constant 1 is inferred to be of type Int (not int), and so you're just adding Int to Int to get another Int. On Sat, Jul 16, 2016 at 5:35 PM pi wrote: > Sorry my bad. Forget to add "in many cases" to last

Re: [go-nuts] Re: why treat int and []int differently here?

On Sun, Jul 17, 2016 at 1:52 AM, Dan Kortschak < dan.kortsc...@adelaide.edu.au> wrote: > On Sat, 2016-07-16 at 15:36 -0700, pi wrote: > > `type` is not `typedef` in Go. `type` introduces completely new type. > > Fortunately, Go can cast these types to base type silently, i.e. > > explicict > >

Re: [go-nuts] Re: why treat int and []int differently here?

On Sat, 2016-07-16 at 15:36 -0700, pi wrote: > `type` is not `typedef` in Go. `type` introduces completely new type. > Fortunately, Go can cast these types to base type silently, i.e. > explicict > cast int(valueOfTI) is unnecessary. This is not true; a named concrete type is never silently