View mode: basic / threaded / horizontal-split · Log in · Help
July 15, 2005
structs and protection
Walter,
The thread "Slashdot on the future of C++" pointed out that structs (and 
modules and unions it turns out) ignore protection attributes. I assumed it 
was a bug but looking at the dmd code the only access checks are in class.c 
and none in struct.c or module.c. In other words if I declare a top-level 
symbol or a struct field as private it can still be accessed from different 
modules.
Is this a bug?
July 15, 2005
Re: structs and protection
In article <db88qn$24tj$1@digitaldaemon.com>, Ben Hinkle says...
>
>Walter,
>The thread "Slashdot on the future of C++" pointed out that structs (and 
>modules and unions it turns out) ignore protection attributes. I assumed it 
>was a bug but looking at the dmd code the only access checks are in class.c 
>and none in struct.c or module.c. In other words if I declare a top-level 
>symbol or a struct field as private it can still be accessed from different 
>modules.
>Is this a bug? 
>

Looks, feels, and smells like a bug to me!



- EricAnderton at yahoo
July 15, 2005
Re: structs and protection
In article <db8m0c$2eqf$1@digitaldaemon.com>, pragma says...
>
>In article <db88qn$24tj$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>Walter,
>>The thread "Slashdot on the future of C++" pointed out that structs (and 
>>modules and unions it turns out) ignore protection attributes. I assumed it 
>>was a bug but looking at the dmd code the only access checks are in class.c 
>>and none in struct.c or module.c. In other words if I declare a top-level 
>>symbol or a struct field as private it can still be accessed from different 
>>modules.
>>Is this a bug? 
>>
>
>Looks, feels, and smells like a bug to me!
>
>

I think the 'bug' may be that the protection attribute is not flagged as
"incorrect syntax" because the docs. or BNF don't mention anything about a
protection attribute for members of structs or unions.

- Dave

>
>- EricAnderton at yahoo
July 15, 2005
Re: structs and protection
"Dave" <Dave_member@pathlink.com> wrote in message 
news:db8nn6$2gdf$1@digitaldaemon.com...
> In article <db8m0c$2eqf$1@digitaldaemon.com>, pragma says...
>>
>>In article <db88qn$24tj$1@digitaldaemon.com>, Ben Hinkle says...
>>>
>>>Walter,
>>>The thread "Slashdot on the future of C++" pointed out that structs (and
>>>modules and unions it turns out) ignore protection attributes. I assumed 
>>>it
>>>was a bug but looking at the dmd code the only access checks are in 
>>>class.c
>>>and none in struct.c or module.c. In other words if I declare a top-level
>>>symbol or a struct field as private it can still be accessed from 
>>>different
>>>modules.
>>>Is this a bug?
>>>
>>
>>Looks, feels, and smells like a bug to me!
>>
>>
>
> I think the 'bug' may be that the protection attribute is not flagged as
> "incorrect syntax" because the docs. or BNF don't mention anything about a
> protection attribute for members of structs or unions.

Then phobos will need some cleanup since, for example, the struct in 
dateparse.d has some private members. Just as worrisome to me, though, is 
the fact that modules can't completely hide a symbol by marking it as 
private. The following code works fine
 import std.stdio;
 void main() {
   std.stdio.writex(stdout,null,null,0);
 }
but
 import std.stdio;
 void main() {
   writex(stdout,null,null,0);
 }
fails to compile with the error "std.stdio.writex is private".
If the current implementation of private stands and one can't enfore private 
for non-classes then many of my projects will need a re-architecture to 
avoid structs and top-level symbols. In particular MinTL will be nearly 
useless since it has almost purely structs with many private members.
July 15, 2005
Re: structs and protection
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message 
news:db9gd5$67k$1@digitaldaemon.com...
> private. The following code works fine
>  import std.stdio;
>  void main() {
>    std.stdio.writex(stdout,null,null,0);
>  }
> but
>  import std.stdio;
>  void main() {
>    writex(stdout,null,null,0);
>  }
> fails to compile with the error "std.stdio.writex is private".

That scares me.

> If the current implementation of private stands and one can't enfore 
> private for non-classes then many of my projects will need a 
> re-architecture to avoid structs and top-level symbols. In particular 
> MinTL will be nearly useless since it has almost purely structs with many 
> private members.

I think the whole mess of protection attributes need work.  Classes can't 
access private members of their own nested classes, although they should be 
friends (same module); struct protection attributes don't work; module 
protection attributes can be circumvented; and I don't think the "package" 
keyword does _anything_.
July 16, 2005
Re: structs and protection
In article <db9git$6f3$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message 
>news:db9gd5$67k$1@digitaldaemon.com...
>> private. The following code works fine
>>  import std.stdio;
>>  void main() {
>>    std.stdio.writex(stdout,null,null,0);
>>  }
>> but
>>  import std.stdio;
>>  void main() {
>>    writex(stdout,null,null,0);
>>  }
>> fails to compile with the error "std.stdio.writex is private".
>
>That scares me.
>
>> If the current implementation of private stands and one can't enfore 
>> private for non-classes then many of my projects will need a 
>> re-architecture to avoid structs and top-level symbols. In particular 
>> MinTL will be nearly useless since it has almost purely structs with many 
>> private members.
>
>I think the whole mess of protection attributes need work.  Classes can't 
>access private members of their own nested classes, although they should be 
>friends (same module); struct protection attributes don't work; module 
>protection attributes can be circumvented; and I don't think the "package" 
>keyword does _anything_. 
>

From what I've seen so far, 'package' does do what the docs. say it should -
it's does for a package what 'private' does for a file (it's 'private' for a
package).

I agree - the other three look like inconsistencies at best.
July 16, 2005
Re: structs and protection
In article <db9gd5$67k$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Dave" <Dave_member@pathlink.com> wrote in message 
>news:db8nn6$2gdf$1@digitaldaemon.com...
>> In article <db8m0c$2eqf$1@digitaldaemon.com>, pragma says...
>>>
>>>In article <db88qn$24tj$1@digitaldaemon.com>, Ben Hinkle says...
>>>>
>>>>Walter,
>>>>The thread "Slashdot on the future of C++" pointed out that structs (and
>>>>modules and unions it turns out) ignore protection attributes. I assumed 
>>>>it
>>>>was a bug but looking at the dmd code the only access checks are in 
>>>>class.c
>>>>and none in struct.c or module.c. In other words if I declare a top-level
>>>>symbol or a struct field as private it can still be accessed from 
>>>>different
>>>>modules.
>>>>Is this a bug?
>>>>
>>>
>>>Looks, feels, and smells like a bug to me!
>>>
>>>
>>
>> I think the 'bug' may be that the protection attribute is not flagged as
>> "incorrect syntax" because the docs. or BNF don't mention anything about a
>> protection attribute for members of structs or unions.
>
>Then phobos will need some cleanup since, for example, the struct in 
>dateparse.d has some private members. Just as worrisome to me, though, is 
>the fact that modules can't completely hide a symbol by marking it as 
>private. The following code works fine
>  import std.stdio;
>  void main() {
>    std.stdio.writex(stdout,null,null,0);
>  }
>but
>  import std.stdio;
>  void main() {
>    writex(stdout,null,null,0);
>  }
>fails to compile with the error "std.stdio.writex is private".
>If the current implementation of private stands and one can't enfore private 
>for non-classes then many of my projects will need a re-architecture to 
>avoid structs and top-level symbols. In particular MinTL will be nearly 
>useless since it has almost purely structs with many private members. 
>

I should have complained a while back I guess.. I just thought it was something
the compiler was ignoring and would hopefully be cleared up soon or perhaps
access protection was on the docket for structs (which makes the most sense,
IMO).

You've made a better case than I could have at the time though - at least two
important libraries were built with structs, and at least parts of them were
built with struct access protection in mind.
July 16, 2005
Re: structs and protection
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
news:db88qn$24tj$1@digitaldaemon.com...
> Walter,
> The thread "Slashdot on the future of C++" pointed out that structs (and
> modules and unions it turns out) ignore protection attributes. I assumed
it
> was a bug but looking at the dmd code the only access checks are in
class.c
> and none in struct.c or module.c. In other words if I declare a top-level
> symbol or a struct field as private it can still be accessed from
different
> modules.
> Is this a bug?

Yes.
July 16, 2005
Re: structs and protection
In article <dba5rj$tou$1@digitaldaemon.com>, Walter says...
>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> Is this a bug?
>
>Yes.

Good to hear.

Can we assume that a struct with private members won't allow static-initializer
syntax?

(Incidentally, why is the static-initialization syntax only allowed on static
variables? At local scope, why can I say "int i = 1;" but not "Foo foo = {1,
2};"? Not a biggie by any means, just curious.)

I'd still quite like struct constructors. Static opCall looks the same, but
unlike a real ctor it doesn't provide a convenient hook on which the compiler
can hang an invariant check, so you don't get contracts enforced at the point of
creation.
July 17, 2005
Re: structs and protection
"Mike Capp" <mike.capp@gmail.com> wrote in message 
news:dbb8a6$1pa1$1@digitaldaemon.com...
> (Incidentally, why is the static-initialization syntax only allowed on 
> static
> variables? At local scope, why can I say "int i = 1;" but not "Foo foo = 
> {1,
> 2};"? Not a biggie by any means, just curious.)

I had a thread about this maybe a week or two ago.  I think we kind of came 
to the conclusion that while

Foo f={1,2,3};

Is obvious, something like

fork({1,2,3});

Isn't.  We were thinking something like

fork(cast(Foo){1,2,3});

But that's kind of ugly and might present parsing problems.

Of course, both problems could be solved with struct ctors ;)

> I'd still quite like struct constructors. Static opCall looks the same, 
> but
> unlike a real ctor it doesn't provide a convenient hook on which the 
> compiler
> can hang an invariant check, so you don't get contracts enforced at the 
> point of
> creation.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home