[OT] Finding longest documents

[Bill Baxter]

On Thu, Oct 16, 2008 at 7:47 AM, Sergey Gromov <snake.scaly at gmail.com> wrote:
> Thu, 16 Oct 2008 06:44:30 +0900,
> Bill Baxter wrote:
>> On Thu, Oct 16, 2008 at 5:46 AM, Sergey Gromov <snake.scaly at gmail.com> wrote:
>> > Wed, 15 Oct 2008 14:04:44 -0500,
>> > Andrei Alexandrescu wrote:
>> >> Sergey Gromov wrote:
>> >> > Wed, 15 Oct 2008 09:49:08 -0500,
>> >> > Andrei Alexandrescu wrote:
>> >> >> Sergey Gromov wrote:
>> >> >>> Wed, 15 Oct 2008 09:17:57 -0500,
>> >> >>> Andrei Alexandrescu wrote:
>> >> >>>> I see how it breaks those conventions, but I've never heard of them. The
>> >> >>>> convention I heard of is that if you want dynamic polymorphism you use
>> >> >>>> classes, otherwise you don't.
>> >> >>> How about if you want pass-by-value you use structs, otherwise you don't?
>> >> >>> My argument against structs-collections is that I want to toss
>> >> >>> collections around and build other collections out of them without
>> >> >>> messing with pointers.
>> >> >> A struct can choose to implement value or reference semantics as it
>> >> >> pleases. The only thing it can't readily implement is dynamic polymorphism.
>> >> >
>> >> > I can imagine the documentation: "Ignore the fact it's a struct, it's
>> >> > actually a reference internally."
>> >>
>> >> No. "Don't submit to the dogma that struct == value semantics, because
>> >> that was never true".
>> >
>> > I don't understand.  Structs are value types, everything else are
>> > implementation details.
>>
>> I think the point is that value *type* doesn't necessarily imply value
>> *semantics*.
>> Like with D's built-in arrays.
>
> Arrays are very widely used and very well documented to the point they're
> quite obvious.  There are no hidden implementation details.

And I think the issues are pretty much the same with all struct-based
container.  So if you understand the issues with D's arrays, then all
you have to know is "same thing for other struct containers".

> Nevertheless, there are well-known problems which directly follow from
> the arrays' sort-of-reference semantics.

Yeh, these do make me wonder about whether it was a good idea to make
D's arrays behave the way they do.  But since they do, and since you
can't really avoid having to learn how they work and what their
pitfalls are, I don't think it's so bad to make other containers
behave the same way.  Less to learn that way.

But I'd definitely be willing to entertain new ground-up designs in
which arrays behaved more like pure references, or were not copyable,
or similar.

--bb