[OT] Finding longest documents

[Sergey Gromov]

Thu, 16 Oct 2008 08:42:23 +0900,
Bill Baxter wrote:
> 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".

No.  Built-in array is transparent.  Appender is not.  Because if 
Appender is transparent, too, and there is a change in GC which makes its 
current implementation slow, you won't be able to fix that.  Therefore 
Appender must be opaque and must specify its interface.  And copy 
semantics becomes a part of that interface.  It may transfer ownership on 
assignment for instance.  Or declare behavior undefined if there are 
multiple copies of it.  You see, I can't even say "multiple references" 
because they are not, and "multiple copies" sounds ambiguous.

The bottom line is, your knowledge of built-in arrays is useless here.  
You must study docs for every container you use.

> > 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.

They cannot behave the same way unless they're very similar to the built-
in arrays, which makes them pretty useless.  Even built-in AA behaves 
differently.  BTW I was quite surprised to find out that it was 
implemented exactly as a struct with a single pointer inside.  Well, 
there could have been reasons to implement a built-in type like this.  I 
cannot see such reasons for Appender.

> 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
>