www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Article Contest, first draft] D Slices

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
Having seen quite a few incorrect descriptions of how D slices work  
(particularly regarding appending), I wrote an article that tries to  
describe how D slices work, and why they behave the way they do.

Being one of the only places where I have web space, it's on my  
dcollections site, I probably will move it to the D wiki eventually, but  
I'm much more familiar with the Trac wiki syntax.

Please, if you have any comments or recommendations, let me know.  I  
certainly am no author, so I probably screwed a few things up :)

http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

Thanks

-Steve
May 18 2011
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 5/18/11 11:03 AM, Steven Schveighoffer wrote:

 Please, if you have any comments or recommendations, let me know.


First off, this is a fantastic article.  Thanks for clearly explaining a 
fairly subtle concept.  I'm especially happy to finally understand how 
appending to a slice can avoid reallocating and what assumeSafeAppend does.

I do have a couple of nits:

1. After the shrinkTo2 example, you say "This might look like you 
changed the passed arr's length to 2, but it actually did not affect 
anything," followed by the reason.  It took me a bit to realize why this 
was so.  I think it would be clearer if the example included the call to 
shrinkTo2, e.g.

void shrinkTo2(int[] arr)
{
     if(arr.length > 2)
         arr.length = 2;
}

int[] a = new int[5];
shrinkTo2(a);

And then you pointed out that a's length hasn't changed after the call. 
  Including the calling code might also be helpful for the Determinism 
example, for the same reason.

2. In the section "A Slice You Can Append On" the phrase "The slice does 
not own it's data" should remove the apostrophe from "its".  There is at 
least one other place in the document that also make this mistake, under 
the Caching section.

Again, fantastic article.

-Dave
May 18 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 14:44:33 -0400, David Gileadi <gileadis nspmgmail.com>  
wrote:


 On 5/18/11 11:03 AM, Steven Schveighoffer wrote:

 Please, if you have any comments or recommendations, let me know.


 First off, this is a fantastic article.  Thanks for clearly explaining a  
 fairly subtle concept.  I'm especially happy to finally understand how  
 appending to a slice can avoid reallocating and what assumeSafeAppend  
 does.


Thanks!


 I do have a couple of nits:

 1. After the shrinkTo2 example, you say "This might look like you  
 changed the passed arr's length to 2, but it actually did not affect  
 anything," followed by the reason.  It took me a bit to realize why this  
 was so.  I think it would be clearer if the example included the call to  
 shrinkTo2, e.g.

 void shrinkTo2(int[] arr)
 {
      if(arr.length > 2)
          arr.length = 2;
 }

 int[] a = new int[5];
 shrinkTo2(a);

 And then you pointed out that a's length hasn't changed after the call.  
   Including the calling code might also be helpful for the Determinism  
 example, for the same reason.


OK, thanks, I'll do that.


 2. In the section "A Slice You Can Append On" the phrase "The slice does  
 not own it's data" should remove the apostrophe from "its".  There is at  
 least one other place in the document that also make this mistake, under  
 the Caching section.


Yes, its a problem I have ;)

-Steve
May 18 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/18/11, David Gileadi <gileadis nspmgmail.com> wrote:

 There is at least one other place in the document that also make this mistake.


The first sentence! :]
May 18 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 14:44:33 -0400, David Gileadi <gileadis nspmgmail.com>  
wrote:


 I do have a couple of nits:


Fixed

-Steve
May 18 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well consider me enlightened. From all the things I've read before
this article, I thought a slice is a special feature that is only
introduced when you take an [n..m] from an array, e.g. my
understanding was something like:

int[] a = new int[5];  // a is definitely a dynamic array
auto b = a[1..3];  // take a slice and make b an array of length 2,
pointing at a[1..3];

Where "making an array" would just mean creating a new struct with a
pointer and a length, not allocating memory for the elements.

Your article should have been in TDPL. Good work!

It might be a good idea to mention how you can take a slice of a
static array to make it passable to functions which expect slices. A
lot of functions (all of them?) in Phobos expect slices and not static
arrays, but it's not at all obvious.

E.g. if you try to do this it will fail to compile with an extremely
ugly message:
    int[4] arr1 = [ 1, 2, 3, 4 ];
    auto mapped = map!("a + a")(arr1);

testmap.d(10): Error: template std.algorithm.map!("a + a").map(Range)
if (isInputRange!(Unqual!(Range))) does not match any function
template declaration
testmap.d(10): Error: template std.algorithm.map!("a + a").map(Range)
if (isInputRange!(Unqual!(Range))) cannot deduce template function
from argument types !()(int[4u])

All that has to be done is to take a slice:
    int[4] arr1 = [ 1, 2, 3, 4 ];
    auto mapped = map!("a + a")(arr1[]);

Come to think of it, these types of errors could be caught by the
compiler to output a nicer error message, imo.
May 18 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 16:22:50 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 Well consider me enlightened. From all the things I've read before
 this article, I thought a slice is a special feature that is only
 introduced when you take an [n..m] from an array, e.g. my
 understanding was something like:

 int[] a = new int[5];  // a is definitely a dynamic array
 auto b = a[1..3];  // take a slice and make b an array of length 2,
 pointing at a[1..3];

 Where "making an array" would just mean creating a new struct with a
 pointer and a length, not allocating memory for the elements.


D1 actually had almost this notion -- any slice that started at the  
beginning of a block was considered the "owner" slice.  The only issue  
was, you could have several slices think they own the data, which leads to  
bad things if you append to more than one of them.  This is where the  
"stomping" issue came in.  We all just dealt with it.


 Your article should have been in TDPL. Good work!


Thanks!


 It might be a good idea to mention how you can take a slice of a
 static array to make it passable to functions which expect slices. A
 lot of functions (all of them?) in Phobos expect slices and not static
 arrays, but it's not at all obvious.


This is a good idea, I should probably add to the section that  
demonstrates slices to show how slicing can be used on things other than  
heap-allocated arrays (although I allude to that in one part).


 E.g. if you try to do this it will fail to compile with an extremely
 ugly message:
     int[4] arr1 = [ 1, 2, 3, 4 ];
     auto mapped = map!("a + a")(arr1);

 testmap.d(10): Error: template std.algorithm.map!("a + a").map(Range)
 if (isInputRange!(Unqual!(Range))) does not match any function
 template declaration
 testmap.d(10): Error: template std.algorithm.map!("a + a").map(Range)
 if (isInputRange!(Unqual!(Range))) cannot deduce template function
 from argument types !()(int[4u])

 All that has to be done is to take a slice:
     int[4] arr1 = [ 1, 2, 3, 4 ];
     auto mapped = map!("a + a")(arr1[]);


This is really more of a problem with map and IFTI than arrays.  The error  
message is actually accurate (a fixed-sized array is not a range).

What would be nice is to say, "if map is called with a static array, slice  
it first".  I think you would probably need some sort of wrapper call:

auto map(alias pred, T)(ref T t) if(isStaticArray!T)
{
    return map!(pred)(t[]);
}

But you'd have to do this for every template function that takes a range.

I don't know of a better way the compiler could do it, IFTI is very simple  
when it comes to interpreting what argument type it should use.

-Steve
May 18 2011
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Steven Schveighoffer Wrote:


 Having seen quite a few incorrect descriptions of how D slices work  
 (particularly regarding appending), I wrote an article that tries to  
 describe how D slices work, and why they behave the way they do.


Still reading, but the example should use assertions which pass:

void main()
{
   int[] arr = new int[5];
   shrinkTo2(arr);
   assert(arr.length != 2); // Not expected!
}

It is good form because reading it will describe the outcome even without
comment.
May 18 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 16:37:49 -0400, Jesse Phillips  
<jessekphillips+D gmail.com> wrote:


 Steven Schveighoffer Wrote:


 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.


 Still reading, but the example should use assertions which pass:

 void main()
 {
    int[] arr = new int[5];
    shrinkTo2(arr);
    assert(arr.length != 2); // Not expected!
 }

 It is good form because reading it will describe the outcome even  
 without comment.


I always wonder about that.  One of the issues with assert for people  
"feeling" out the language is, a passing assert doesn't seem to do  
anything.

For instance, in this example, if you take the code I wrote, and compile  
it, you'll get a loud assertion error (proving the assertion runs and  
fails).

If you take your code and run it, you get a command prompt.  It doesn't  
really help you see how it works.

I'm contemplating switching it to a writeln instead ;)

-Steve
May 18 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Asserts are kind of like going to court and interpreting the silence
of the jury as a not guilty verdict. :p
May 18 2011
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Steven Schveighoffer Wrote:


 I always wonder about that.  One of the issues with assert for people  
 "feeling" out the language is, a passing assert doesn't seem to do  
 anything.
 
 For instance, in this example, if you take the code I wrote, and compile  
 it, you'll get a loud assertion error (proving the assertion runs and  
 fails).
 
 If you take your code and run it, you get a command prompt.  It doesn't  
 really help you see how it works.
 
 I'm contemplating switching it to a writeln instead ;)
 
 -Steve


Go with writeln, I understand that concern. The counter point I have is that
this is how unittests work and much of the documentation has been written.
May 18 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 Steven Schveighoffer Wrote:

 I always wonder about that. One of the issues with assert for people
 "feeling" out the language is, a passing assert doesn't seem to do
 anything.
 
 For instance, in this example, if you take the code I wrote, and compile
 it, you'll get a loud assertion error (proving the assertion runs and
 fails).
 
 If you take your code and run it, you get a command prompt. It doesn't
 really help you see how it works.
 
 I'm contemplating switching it to a writeln instead ;)
 
 -Steve


 
 Go with writeln, I understand that concern. The counter point I have is
 that this is how unittests work and much of the documentation has been
 written.


The huge advantage of assert over writeln is that it shows you what the result 
is supposed to be. If you're reading the code or documentation, that's 
extremely valuable, whereas writeln is useless. However, if what you're 
concerned about is running the code and see the result, writeln is far more 
useful. Since you're writing an article, I would definitely go with assert, 
but it really depends on what you're trying to do. assert works far better as 
documentation because you can see the result as you read, but writeln when 
running code because when you do, you can see the result.

- Jonathan M Davis
May 18 2011
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Jonathan M Davis Wrote:


 The huge advantage of assert over writeln is that it shows you what the result 
 is supposed to be. If you're reading the code or documentation, that's 
 extremely valuable, whereas writeln is useless. However, if what you're 
 concerned about is running the code and see the result, writeln is far more 
 useful. Since you're writing an article, I would definitely go with assert, 
 but it really depends on what you're trying to do. assert works far better as 
 documentation because you can see the result as you read, but writeln when 
 running code because when you do, you can see the result.
 
 - Jonathan M Davis


I agree, but he is conflicted on whether the assert should pass or fail. By
your logic though it sound like you want it also passing. There isn't much
difference between these:

   assert(arr.length == 2); // error!

   wirteln(arr.length); // 5
May 18 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-18 21:09, Jesse Phillips wrote:

 Jonathan M Davis Wrote:

 The huge advantage of assert over writeln is that it shows you what the
 result is supposed to be. If you're reading the code or documentation,
 that's extremely valuable, whereas writeln is useless. However, if what
 you're concerned about is running the code and see the result, writeln
 is far more useful. Since you're writing an article, I would definitely
 go with assert, but it really depends on what you're trying to do.
 assert works far better as documentation because you can see the result
 as you read, but writeln when running code because when you do, you can
 see the result.
 
 - Jonathan M Davis


 
 I agree, but he is conflicted on whether the assert should pass or fail. By
 your logic though it sound like you want it also passing. There isn't much
 difference between these:
 
    assert(arr.length == 2); // error!
 
    wirteln(arr.length); // 5


Yes. Such assertions should always be passing. If he has a good reason for not 
just doing

assert(arr.length != 2);

then what the best choice is depends on what he's really doing. I haven't 
gotten the chance to read the article yet though, so I don't know exactly what 
he's trying to do. In the general case, however, I think that for 
documentation and articles, the best choice is to use assertions which pass - 
particularly those which use == - because then it's clear what's actually 
happening without having to run the code.

- Jonathan M Davis
May 18 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 19 May 2011 00:27:51 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On 2011-05-18 21:09, Jesse Phillips wrote:

 Jonathan M Davis Wrote:

 The huge advantage of assert over writeln is that it shows you what  


 the

 result is supposed to be. If you're reading the code or documentation,
 that's extremely valuable, whereas writeln is useless.






Both assert and writeln with a comment describing what is output are  
equally as useful for code that is not compiled and executed (i.e. you are  
just reading).  Both describe what you should expect, and you can't really  
prove it is wrong without compiling and executing.

writeln is just a little more friendly to those who want to see something  
happening when you do actually execute it.  Whenever I'm learning a  
language, I like to write little test programs to print out what's going  
on to make sure I understand it.


 However, if what
 you're concerned about is running the code and see the result, writeln
 is far more useful. Since you're writing an article, I would  


 definitely

 go with assert, but it really depends on what you're trying to do.
 assert works far better as documentation because you can see the  


 result

 as you read, but writeln when running code because when you do, you  


 can

 see the result.

 - Jonathan M Davis


 I agree, but he is conflicted on whether the assert should pass or  
 fail. By
 your logic though it sound like you want it also passing. There isn't  
 much
 difference between these:

    assert(arr.length == 2); // error!

    wirteln(arr.length); // 5


 Yes. Such assertions should always be passing.


Shouldn't asserts be what you *expect* the value to be?  For example, in  
this case, a novice programmer may have written this code expecting that  
the value should be 2.  At least, that's what I was going for when I wrote  
an assert that I knew would throw an error.

I agree that proper documentation for the D spec or library modules should  
specify all passing asserts.  Especially when eventually these examples  
are used as unit tests.

In any case, I'm going to change it to writeln.  Thanks for all the  
opinions on this, it definitely helps to see what other people are  
thinking.

-Steve
May 19 2011
prev sibling next sibling parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> сообщил/сообщила в новостях 
следующее: news:op.vvou3fbgeav7ka localhost.localdomain...

 Having seen quite a few incorrect descriptions of how D slices work 
 (particularly regarding appending), I wrote an article that tries to 
 describe how D slices work, and why they behave the way they do.

 Being one of the only places where I have web space, it's on my 
 dcollections site, I probably will move it to the D wiki eventually, but 
 I'm much more familiar with the Trac wiki syntax.

 Please, if you have any comments or recommendations, let me know.  I 
 certainly am no author, so I probably screwed a few things up :)

 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

 Thanks

 -Steve


Nice article, very pleasured to read. One thing that strained my mind - this 
exaple:


import std.stdio;

char[] fillAs(char[] buf, size_t num)
{
   if(buf.length < num)
      buf.length = num; // increase buffer length to be able to hold the 
 A's
   buf[0..num] = 'A';   // assign A to all the elements
   return buf[0..num];  // return the result
}

void main()
{
   char[] str = new char[10];   str[] = 'B';
   fillAs(str, 20);     // buffer must be reallocated
   writeln(str);        // "BBBBBBBBBB"


(1)

   fillAs(str, 12);     // buffer can be extended in place!
   writeln(str);        // "AAAAAAAAAA";
}


Please add in (1) assert(str.capacity == 15);
May 18 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 16:47:47 -0400, Alex_Dovhal <alex_dovhal yahoo.com>  
wrote:


 Nice article, very pleasured to read. One thing that strained my mind -  
 this
 exaple:


 import std.stdio;

 char[] fillAs(char[] buf, size_t num)
 {
   if(buf.length < num)
      buf.length = num; // increase buffer length to be able to hold the
 A's
   buf[0..num] = 'A';   // assign A to all the elements
   return buf[0..num];  // return the result
 }

 void main()
 {
   char[] str = new char[10];   str[] = 'B';
   fillAs(str, 20);     // buffer must be reallocated
   writeln(str);        // "BBBBBBBBBB"


 (1)

   fillAs(str, 12);     // buffer can be extended in place!
   writeln(str);        // "AAAAAAAAAA";
 }


 Please add in (1) assert(str.capacity == 15);


hm... I think I'll add a comment instead, since I haven't discussed the  
capacity property yet.  People might not get what that means.

Thanks for the suggestion!

-Steve
May 18 2011
prev sibling next sibling parent Johann MacDonagh <johann.macdonagh..no spam..gmail.com> writes:
On 5/18/2011 2:03 PM, Steven Schveighoffer wrote:

 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.

 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually, but
 I'm much more familiar with the Trac wiki syntax.

 Please, if you have any comments or recommendations, let me know. I
 certainly am no author, so I probably screwed a few things up :)

 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

 Thanks

 -Steve


Fantastic! Just a grammar nitpick.

Caching:
we employ a caching technique that is as far as I know, unique to D.
should be:
we employ a caching technique that is, as far as I know, unique to D.

This seriously should be in the next TDPL ;)
May 18 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 18 May 2011 14:03:05 -0400, Steven Schveighoffer wrote:


 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.
 
 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually, but
 I'm much more familiar with the Trac wiki syntax.
 
 Please, if you have any comments or recommendations, let me know.  I
 certainly am no author, so I probably screwed a few things up :)
 
 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle


This is an excellent article!  It answers many questions about the new 
appending system which I've been meaning to ask you for a long time.

One question, still:  It seems inconsistent that the value of capacity() 
normally includes the existing slice elements, yet suddenly returns 0 
when the array cannot be appended to.  Why doesn't it return slice.length?
 
-Lars
May 19 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 19 May 2011 07:42:57 -0400, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:


 On Wed, 18 May 2011 14:03:05 -0400, Steven Schveighoffer wrote:


 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.

 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually, but
 I'm much more familiar with the Trac wiki syntax.

 Please, if you have any comments or recommendations, let me know.  I
 certainly am no author, so I probably screwed a few things up :)

 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle


 This is an excellent article!  It answers many questions about the new
 appending system which I've been meaning to ask you for a long time.


Thanks!


 One question, still:  It seems inconsistent that the value of capacity()
 normally includes the existing slice elements, yet suddenly returns 0
 when the array cannot be appended to.  Why doesn't it return  
 slice.length?


Well, I think someone has brought that up before, and I thought it was a  
good idea, but I found a reason recently for leaving it the way it is.

If an array has completely filled a memory block, and you have a slice  
that ends at the end of that memory block, the capacity will be equal to  
the slice length.  This might be a condition you want to know, vs a slice  
that does not end at the end of the array (which currently returns  
capacity of 0).

The example I found was a recent request for a way to safely remove an  
element from a slice.  I recommended to use assumeSafeAppend after  
removing the element.  The question was then asked, what if the slice is  
part of a larger array?  Calling assumeSafeAppend effectively invalidates  
all elements after the slice.  So you want to know positively that a slice  
ends at the end of the array, and only call assumeSafeAppend if it's safe  
to do so.

Maybe there is a better way to do this, but it turns out to be a useful  
inconsistency.  Keep in mind that calling capacity is not a simple quick  
lookup, so you don't want to have to call it multiple times.

Slices of non-heap arrays also return a capacity of 0.

-Steve
May 19 2011
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Steven Schveighoffer wrote:

 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.
 
 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually,
 but I'm much more familiar with the Trac wiki syntax.
 
 Please, if you have any comments or recommendations, let me know.  I
 certainly am no author, so I probably screwed a few things up :)
 
 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle
 
 Thanks


Any chance to move the article under Articles on
d-programming-language.org? More people will find/read it.

Jens
May 20 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/20/11 12:55 PM, Jens Mueller wrote:

 Steven Schveighoffer wrote:

 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.

 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually,
 but I'm much more familiar with the Trac wiki syntax.

 Please, if you have any comments or recommendations, let me know.  I
 certainly am no author, so I probably screwed a few things up :)

 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

 Thanks


 Any chance to move the article under Articles on
 d-programming-language.org? More people will find/read it.

 Jens


I'd be glad to. Could someone please put together a pull request?

Andrei
May 20 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 20 May 2011 13:57:15 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 5/20/11 12:55 PM, Jens Mueller wrote:

 Steven Schveighoffer wrote:

 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.

 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually,
 but I'm much more familiar with the Trac wiki syntax.

 Please, if you have any comments or recommendations, let me know.  I
 certainly am no author, so I probably screwed a few things up :)

 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

 Thanks


 Any chance to move the article under Articles on
 d-programming-language.org? More people will find/read it.

 Jens


 I'd be glad to. Could someone please put together a pull request?


I can do this.

-Steve
May 22 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-18 11:03, Steven Schveighoffer wrote:

 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.
 
 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually, but
 I'm much more familiar with the Trac wiki syntax.
 
 Please, if you have any comments or recommendations, let me know.  I
 certainly am no author, so I probably screwed a few things up :)
 
 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle


Finally got around to reading it. Definitely a good article. I even learned a 
few things from it (primarily surrounding implementation details). I am a bit 
surprised that you never mentioned that a slice is essentially struct with the 
a C style array pointer and the length of the slice (particularly since that 
helps to explain why passing an array without ref means that altering the 
slice rather than its elements doesn't alter the array that was passed in), 
but it still works quite well without that. A couple of total nitpicks would 
be that the first sentence should say "...is its implementation..." rather 
than using "are", and the title "A Slice You Can Append On" should be "A Slice 
You Can Append To." But as those just nitpicky grammar issues. Overall, it's 
very good and definitely something that D programmers (especially newbies) 
should read. Dynamic arrays and slices throw them off too often.

- Jonathan M Davis
May 22 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 22 May 2011 22:46:13 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On 2011-05-18 11:03, Steven Schveighoffer wrote:

 Having seen quite a few incorrect descriptions of how D slices work
 (particularly regarding appending), I wrote an article that tries to
 describe how D slices work, and why they behave the way they do.

 Being one of the only places where I have web space, it's on my
 dcollections site, I probably will move it to the D wiki eventually, but
 I'm much more familiar with the Trac wiki syntax.

 Please, if you have any comments or recommendations, let me know.  I
 certainly am no author, so I probably screwed a few things up :)

 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle


 Finally got around to reading it. Definitely a good article. I even  
 learned a
 few things from it (primarily surrounding implementation details). I am  
 a bit
 surprised that you never mentioned that a slice is essentially struct  
 with the
 a C style array pointer and the length of the slice (particularly since  
 that
 helps to explain why passing an array without ref means that altering the
 slice rather than its elements doesn't alter the array that was passed  
 in),
 but it still works quite well without that.


A slice is kind of an opaque type.  You shouldn't rely on the exact  
implementation (at one point, Walter was considering changing it to a  
begin and end pointer), although I do describe its implementation, without  
saying it's a struct:

"A slice is a segment of an array (dynamic or otherwise) that tracks both  
the pointer and the length of the segment"


 A couple of total nitpicks would
 be that the first sentence should say "...is its implementation..."  
 rather
 than using "are",


Fixed, thanks!


 and the title "A Slice You Can Append On" should be "A Slice
 You Can Append To."


This was intentional :)  It's a pun (something "you can depend on").


 But as those just nitpicky grammar issues. Overall, it's
 very good and definitely something that D programmers (especially  
 newbies)
 should read. Dynamic arrays and slices throw them off too often.


Thanks!

-Steve
May 23 2011