If you consider lv and rv in BCPL, and see how that becomes * and & in B
and stays that way in C/C++/... it may be more clear.
The C declaration syntax was revolutionary for being inside out. “int *p”
really means “p is the type of variable where *p means an int.” Your
argument seems right, in the outside in order of most every non-C language,
we are saying “var p X” where X should mean “address of an int” and that
is, as you say, “& int”
The installed base of programmers expects it the other way, though. 🙂
On Sun, Mar 10, 2019 at 9:18 AM 박민우 <minwoo33p...@gmail.com> wrote:
> Thank you for the explanation!
>
> and sorry for the typo,
> I meant to say something like,
> someInteger := 0
> q := &someInteger
> or
> q := &SomeStructure{}
> as an example of & symbol as "pointer to".
>
> Anyway, I would say C's declaration syntax
> int *p
> makes more sense because *p , "where p points to", is int.
> However, it also makes sense to use the same asterisk for pointer
> declaration.
> Thank you for mentioning creation of other types too,
> It really helped me get over it ! :)
> I believe I just need some getting used to !
>
>
>
> 2019년 3월 10일 일요일 오후 11시 46분 13초 UTC+9, Ian Lance Taylor 님의 말:
>
>> On Sun, Mar 10, 2019 at 7:41 AM 박민우 <minwoo...@gmail.com> wrote:
>> >
>> > I am new to Go and I have read Go;s-declaration-syntax documentation.
>> >
>> > It states that:
>> >
>> > p: pointer to int
>> >
>> > Would be written as:
>> > p *int
>> >
>> > However, other than declaration syntax, "&" is the symbol for "the
>> pointer to" like,
>> > q := &int
>> > The above code would be the same as:
>> > var q *int
>> > q = new(int)
>> > So, I would suggest,
>> > var q &int
>> > to be more consistent, but Go's syntax wouldn't permit this.
>> >
>> > Is there a reason behind this decision?
>> > I will get used to the syntax after a while, but in need of some
>> reasonable explanation.
>>
>> The reason boils down to: this is how it is done in C. A pointer type
>> is written as *int. A pointer variable q is dereferenced as *q. That
>> is also what C looks like.
>>
>> Note that in Go there is no particular correspondence between the way
>> that a type is written and the way that a value of that type is
>> created. A map or chan type is created using the builtin function
>> make, or using a composite literal. An int type is created by
>> declaration, or implicitly. A slice type can be created by using a
>> slice expression on an array value. The consistency you suggest just
>> doesn't exist for Go.
>>
>> 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.
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
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.
For more options, visit https://groups.google.com/d/optout.
