Proposal: Relax rules for 'pure'

[Steven Schveighoffer]

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.

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.

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.

A type that has both value copy semantics and reference semantics, I guess  
you could call it a hybrid type (an array is such a type), but primarily  
it is treated like a reference.  If that's what you're asking about, then  
those also would make a function weakly pure.

>
>> another example of something that is not a value type:
>>
>> alias int * iptr;
>>
>> foo(iptr p);
>>
>> iptr is not a value type just because you don't see any * in the  
>> signature.
>
> *sigh* I explicitly referred to the type system/compiler. And to the  
> type system iptr is a pointer, no matter what you call it.

This is also purely a reference type.  Semantically, it's exactly the same  
as a pointer, except you have to refer to the member.

struct iptr
{
    int *ptr;
}

You are splitting hairs here, and it's not really furthering the  
discussion.

>
>>>>
>>>> But the compiler will be able to tell.  I think adding a  
>>>> __traits(isStronglyPure, symbol) will be good for those rare  
>>>> occasions where you really want to ensure purity.
>>>>
>>>> static assert(__traits(isStronglyPure, foo));
>>>>
>>>> -Steve
>>>
>>> This would work, but it wouldn't be self-documenting, etc.
>>
>> Hm... OK, well I disagree, it looks like it's documented to me.  I  
>> don't see a difference between tagging something as strongly pure and  
>> putting in the static assert (except verbosity of course).  I will note  
>> that I think the above would be a rare situation.
>
> To clarify, self-documenting => be able to automatically shows up in  
> ddoc, etc.

OK, that's a fair point, I hadn't thought of that aspect.  The only  
counter I have for that is, does it matter in the docs whether the  
compiler will optimize via parallelizing or not?  Or is it more important  
just to have the compiler refuse to compile if it can't parallelize?

-Steve