On Tue, 14 Dec 2010 13:53:39 -0600 Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:
> Coming from an STL background I was also very comfortable with the > notion of value. Walter pointed to me that in the STL what you worry > about most of the time is to _undo_ the propensity of objects getting > copied at the drop of a hat. For example, think of the common n00b error > of passing containers by value. > > So since we have the opportunity to decide now for eternity the right > thing, I think reference semantics works great with containers. The issue for me in your reasoning is that what you are here talking about, and what your choice is based on, is _not_ reference _semantics_, but something like "indirection efficiency". This is optimization that clearly belongs to implementation and has nothing to do with semantics. Now, I totally agree it is very important (esp avoiding useless copies). Reference semantics has something to do with semantics, namely that an element in the program represents a "thing", some kind of entity in the model that has a proper "identity" (selfsameness), left unchanged in time however its form changes, and that can be multiply referenced. Confusion arises (esp in languages of the C-line) because pointers used for implementation (of variable size elements like dyn arrays) & performance (avoid copy) are sometimes called "references"; and references themselves are most commonly implemented as pointers. The choice whether an program element should be made plain value/data or thing/entity/ref, only depends from the semantic point of view on what it represents in the model. In languages of the C line that expose many implementation issues to the programmer, other considerations may then enter the dance and contradict semantics in some cases. In other words, the value/ref criterion is orthogonal to the common notion of type. We may be forced to paradoxically "ref" elements that represent plain information, like color values, just to avoid useles copies, for instance, because the compiler won't ref it under the hood when possible. I am convinced this efficiency can be automagic in the compiler, and the programmer would not have to care about that. Actually, the only problematic case is the one of (input-only-) _value_ parameters. The aim is for the compiler to pass them by ref for efficiency, when (1) they are heavy & (2) they are left unchanged. In an ideal world, parameters would be read-only e basta! But since this seems to be impossible in a C-like language, the compiler would have to check whether a value parameter is changed (1 per-thousand of all cases?), and copy it only in this case. I do not know how complicated this is, anyway it is certainly doable. On the other hand, if arguments let your positon unchanged that containers must behave like refs, then I fully agree they should be implemented as classes. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
