Proposal: Relax rules for 'pure'

Steven Schveighoffer schveiguy at yahoo.com
Fri Sep 24 10:09:05 PDT 2010


On Fri, 24 Sep 2010 12:16:23 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

> On Fri, 24 Sep 2010 10:47:16 -0400, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
>
>> On Fri, 24 Sep 2010 10:33:10 -0400, Robert Jacques <sandford at jhu.edu>  
>> wrote:
>>
>>> On Fri, 24 Sep 2010 09:32:40 -0400, Steven Schveighoffer  
>>> <schveiguy at yahoo.com> wrote:
>>>> 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.
>>
>> Containing references means it cannot be cast to immutable, the only  
>> important thing when determining the strength of purity here.
>>
>> This whole discussion is going nowhere, you haven't made any real  
>> points.  Can you think of a case where the compiler would be wrong in  
>> determining purity strength for "value types" as you define them?  An  
>> example would be most helpful.
>>
>> -Steve
>
> I feel like I've upset you and would like to make amends. First, this  
> discussion was never about the compiler being able to determine purity.  
> That's easy. The point raised was about whether the programmer could  
> enforce strong-purity for any strongly-pure fucntion. The answer is that  
> you can by making all arguments immutable, which is a fairly minor  
> restriction on the callee. Second, this thread (fiber?), has veered a  
> little off-topic due to a misunderstanding/debate about value-types vs  
> value-semantics and reference-types vs reference-semantics. Perhaps it's  
> because I work with large, 'hybrid' structs a lot, but the difference  
> between value-type and value-semantics is very large in my mind. Third,  
> this fiber started, in part, due to a question by regarding value-types  
> being answered with value-semantics. Forth, I raised the question  
> regarding value-types in part due to half-remembered old posts in which  
> value-semantics were discussed but under the label of value-types, thus  
> causing confusion in my brain. And because it was late at night, I  
> decided to ask a simple question instead of testing DMD's current  
> behavior myself. I did end up testing DMD the next day (and then banging  
> my head on a wall), but by then all this had started.

You haven't upset me, I just couldn't follow what you were saying :)

When you said "what about value types," I thought it was a suggestion that  
value types would make it hard to determine whether a function was  
strongly pure or weakly pure, and my interpretation of what "value type"  
means sent us off on this tangent.

I think we both agree that the proposed changes by Don will work with the  
compiler, and I understand your desire to ensure a function is  
strongly-pure, and why the proposal does not give an easy solution to that.

So no hard feelings, we can move on and forget this whole thread ever  
happened :)

-Steve


More information about the Digitalmars-d mailing list