Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Saturday, March 4, 2017 at 12:56:23 AM UTC+8, James Bardin wrote: > > > > On Friday, March 3, 2017 at 11:47:10 AM UTC-5, T L wrote: >> >> >> Yes, the suggestion needs more allocations in creating new string and >> slice values. >> But it makes copying string and slice values a little faster

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 11:47:10 AM UTC-5, T L wrote: > > > Yes, the suggestion needs more allocations in creating new string and > slice values. > But it makes copying string and slice values a little faster and a little > less memory consuming. > > In most cases there is no difference

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

I seriously doubt that it's actually going to make anything faster in reality. I bet that a) copying one word or three words doesn't actually make any observable difference, but b) it's not going to actually help a lot, because in most cases you will need to copy the indirected struct anyway and

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Saturday, March 4, 2017 at 12:47:10 AM UTC+8, T L wrote: > > > > On Friday, March 3, 2017 at 10:32:25 PM UTC+8, Ian Lance Taylor wrote: >> >> On Fri, Mar 3, 2017 at 5:31 AM, T L wrote: >> > >> > On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote: >> >> >> >>

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 10:32:25 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Mar 3, 2017 at 5:31 AM, T L > wrote: > > > > On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote: > >> > >> Perhaps you can help the discussion by explaining the advantages you

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote: > > Perhaps you can help the discussion by explaining the advantages you see > in that change? > The advantage is to save a few bytes memory and make faster copying. > > > On Fri, 3 Mar 2017, at 11:44 AM, T L wrote: > > > > On

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

Perhaps you can help the discussion by explaining the advantages you see in that change? On Fri, 3 Mar 2017, at 11:44 AM, T L wrote: > > > On Friday, March 3, 2017 at 4:27:02 PM UTC+8, Konstantin > Khomoutov wrote: >> On Thu, 2 Mar 2017 23:49:52 -0800 (PST) >> T L

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 4:27:02 PM UTC+8, Konstantin Khomoutov wrote: > > On Thu, 2 Mar 2017 23:49:52 -0800 (PST) > T L wrote: > > > After all, the len and cap fields of any value of string and slice > > values are immutable. > > Could you elaborate? > > Are you

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

Very basic explanation in the faq https://golang.org/doc/faq#methods_on_basics On 03/03/2017 08:49, T L wrote: After all, the len and cap fields of any value of string and slice values are immutable. -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Fri, Mar 3, 2017 at 6:49 PM, T L wrote: > After all, the len and cap fields of any value of string and slice values > are immutable. > This is slices and strings are currently. A string value contains a length and a pointer to some bytes. A slice contains a length,

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Thu, 2 Mar 2017 23:49:52 -0800 (PST) T L wrote: > After all, the len and cap fields of any value of string and slice > values are immutable. Could you elaborate? Are you suggesting to replace var s []string if len(s) ... if cap(s) ... with if s.len ... if

[go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

After all, the len and cap fields of any value of string and slice values are immutable. -- 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