Unofficial wish list status.(Jul 2008)

[Sean Kelly]

Fawzi Mohamed wrote:
> On 2008-07-23 02:40:55 +0200, Sean Kelly <sean at invisibleduck.org> said:
> 
>> Walter Bright wrote:
>>> Sean Kelly wrote:
>>>> I personally feel that requiring that parameters be const is 
>>>> sufficient for memoizing results.  Requiring invariance assumes a 
>>>> programming model that I simply don't endorse.  But I'll grant that 
>>>> it's certainly the safer approach.
>>>
>>> What such a an approach would rely on would be the *convention* that 
>>> nobody would change the referenced const data from one invocation of 
>>> the function to the next. This contradicts the whole premise, and is 
>>> no better than C++.
>>
>> Oops, you're right.  I was thinking simply of the data changing while 
>> the function was executing.  I suppose requiring invariance of 
>> parameters does make sense.
> 
> I think that the const/invariant separation makes much sense, and the 
> whole framework is sound:
> 
> const: this constant *now* and should not be changed by you (but might 
> be changed by others)
> 
> invariant: this won't be changed by anybody (always constant), you can 
> cache it, do whatever you want to it, expect it to remain the same also 
> in the future

I think the theory is completely sound, I'm just not convinced it's 
worth the cost in terms of its impact on D programs.

>  From another post of Walter:
>> 4. Invariant data can be placed in hardware protected readonly memory, 
>> such as ROM.
> 
> I thin the invariant should not necessarily allow that.

I think the salient point is that invariant data /can/ be placed in ROM, 
not that it has to.  In fact, only some invariant data can be placed in 
ROM--that data which is known at compile-time.  const data in D 1.0 
works this way.


Sean