Top 5

[Sergey Gromov]

Thu, 09 Oct 2008 11:22:11 -0500,
Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
> > I'd generally like less syntactic freedom in D.  Excessive amounts of 
> > syntactic sugar cause troubles in many different places.  Economy of 
> > syntax principle has a flip side: a single mistake can make your program 
> > mean a whole different thing instead of simply giving you a syntax 
> > error.  Redundancy is required to detect an error and suggest a fix.
> 
> Ok. I guess what you're saying is that the Hamming distance between 
> semantically correct notation should be large.

Exactly, I forgot the term and didn't manage to google it up.  :D

> > 1.  Drop the "array is a slice" idea.  I liked it a lot when I saw the D 
> > specs but it bit me immediately while I implemented a text parser.  The 
> > idea sounds nice but it causes too many problems.
> > 
> > There are two major use cases for arrays: building and parsing.  When 
> > building, you want fast append, you've got a limited number of arrays, 
> > and you likely don't care if your arrays are a little fat.  When 
> > parsing, you want data consistency, that is you don't want a sub-array 
> > to change if you occasionally append to another sub-array.  You also 
> > want to pass those sub-arrays around a lot and you probably want them to 
> > be cheap.
> > 
> > An array should be a fat object optimized for fast appending.  It should 
> > be a class, because you want to pass it into functions and store 
> > references to it while keeping it a distinct object.  Call it Array!(T) 
> > or List or Vector or whatever.  It should be implicitly convertable to a 
> > slice type T[] which can stay what it is now.  It should be built-in 
> > because array new, .dup and slice ~ should return a new array instance.
> > 
> > It'll probably break lots of generic code.
> 
> I think there are very solid reasons for keeping slices the primitive 
> array type of choice. Rock-solid in fact. I will go over them in TDPL, 
> but in short pointers are too low-level a primitive for arrays, and more 
> than (the equivalent of) a pair of pointers would be too non-primitive.

I think there's a terminology issue again.

In this proposal when I talk about slices I mean the primitives which we 
currently have as arrays, T[].  Because they *are* slices.  And when I 
talk about arrays I mean fat memory management constructs similar to 
your Appender or bearophile's ArrayBuilder.

> For appending, I already put Appender in std.array. For parsing, I 
> didn't get your argument.

When you try to use current arrays for memory management, i.e. 
appending/growing, you get two major problems.  First is what your 
Appender solves, speed.  Second is that appending to a slice can 
overwrite contents of a larger slice, i.e. broken safety.

Your library solution can improve speed.  But it cannot improve safety, 
and the speed improvement is kinda optional: you must know about that 
particular library feature to get a speed gain.

I think that the base type should offer both speed and safety by 
default.  To achieve this I propose to disallow unsafe operations on 
current arrays, call them slices, and introduce a built-in memory 
management class, Array(T).  Here's why built-in:

void main()
{
  auto arr = new char[]; // arr is of type Array!(char)
  arr.length = 10;       // OK
  arr ~= 'c';            // fast
  arr ~= "foo bar";      // fast
  foo(arr);              // implicit cast to char[]
  bar(arr);              // passed by reference
                         // "text" is appended
}

void foo(char[] a)
{
  char x = a[0];                // OK
  char[] word = a[10..14];      // fine
  size_t l = a.length;          // 18
  a.length = 20;                // error, .length is read-only
  a ~= "text";                  // error, append not supported
  char[] n = a[15..18] ~ "some" // type of expression is Array!(char)
             ~ word             // fast
             ~ "baz"            // fast
             ;                  // implicit cast to char[]
}

void bar(Array!(char) a)
{
  a ~= "text"; // OK
}

> > 2.  Drop the "call a function however you want" idea.  Simple property 
> > method syntax is nice, but excessive freedom is not.  Adding one simple 
> > keyword fixes the situation.  See
> >> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=13471
> > for an explanation.
> > 
> > It'll probably break lots of regular code.
> 
> This would be an uphill battle with Walter. He'd like to implement the 
> property calls to work only for pairs of functions, something discussed 
> here before.

I'm not fighting here.  Just saying what I think is the right thing to 
do.