iterators again

[Bruno Medeiros]

David B. Held wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> [...]
>>> It'll be an error, since there's no way to deduce the type of foo. 
>>> But let's rewrite it as:
>>>     final int foo;
>>>     auto fooptr = &foo;
>>> Since foo cannot change its value, then fooptr must be an 
>>> invariant(int)*.
>>
>> [...]
>> Second, let's change the first example, let's have a Foo instead of an 
>> int:
>>    final Foo foo;
>>    auto fooptr = &foo;
>> What would be the type of fooptr?  Would it also be invariant(Foo)* ?
>> What would be the type of *fooptr? Would it be invariant(Foo) ?
>> If so, would that mean that the following would not be allowed:
>>   (*fooptr).membervar = 42 ;
>> even though this is:
>>   foo.membervar = 42;
>> ?
> 
> I think that Walter's scenario must type to const(int)*, for 
> consistency, even though const(int)* and invariant(int)* are equivalent, 
> given that int is an elementary value type.  This leads to the proper 
> conclusion that typeof(fooptr) == const(Foo)*, typeof(*fooptr) == 
> const(Foo).
> 
> Dave

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;

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