iterators again

[Bruno Medeiros]

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> Bruno Medeiros wrote:
>>>> Hum, you're right, it should type to const instead of invariant, I 
>>>> totally missed that. However I missed because I'm trying to look 
>>>> into another issue, what I really want to know is if the full type 
>>>> of (*(&foo)) will be the same as (foo), and so far it seems not, 
>>>> according to what Walter's said. So
>>>>   typeof(foo) is:  final Foo
>>>> but
>>>>   typeof(*(&foo)) is:  const(Foo)
>>>> which seems a breach in orthogonality, and meaning that this won't 
>>>> be allowed:
>>>>   (*(&foo)).membervar = 42;
>>>
>>> final is not a type constructor, it is a storage class. And no, you 
>>> won't be able to change the contents of an instance of a final 
>>> struct, even if you do machinations to do so.
>>
>> I should have clarified, Foo there is supposed to be a class, not a 
>> struct.
> 
> You can still change the members of a final class instance.

I know I can change the members of a final class, if I use the class 
reference directly (like "foo.membervar = 42"). However it seems that 
with that design, if one uses (*(&foo)) one won't be able to change the 
members of (*(&foo)) , as in "(*(&foo)).membervar = 42", even tough foo 
is conceptually the same as (*(&foo)). I was just checking if you 
recognized that this happens.

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