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 <tapi...@gmail.com> 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 s.cap ...
>>
>> ?
>>
>> If yes, then what would be the prospective benefits?
>
>
> No, I mean why not define string and slice as
>
> type string struct {
> underlyingString *struct {
> data *byte
> len int
> }
> }
>
> type slice struct {
> underlyingSlice *struct {
> underlyingElements unsafe.Pointer
> len int
> cap int
> }
> }
> instead of the current:
>
> type string struct {
> data *byte
> len int
> }
>
> type slice struct {
> underlyingElements unsafe.Pointer
> len int
> cap int
> }
>
>
>
>
> --
> 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.
--
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.
