On 03/12/2010 23:09, Fawzi Mohamed wrote:
On 3-dic-10, at 17:23, Bruno Medeiros wrote:
On 03/12/2010 13:22, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
<brunodomedeiros+s...@com.gmail> wrote:
The above are not trivial differences, so I do not agree that it
constitutes full logical const, only a limited form of it. More
concretely, it doesn't constitute logical const in in the sense where
you can use that as argument to say "logical const already exists,
it's just clunky to use", so let's add it to the language formally.
Like if mutable members where just syntax sugar, or a betterment of
safety rules.
I disagree, I think it does prove logical const already exists. How do
you define logical const?
I define logical const as the ability to specify that operations on a
given object reference will not modify the logical state of that
object (through that reference), and the ability for the compiler to
verify that statically.
No for me the compiler *cannot* verify logical const. Logical const can
be verified only in some occasions:
for example a place where to store the result of a suspended evaluation
(what functional languages call a thunk).
A dataflow variable for example in general cannot be verified by the
compiler, but should also be logically const.
If you have a different notion of what logical state is, then yeah,
could be that the compiler cannot verify it. But considering what I
meant with logical state, the compiler can verify it. Let me go back and
restate what I meant by logical const:
For any type, the programmer can define a subset of that type's data
that composes the "logical state". He will do that using annotations on
the type's members for example. Then logical const is being able to
annotate function parameters (or any variable) to indicate that the
function will not change the "logical state" (aka, the previously
defined data subset) of that argument, and have the compiler verify this.
--
Bruno Medeiros - Software Engineer
