Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 10:18 me escribiste:
2 types should be provided: array and slice.
array is a *real* type, storing and owning memory, it should be something
like this (conceptually):
class array(T)
{
size_t length;
size_t capacity;
T[capacity] elements;
}
At the point I introduce arrays I hadn't described classes.
You are talking about the book, right? You don't have to! You can explain
arrays without talking about classes at all!
I was just replying to your suggestion.
One major problem with writing a "The X Programming Language" book
is sequencing. It's very easy to explain a complicated feature if
the listener knows all others. It is very difficult to introduce
them serially.
I don't think an array would be the case, come on! =)
1) a pure reference type.
2) 1 allocation only (interior pointers are not a problem, the GC have to
support them anyways).
3) easily appendable (capacity field).
slice should be something like this:
struct slice(T)
{
size_t length;
T* ptr;
}
structs and pointers have also not been introduced yet.
I don't know what this have to do with the book. Should be D designed
based on how good are you to explain the concepts on the book? I think
this is getting ridiculous... seriously. I don't want to be rude, I know
you're putting a lot of work in the book and we all appreciate that, but
you didn't mention any technical point about what I wrote.
I'm missing something? Why this shouldn't work?
It may work, but I was unable to pull it off reasonably well.
What problems did you find?
I thought I explained that above and in several other posts. I have the
feeling this is going in circles, but let me add one more thing. People
would want to have a reasonable way of choosing between T[new] and T[].
The differences between them are subtle (I have two tables showing the
primitives of T[] and T[new], which are very similar). That static
decision concerns future appends to the array, which doesn't strike me
as something you know from the get-go through future iterations of a
design. Use of "auto" messes up things further: a nice function may
choose to return T[new] because it just created an array (an
implementation detail), but clients may find that unexpected.
Andrei
