[OT] Finding longest documents

[Sergey Gromov]

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.  And yes, I assume that struct copying yields a 
separate, independent object unless documented otherwise.  I don't 
usually need such documentation in my code because I either remember what 
I'm doing or the reference components of structs are obvious.  But with a 
library struct with undocumented, private implementation it becomes an 
issue.

> > So how do I return it?  Should I 
> > return it by value, hoping that the implied reference semantics will stay 
> > that way in future releases?  How does your Array!() behave?
> 
> That's not finished, but e.g. Appender can be copied around and always 
> refers to the same underlying array.

This means that without reading docs I won't be able to tell whether my 
code is going to work or not.  Because the only truly copyable struct-
based solution I can imagine is a struct with a single pointer field 
pointing at a heap-allocated implementation.  And I doubt that your 
Appender is implemented this way.

I'm afraid I'll have to actually look into library sources to make sure 
Appender does what I expect.