On 3/17/21 12:06 PM, jmh530 wrote:
> On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat wrote:
>> On Wednesday, 17 March 2021 at 10:54:10 UTC, jmh530 wrote:
>>>
>>> This is one of those things that is not explained well enough.
>>
>> Yes.
>> I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property 
>>
>>
>> "That a slice own or not its memory is purely derived from the pointed area."
>>
>> could perhaps better be said
>>
>> "A slice is managed by the GC when the memory it points to is in GC memory"?
> 
> I probably skimmed over the link when I originally read it without really understanding it. I'm able to understand it now.
> 
> I think the underlying issue that needs to get explained better is that when you do
> int[] x = [1, 2, 3];
> the result is always a GC-allocated dynamic array. However, z below
> int[3] y = [1, 2, 3];
> int[] z = y[];
> does not touch the GC at all. For a long time, I operated under the assumption that dynamic arrays and slices are the same thing and that dynamic arrays are always GC-allocated. z is obviously a slice of y, but it is also a dynamic array in the sense that you can append to it and get an array with one more member than y (except in @nogc code). However, when appending to z, it seems that what's really happening is that the GC is allocating a new part of memory, copying over the original value of y and then copying in the new value. So it really becomes a new kind of thing (even if the type is unchanged).
> 
> One takeaway is there is no issue with a function like below
> @nogc void foo(T)(T[] x) {}
> so long as you don't actually need the GC within the function. A static array can be passed in just using a slice.

This is why I view slices as not dynamic arrays.

I think of a slice as pointing at memory. When you append it effectively:

1. Checks to see if the underlying memory is GC allocated.
2. If not, it allocates new GC memory to hold the original memory + the appended data
3. It appends the data to the GC block that it now must point at.

In this way, it presents a dynamic array *interface*, but it's not necessarily pointing at a dynamic array type (at least in the way I think of a dynamic array type).

I've had online battles about this terminology, and people asked me to change my array article to disavow this distinction, but I'm not going to change it. It's so much easier to understand.

-Steve

On 3/17/21 3:54 AM, jmh530 wrote:
> On Tuesday, 16 March 2021 at 23:49:00 UTC, H. S. Teoh wrote:

>>     double[] data;
>>     data = cast(double[]) malloc(n * double.sizeof)[0 .. n];

> This is one of those things that is not explained well enough.

I have something here:


http://ddili.org/ders/d.en/pointers.html#ix_pointers.slice%20from%20pointer

Ali

On Wednesday, 17 March 2021 at 16:20:06 UTC, Steven Schveighoffer wrote:
> [snip]
> 
> I've had online battles about this terminology, and people asked me to change my array article to disavow this distinction, but I'm not going to change it. It's so much easier to understand.
>
> -Steve

I'll be on your side on that one.

On Wednesday, 17 March 2021 at 16:32:28 UTC, Ali Çehreli wrote:
> On 3/17/21 3:54 AM, jmh530 wrote:
>> On Tuesday, 16 March 2021 at 23:49:00 UTC, H. S. Teoh wrote:
>
>>>     double[] data;
>>>     data = cast(double[]) malloc(n * double.sizeof)[0 .. n];
>
>> This is one of those things that is not explained well enough.
>
> I have something here:
>
>
> http://ddili.org/ders/d.en/pointers.html#ix_pointers.slice%20from%20pointer
>
> Ali

That's a little advanced, I think. And you also have
http://ddili.org/ders/d.en/slices.html
saying that slices are just another name for dynamic arrays.

On 3/17/21 10:21 AM, jmh530 wrote:

> That's a little advanced, I think. And you also have
> http://ddili.org/ders/d.en/slices.html
> saying that slices are just another name for dynamic arrays.

I don't fully agree with myself there. :) Slices are interfaces to many different kinds of consecutive objects: nameless dynamic arrays owned by the GC, static arrays, dynamic arrays managed by the programmer, etc.

The conflation stems from the fact that the storage for the slice becomes "a dynamic array owned by the GC" as soon as new storage is needed: appending, concatenation, and increasing the length. The slice leaves its existing storage just like that.

Ali

On Wednesday, 17 March 2021 at 16:20:06 UTC, Steven Schveighoffer wrote:

It's important to understand that [] is just a practical syntax for a fat pointer.

Thinking of [] just as a fancy pointer helps imho to clarify that the pointed to memory nature is independant of the pointer itself.

On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat wrote:

> I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property
>
Sorry for this off-topic question. I am amazed with eye catchy look of that d-idioms page. I want to create a page like it for my ongoing project. I think it's a good form of documentation. How do i create one like it ?

On Thursday, 18 March 2021 at 18:48:26 UTC, Vinod K Chandran wrote:
> On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat wrote:
>
>> I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property
>>
> Sorry for this off-topic question. I am amazed with eye catchy look of that d-idioms page. I want to create a page like it for my ongoing project. I think it's a good form of documentation. How do i create one like it ?

The source code is here: https://github.com/p0nce/d-idioms/

On Thursday, 18 March 2021 at 21:21:37 UTC, Paul Backus wrote:

>
> The source code is here: https://github.com/p0nce/d-idioms/

Thanks for the answer. But it's more complex than I thought. Something like Latex was in my mind.

On Thursday, 18 March 2021 at 17:57:30 UTC, Patrick Schluter wrote:
> It's important to understand that [] is just a practical syntax for a fat pointer.
>
> Thinking of [] just as a fancy pointer helps imho to clarify that the pointed to memory nature is independant of the pointer itself.

I think they are arrays alright. What's missing is expression of ownership, because D follows traditional language design approach, and traditionally ownership wasn't expressed in language and was done by convention.