D const design rationale

[Bruno Medeiros]

Sean Kelly wrote:
> 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.
> 

Well, but that code duplication (even if simplified by the use of 
templates), is optional, because the invariant version of that function 
is just an optimization that can be made for some kinds of arrays. With 
only const in the language, but no invariant, you don't even have that 
option, so you are not any worse by having invariant in the language (in 
terms of the aformentioned code duplication).

I think it has now been clearly established the usefulness of having 
both const and invariant type modifiers (which Walter has explained 
about a lot), and I hope everyone understands that now.
We should focus now on the implementation details of our current 
proposal, for which there are several issues:

* Having invariant/const being used differently as a storage-class and 
type-modifier. Is this a good thing? (IMO, no, it is a major unnecessary 
source of confusion)

* The fact that the top-level type is never declared const/invariant 
when using const/invariant as type modifiers. Is this a horrible breach 
in consistency, or is actually a key necessary aspect of the design? 
(IMO, it's either one or the other, but I'm still not sure which)

* How to deal with code duplication, especially in class getter methods. 
where the only thing that changes is the type modifier of the implicit 
'this' parameter and some other input or output.

* How will meta-programming, specialization, IFTI, etc. work with these 
type modifiers?

* ... and other issues that there may be.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D