[OT] Finding longest documents

[Steven Schveighoffer]

"Sergey Gromov" 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.  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.

First, there is no compiler required semantics.  It is up to the designer. 
If the designer says 'this is return by reference', then the designer is 
telling you what it is.

Second, just because you have your expectations doesn't mean they should be 
right ;)  The only things that are guaranteed are done so by the compiler. 
Everything else is up to the designer.

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

All you should need to do is look at the docs.  If the docs suck, you have a 
gripe.  If the implementation isn't what you would have done, but there is 
nothing wrong with it, tough.  Go write your own.

-Steve