Go and generic programming on reddit, also touches on D

[Steven Schveighoffer]

On Mon, 19 Sep 2011 10:08:32 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 9/19/11 6:25 AM, Steven Schveighoffer wrote:
>> On Sun, 18 Sep 2011 15:34:16 -0400, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>>
>>> On 09/18/2011 08:28 PM, Andrei Alexandrescu wrote:
>>>> That would allow us to e.g. switch from the
>>>> pointer+length representation to the arguably better pointer+pointer
>>>> representation with ease.
>>>
>>> In what way is that representation better?
>>
>> I agree, I don't see why the representation is inherently better. Some
>> operations become higher performance (i.e. popFront), and some become
>> worse (i.e. length). Most of the others are a wash.
>
> That's where frequency of use comes into play. I'm thinking popFront  
> would be used most often, and it touches two words.

I'm not so sure.  It's very difficult to prove this is the case (either  
way).

Already foreach does not use the range primitives for arrays, which is  
probably the most frequent user of popFront (for ranges other than arrays  
of course).

However, length is used frequently in slicing, or passing to underlying C  
or OS functions which require ptr + length.  Maybe the compiler can  
optimize out the calculations of length when they are just getting  
translated right back to pointers.  For example a = a[1..$] shouldn't have  
to calculate a.length, it should just be a.ptr += 5.  I also think it  
would be nice to have direct access to the end pointer.  Likewise,  
a.length -= 5 shouldn't have to calculate the original length, then  
subtract 5, then pass that to the setlength function.

I'm not sure if the runtime code would be better or worse if we used 2  
pointers instead of ptr/length.  for sure that is where the bulk of the  
changes would need to be made.

The other thing that I don't like is it's much easier to construct an  
invalid slice with 2 pointers than it is with a ptr/length.

I suspect my opinion doesn't matter much for what we all "think" is used  
more frequently, but there are bigger issues to solve before we could have  
a library-based array type.  It might be best to leave the array as a  
magic type, but just change the internal representation in the  
compiler/runtime.

I know that printf was abused at some point for writing slices by relying  
on the fact that the order of length/ptr happened to be the same when you  
specified the length of a string as a parameter to printf, this would  
definitely break any code that relies on that.  Not that we need to care,  
but it's something to think about.

And actually, false pointers would be cut down (both pointers always point  
to the referenced block), which might be worth all the trouble anyways :)

-Steve