[Issue 1654] Array concatenation should result in mutable or invariant depending on usage

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Jan 31 15:26:06 PST 2008


http://d.puremagic.com/issues/show_bug.cgi?id=1654





------- Comment #5 from andrei at metalanguage.com  2008-01-31 17:26 -------
It's great to push the point. It is true that classes are reference types and
as such are distinct from structs and builtins, which are value types. But
that's a decision that is taken up front by the type designer: do I want
dynamic polymorphism, inheritance, infinite lifetime (garbage collection),
reference semantics? Then I write:

class Foo { ... }

Conversely: do I want eager copy, value semantics, deterministic termination
(that's to come in D 2.0 in a couple of weeks)? Then I write:

struct Bar { ... }

This does introduce an inconsistency in the type system, but it tends to work
well in practice and is documented upfront in the definition of the type. In
contrast, agreeing to further part types depending on whether they contain
pointers or not is murkier.

That is not even the main problem. At the risk of spreading FUD, Real Soon Now,
not all types containing pointers will be non-values. In a couple of weeks
we'll be able to write (syntax details may change):

struct Value {
  int * p = null;
  this() { p = new int; }
  ~this() { delete p; }
  this(scope) { p = new int(*p); }
}

This would effectively implement a structure containing a pointer but with 100%
value semantics (the third function is automatically invoked whenever an object
is copied into a new scope, right after the bitwise copy).

Note that the assignment operator will do the right thing, which is: (1)
duplicate the source into a temporary by bitwise copying it and then invoking
this(scope), (2) destroy the assignment target, (3) bitwise copy the temporary
into the assignment target.


Andrei


-- 



More information about the Digitalmars-d-bugs mailing list