The Thermopylae excerpt of TDPL available online

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el 29 de octubre a las 12:23 me escribiste:
>> Leandro Lucarella wrote:
>>> Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
>>>> Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
>>> BTW, it looks like array literals will be dynamic arrays, from the code in
>>> your book. Can you or Walter explain why this is better to make array
>>> literals statically stored immutable memory like strings (which adds an
>>> inconsistency to the language)? Is this just to avoid [1,2,3].dup; when
>>> you want to get a dynamic array from an array literal or is there other
>>> reasons?
>> I don't have a better explanation than the excerpt:
>>
>> Beware, however: if you replace @int[3]@ above with @auto@, @a@'s type
>> will be deduced  as @int[]@, not @int[3]@.  Although  it seems logical
>> that the type of  \cc{[1, 2, 3]} should be @int[3]@ which  in a way is
>> more  ``precise'' than  @int[]@, it  turns out  that dynamically-sized
>> arrays are used  much more often than fixed-size  arrays, so insisting
>> on fixed-size  array literals would  have been a  usability impediment
>> and  a  source  of  unpleasant  surprises.  Effectively,  the  use  of
>> literals would  have prevented the gainful  use of @auto at .   As it is,
>> array literals are @T[]@ by  default, and @T[n]@ if you \emph{ask} for
>> that specific  type and  if @n@  matches the number  of values  in the
>> literal (as the code above shows).
> 
> I saw that, but I think introducing an inconsistency (and depart on how
> literals usually work) is worse than having to explicitly state the type
> or adding a .dup to the literal.
> 
> But I guess it's just me.

It's me as well. The decision didn't go without a fight (I had your 
viewpoint and Walter didn't). He convinced me with two arguments. One is 
that 90% of the time you actually want T[], not T[n]. The second is that 
string literals already have dynamic (not static) type, although the 
most informative type would be fixed-size.

> Another question about the book: you explain dynamic arrays are being
> represented by a start and end pointer, much like the STL, but that's not
> the real implementation. I know you say in the book that the
> implementation doesn't necessarily work like that, but I wonder if you
> decided to explain things like that because it's planned to change the
> dynamic arrays implementation or just because you found it more didactic.

We will change the implementation at some point, but right now I hope I 
made it clear enough it's about the notion of a bounded chunk of typed 
memory, than the representation of it.


Andrei