June 02, 2007 Re: iterators again | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David B. Held | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | 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.
|
Copyright © 1999-2021 by the D Language Foundation