On 06/20/2012 02:38 PM, deadalnix wrote:
Le 20/06/2012 13:58, Timon Gehr a écrit :
Clarification: 'const' means 'const'. No other qualifiers.
There is no 'const' in that example code. 'immutable' obviously
needs to
be transitive regardless of the particular interpretation of 'const'.
const means: maybe immutable.
Or maybe mutable. Therefore, interpretation '2.'
Thus const needs to be transitive too.
Wrong. This is the (A==>B) ==> (B==>A) fallacy, where
A: 'const' is transitive
B: 'const' references cannot modify 'immutable' data
I understand the difference. It can change the legality of some calls,
that is true (and probably it is better).
None is strictly better than the other. Interpretation 2. gains some
flexibility in respect to interpretation 1., but it loses some 'const
pure' guarantees.
It is a matter of how these two orthogonal concerns are weighted
against each other. (Ideally, there would be one distinct qualifier for
each of the interpretations. :o) )
But it doesn't change the need
for a frame pointer's qualifier (mandatory to ensure immutability
transitivity).
To benefit of the extra freedom granted by B, what could be the casts
safely allowed on the delegate ? I understand your point, but fail to
find any way to make it work in practice.
It works if implicit conversions from 'R delegate(A)' to
'R delegate(A) const' are allowed, as well as looking up an
'R delegate(A) in a const receiver object.
