[Issue 1961] Allow "scoped const" contracts

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1961





------- Comment #15 from schveiguy at yahoo.com  2008-12-02 09:07 -------
(In reply to comment #12)
> This code duplication bug requires to write every rom method in three flavors
> to provide good rom interface. For me, this entirely prevents use of const
> system in OOP, restricting it to POD alone. I consider this a large enough
> problem, worth of new flavor of const. And this feature is not that confusing,
> if anyone wants a really confusing feature, he can look at the D templates :)

Thanks for the support, please vote for the issue so it goes up the list!

 (In reply to comment #13)
> Another kind of solution to this problem, more complex to create, but maybe
> cleaner is to have templates to extract/change the constness of types.

This works today, in fact it is the same solution I bring up in the beginning
of the bug report (with slight variations).  But there are several drawbacks:

1. Different arguments create different identical template instantiations. 
Const does not affect actual assembly generated, it is simply a safeguard for
the compiler to enforce.  Start creating functions with 2 or 3 const args, and
you are exponentially increasing the number of possible template
instantiations.
2. As a user of the function, I must read the function to tell if any
specialization is done depending on the constness of the type.  For example, a
static if can easily detect the absence of const and modify the data.  In
addition, there is no indication that the function works with const types
anyways, just seeing a T does not tell me immediately that the function will
not modify the args, I must either try to use the function or read the
function.
3. Template functions cannot be virtual.
4. What do you do when the return value depends on the constness of multiple
arguments?  I guess you have a plausible solution, but you still have to mark
the function somehow.  Using templates, you would need a very convoluted
template structure to do this, and you may even need to ensure a certain type
of argument.

I think my proposal has none of these drawbacks, and all the same benefits as
your proposal.  The only valid drawback anyone has brought up is the additional
const specifier possibly making const even more confusing.  Although I still
contend that this method would be much easier to understand and explain than
any template or set of 3^n different versions of a function.  Perhaps the
choice of keyword needs to be examined.


--