On Jun 26, 2020, at 2:59 PM, Ian Lance Taylor wrote:
>
> I honestly don't think that append is an example of worse-is-better.
> I think it's an example of preferring to pass and return values rather
> than pointers. The language could easily have made append take a
> pointer to a slice as its fi
> On Jun 26, 2020, at 2:52 PM, Tyler Compton wrote:
>
> On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote:
>> Also, to this specific point: this exact approach, as with much of Go,
>> embodies the Bell Labs approach to design (for better or for worse, and with
>> good reason). Sometimes w
On Fri, Jun 26, 2020 at 11:52 AM Tyler Compton wrote:
>
> On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote:
>>
>> Also, to this specific point: this exact approach, as with much of Go,
>> embodies the Bell Labs approach to design (for better or for worse, and with
>> good reason). Sometimes
On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote:
> Also, to this specific point: this exact approach, as with much of Go,
> embodies the Bell Labs approach to design (for better or for worse, and
> with good reason). Sometimes we have to live with the artifacts of
> evolution.
>
One interest
On Jun 26, 2020, at 1:41 PM, Robert Engels wrote:
>
> My opinion is that if RTFM is required more than once for a core concept
> there may be a design problem. It clearly bites a lot of people. Slices are a
> higher level struct, as the underlying array is the same as Java, but Java
> doesn’t
On Jun 26, 2020, at 1:41 PM, Robert Engels wrote:
>
> I don’t think “how it works” is the confusion, more of “how to use it
> properly”
>
> My opinion is that if RTFM is required more than once for a core concept
> there may be a design problem. It clearly bites a lot of people. Slices are a
I don’t think “how it works” is the confusion, more of “how to use it properly”
My opinion is that if RTFM is required more than once for a core concept there
may be a design problem. It clearly bites a lot of people. Slices are a higher
level struct, as the underlying array is the same as Java,
"If the capacity of s is not large enough to fit the additional values,
append allocates a new, sufficiently large underlying array that fits both
the existing slice elements and the additional values. Otherwise, append
re-uses the underlying array."
That seems pretty explicit to me? That's fro
> On Jun 26, 2020, at 9:28 AM, Robert Engels wrote:
>
>> On Jun 26, 2020, at 8:23 AM, David Riley wrote:
>>
>> You are correct, the programmer needs to read the manual. Slices are
>> "windows" into their underlying array, therefore assigning data into slices
>> tied to a given array changes t
That is not quite true. Once is it extended beyond the current capacity you
will have a new backing array and the slices will diverge.
> On Jun 26, 2020, at 8:23 AM, David Riley wrote:
>
> On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote:
>>
>> Essentially based on the existing cap
On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote:
>
> Essentially based on the existing capacity, the assignment of one slice
> effects other slices. These are stemming from the underlying pointer
> arithmetic and seems inconsistent. Looks like programmer needs to know the
> history o
On Thu, Jun 25, 2020 at 5:58 PM wrote:
>
> Hi, I am trying to learn Go (I have been working with C++ for a while). I
> see inconsistency of slices and append
>
>
> func main() {
>
> // append example within capacity
> var m []int = []int{1, 2, 3}
> a := m[0:2]
> b := append(a, 4)
> a[0] = -1
>
>
12 matches
Mail list logo
