On Fri, 24 Sep 2010 09:32:40 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Thu, 23 Sep 2010 18:26:28 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Thu, 23 Sep 2010 10:05:45 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Wed, 22 Sep 2010 21:48:19 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Wed, 22 Sep 2010 13:10:36 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Wed, 22 Sep 2010 12:00:16 -0400, Robert Jacques
<sandf...@jhu.edu> wrote:
What about value types?
Value types are implicitly convertable to immutable, so they can be
strongly-pure.
No their not. Remember, arrays and other structs are value types in
the type system. Logically, they may be reference types, but as far
as their type signature goes, they are value types.
Arrays are not value types. A value type is one that contains no
references, no matter how deep. It is irrelevant if you have to spell
out the references or not.
Arrays are implemented as a struct. And as per the language spec:
(http://www.digitalmars.com/d/2.0/struct.html) all structs are value
types *to the compiler*. This doesn't mean that logically, from the
programmer's point of view, they aren't providing reference semantics.
structs can have value copy semantics. But for a struct that contains a
reference, the references have reference semantics, which makes the
struct a reference type.
A struct is never a reference type. It may have reference semantics, but
this is a high-order feature that is uncheckable by the compiler. At best
the compiler can detect that a struct contains references, not how those
references are exposed/managed by the API.
Look, terms can be debated, but here is the bottom line: A struct with a
reference type inside it cannot be implicitly converted to immutable,
whereas a struct with only non-reference types in it can. The compiler
knows this, and makes its decision on what must be immutable or not
based on that knowledge. Call it whatever you want, but that's how it
works internally, and it's not hidden from the compiler.
Right. Immutable transitivity for the win.
When you say "what about value types" what do you mean? I thought you
meant types which have value copy semantics, which can only have
non-references in them.
Given that I explicitly referred to the spec and compiler and contrasted
that to logical/semantic value types, I thought I was pretty clear about
what I mean.
