"goference"
On Fri, Oct 21, 2016 at 10:13 AM, Ian Lance Taylor wrote:
> On Fri, Oct 21, 2016 at 8:59 AM, T L wrote:
>>
>> Is it a good idea to remove the reference words from faq?
>> Go spec did this 3 years ago.
>
> The question makes sense and needs an answer. If someone can rewrite
> it to a
On Fri, Oct 21, 2016 at 8:59 AM, T L wrote:
>
> Is it a good idea to remove the reference words from faq?
> Go spec did this 3 years ago.
The question makes sense and needs an answer. If someone can rewrite
it to avoid the use of the word "reference" while also making it more
clear, then, sure.
I am now enlightened as to why my colleagues were so eager to banish this
term from our documentation.
On 21 October 2016 at 11:59, T L wrote:
>
>
> On Friday, October 21, 2016 at 9:40:09 PM UTC+8, Ian Lance Taylor wrote:
>
>> On Thu, Oct 20, 2016 at 10:47 PM, T L wrote:
>> >
>> > On Friday, Oc
On Friday, October 21, 2016 at 11:37:21 PM UTC+8, Paul Borman wrote:
>
> I think you should clarify that this is because T *only* contains
> pointers. If T were:
>
> type T struct {
> i int
> p *int
> }
>
>
Ian says slice is also a reference type. This type declaration is much like
sli
On Friday, October 21, 2016 at 9:40:09 PM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Oct 20, 2016 at 10:47 PM, T L >
> wrote:
> >
> > On Friday, October 21, 2016 at 1:11:32 AM UTC+8, Ian Lance Taylor wrote:
> >>
> >> On Thu, Oct 20, 2016 at 6:47 AM, T L wrote:
> >> >
> >> > On Thursday, O
Well, from that standpoint, any structure that has a pointer is a reference
type.
On Fri, Oct 21, 2016 at 8:50 AM, T L wrote:
>
>
> On Friday, October 21, 2016 at 11:37:21 PM UTC+8, Paul Borman wrote:
>>
>> I think you should clarify that this is because T *only* contains
>> pointers. If T were
I think you should clarify that this is because T *only* contains
pointers. If T were:
type T struct {
i int
p *int
}
then it would suddenly become non-reference type, as defined in this
thread, as a change to i will not be noticed by other copies of a given T.
-Paul
On Fri, Oct
On Friday, October 21, 2016 at 11:20:44 PM UTC+8, Alan Donovan wrote:
>
> On 21 October 2016 at 11:15, T L > wrote:
>>
>> On Friday, October 21, 2016 at 10:01:43 PM UTC+8, Ian Lance Taylor wrote:
>>>
>>> On Fri, Oct 21, 2016 at 6:52 AM, Henrik Johansson
>>> wrote:
>>> > The confusion I have ha
On 21 October 2016 at 11:15, T L wrote:
>
> On Friday, October 21, 2016 at 10:01:43 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Oct 21, 2016 at 6:52 AM, Henrik Johansson
>> wrote:
>> > The confusion I have had is rather with nilability.
>> > A channel can be nil even though it is not explicit
On Friday, October 21, 2016 at 9:53:14 PM UTC+8, Henrik Johansson wrote:
>
> The confusion I have had is rather with nilability.
> A channel can be nil even though it is not explicitly a pointer.
>
Someone think pointers should be distinguished from
channel/map/slice/interface/function.
For exa
On Friday, October 21, 2016 at 10:01:43 PM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Oct 21, 2016 at 6:52 AM, Henrik Johansson > wrote:
> > The confusion I have had is rather with nilability.
> > A channel can be nil even though it is not explicitly a pointer.
>
> It's a basic design decisio
Yes and once that was clear it quickly became familiar but to people from
other languages (a mix between Java and C perhaps) it can be confusing.
At first it bummed me out that these where special but it is easy to get
used to it.
fre 21 okt. 2016 kl 16:01 skrev Ian Lance Taylor :
> On Fri, Oct
On Fri, Oct 21, 2016 at 6:52 AM, Henrik Johansson wrote:
> The confusion I have had is rather with nilability.
> A channel can be nil even though it is not explicitly a pointer.
It's a basic design decision in Go that every type has a zero value.
For the "reference types" (pointer, channel, map,
The confusion I have had is rather with nilability.
A channel can be nil even though it is not explicitly a pointer.
The whole "call by reference" debate is fun but usually with beer...
fre 21 okt. 2016 kl 15:39 skrev Ian Lance Taylor :
> On Thu, Oct 20, 2016 at 10:47 PM, T L wrote:
> >
> > On
On Thu, Oct 20, 2016 at 10:47 PM, T L wrote:
>
> On Friday, October 21, 2016 at 1:11:32 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Thu, Oct 20, 2016 at 6:47 AM, T L wrote:
>> >
>> > On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote:
>> >>
>> >> What is a pointer wrapper value?
* T L [161021 01:47]:
> This faq, "Why are maps, slices, and channels references while arrays are
> values?", https://golang.org/doc/faq#references.
> thinks maps, slices, and channels are references. I think the "references"
> here means "reference values".
That's not the way I read it. The q
On Friday, October 21, 2016 at 1:11:32 AM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Oct 20, 2016 at 6:47 AM, T L >
> wrote:
> >
> > On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote:
> >>
> >> What is a pointer wrapper value?
> >
> >
> > struct {
> >p *T
> > }
>
On Thu, Oct 20, 2016 at 6:47 AM, T L wrote:
>
> On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote:
>>
>> What is a pointer wrapper value?
>
>
> struct {
>p *T
> }
>
>>
>>
>> in all seriousness, if you review the git history of the Go spec you'll
>> find the word "reference"
On Thursday, October 20, 2016 at 10:34:41 PM UTC+8, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 9:58:46 PM UTC+8, T L wrote:
>>
>>
>>
>> On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote:
>>>
>>> I like Alan's "useful definition" of a semantically reference type,
>>> which inv
On Thursday, October 20, 2016 at 9:58:46 PM UTC+8, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote:
>>
>> I like Alan's "useful definition" of a semantically reference type, which
>> involves shared mutable state.
>>
>> About the string type, I also like the imple
On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote:
>
> I like Alan's "useful definition" of a semantically reference type, which
> involves shared mutable state.
>
> About the string type, I also like the implementation detail that
>
> var string t = s
>
> is O(1) in memory and run
On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote:
>
> What is a pointer wrapper value?
>
struct {
p *T
}
>
> in all seriousness, if you review the git history of the Go spec you'll
> find the word "reference" was purged about two years ago, in effect, to try
> to stem
I like Alan's "useful definition" of a semantically reference type, which
involves shared mutable state.
About the string type, I also like the implementation detail that
var string t = s
is O(1) in memory and running time, i.e. it happens internally to "copy the
reference, not the bytes" :
What is a pointer wrapper value?
in all seriousness, if you review the git history of the Go spec you'll
find the word "reference" was purged about two years ago, in effect, to try
to stem these discussions.
On Thursday, 20 October 2016 16:07:07 UTC+9, T L wrote:
>
>
>
> On Thursday, October 20
On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com
wrote:
>
> On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>>
>> On Wed, Oct 19, 2016 at 12:27 PM T L wrote:
>>
>> Nothing. The language specification does not mention it.
>>
>> People use that term based on d
On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com
wrote:
>
> On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>>
>> On Wed, Oct 19, 2016 at 12:27 PM T L wrote:
>>
>> Nothing. The language specification does not mention it.
>>
>> People use that term based on d
On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>
> On Wed, Oct 19, 2016 at 12:27 PM T L >
> wrote:
>
> Nothing. The language specification does not mention it.
>
> People use that term based on definitions specified for other programming
> languages, but those are not always equal
On Wed, Oct 19, 2016 at 12:27 PM T L wrote:
Nothing. The language specification does not mention it.
People use that term based on definitions specified for other programming
languages, but those are not always equal to each other.
--
-j
--
You received this message because you are subscribe
.
--
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.
29 matches
Mail list logo
