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?

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

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

"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.

"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_.

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.

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.

"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.

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.

"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.