D const design rationale

[Sean Kelly]

Bruno Medeiros wrote:
> Sean Kelly wrote:
>>
>>>> I can appreciate that 'invariant' may be of tremendous use to the 
>>>> compiler, but I balk at the notion of adding language features that 
>>>> seem largely intended as compiler "hints."
>>>
>>> It's a lot more than that. First, there's the self-documenting aspect 
>>> of it. Second, it opens the way for functional programming, which can 
>>> be of huge importance.
>>
>> Could you explain?  I've been trying to determine how I would write a 
>> library using these new features, and so far, 'invariant' simply seems 
>> more an obstacle to maintainability (because of the necessary code 
>> duplication), than it is an aid to programming.
>>
> 
> In which situation does having 'invariant' lead to code duplication? I 
> can see the common situation where you have class getter methods, or 
> other similiar methods, but even without 'invariant' and only with const 
> and non-const you have that problem.

Let's say I am writing a linear search routine for arrays.  The most 
obvious implementation would accept that array as 'const', but it may be 
more optimal to use 'invariant'.  Since not all searchable arrays will 
be invariant however, both implementations must exist.  That said, a 
template function could likely handle both situations with the same 
code, and hopefully it will be uncommon to want virtual class routines 
that take both types of parameters.  Though I guess the same could be 
done there with a single template implementation and aliases.

>>>> The compiler can inspect the code however, and a global const is as 
>>>> good as an invariant for optimization (as far as I know).  As for 
>>>> the rest, I think the majority of remaining cases aren't ones where 
>>>> 'invariant' would apply anyway: dynamic buffers whose contents are 
>>>> guaranteed not to change either in word or by design, etc.
>>>
>>> But they do apply - that's the whole array optimization thing. You're 
>>> not just going to have global arrays.
>>
>> Perhaps I misunderstood the "must be known at compile-time" clause.  
>> Can 'invariant' apply to dynamic arrays that will remain unchanged 
>> once initialized?  In my work I use almost no static data--it's all 
>> generated on the fly or loaded from some data source.  Will 
>> 'invariant' help to make my code more optimal?
> 
> Of course, that's the whole point of invariant. The 'invariant' keyword 
> is being used for two things, compile-time values, and invariant data. 
> You obviously can't do what you mention with compile-time values, but 
> you can with invariant data (which is created at runtime). (or have I 
> misunderstood you, and you already knew that?)

I didn't know that, and that was the source of my confusion.  I had 
thought that 'invariant' only applied to data which was initialized at 
compile-time.  That it can apply to run-time initialized data makes a 
world of difference.


Sean