Proposal: Relax rules for 'pure'

[Robert Jacques]

On Fri, 24 Sep 2010 09:32:40 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Thu, 23 Sep 2010 18:26:28 -0400, Robert Jacques <sandford at jhu.edu>  
> wrote:
>
>> On Thu, 23 Sep 2010 10:05:45 -0400, Steven Schveighoffer  
>> <schveiguy at yahoo.com> wrote:
>>
>>> On Wed, 22 Sep 2010 21:48:19 -0400, Robert Jacques <sandford at jhu.edu>  
>>> wrote:
>>>
>>>> On Wed, 22 Sep 2010 13:10:36 -0400, Steven Schveighoffer  
>>>> <schveiguy at yahoo.com> wrote:
>>>>
>>>>> On Wed, 22 Sep 2010 12:00:16 -0400, Robert Jacques  
>>>>> <sandford at 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.