June 02, 2007
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
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
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
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
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
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
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.
1 2 3 4
Next ›   Last »