View mode: basic / threaded / horizontal-split · Log in · Help
June 02, 2007
Re: iterators again
Bruno Medeiros wrote:
> [...]
> 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;

Can you produce a realistic scenario where you need to take a pointer to 
a final and get back the exact type?  Most of the time, you shouldn't 
even need to take addresses in D.  Most uses of pointers is with dynamic 
allocation.

Dave
June 02, 2007
Re: iterators again
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.
June 02, 2007
Re: iterators again
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.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
June 02, 2007
Re: iterators again
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.
June 06, 2007
Re: iterators again
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
June 06, 2007
Re: iterators again
David B. Held wrote:
> Bruno Medeiros wrote:
>> [...]
>> 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;
> 
> Can you produce a realistic scenario where you need to take a pointer to 
> a final and get back the exact type?  Most of the time, you shouldn't 
> even need to take addresses in D.  Most uses of pointers is with dynamic 
> allocation.
> 
> Dave

Well, I wasn't saying that this is a terrible problem, for now I was 
just confirming if this indeed happens with the planned design.

Still, I do have a feeling that it might cause some problems, altough I 
can't think of any concrete scenario right now (which doesn't mean there 
is one). For example, advanced type-generic templates usually get more 
complicated because of special and nonorthogonal cases. I've heard 
people say they had some inconveniences (don't know how severe they were 
though) because typeof(T) == typeof(T.init) is true for all types, 
*except* static arrays.
Similarly, problems might arise because:
  typeof(*(&something)) == typeof(something)
is true for all vars, except those that are final.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
June 06, 2007
Re: iterators again
Bruno Medeiros wrote:
> 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.

Yes.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home