• "Ben Hinkle" <ben.hinkle gmail.com> Jul 15 2005
• pragma <pragma_member pathlink.com> Jul 15 2005
• Dave <Dave_member pathlink.com> Jul 15 2005
• "Ben Hinkle" <ben.hinkle gmail.com> Jul 15 2005
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jul 15 2005
• Dave <Dave_member pathlink.com> Jul 15 2005
• Dave <Dave_member pathlink.com> Jul 15 2005
• "Walter" <newshound digitalmars.com> Jul 15 2005
• Mike Capp <mike.capp gmail.com> Jul 16 2005
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jul 17 2005
• Chris Sauls <ibisbasenji gmail.com> Jul 17 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

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? 

pragma <pragma_member pathlink.com> writes:

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

Dave <Dave_member pathlink.com> writes:

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

"Ben Hinkle" <ben.hinkle gmail.com> writes:

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

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

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

Dave <Dave_member pathlink.com> writes:

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.

Dave <Dave_member pathlink.com> writes:

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.

"Walter" <newshound digitalmars.com> writes:

"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


 was a bug but looking at the dmd code the only access checks are in


 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


 modules.
 Is this a bug?


Yes.

Mike Capp <mike.capp gmail.com> writes:

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.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

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

Chris Sauls <ibisbasenji gmail.com> writes:

Jarrett Billingsley wrote:
 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.


That's pretty much exactly it (although if the only definition of fork()
available expects 
a Foo, then its pretty easy to deduce... but the argument-on-topic stays
valid).  And why 
am I responding?  To take one more stab at my preferred solution-syntax, of
course.  :)

# fork(new Foo {1,2,3});

Ta-da.  Could work well with arrays too.

# func(new int[] [1,2,3]);

Although for arrays there's a simple template function one can use, but that
doesn't 
really solve anything.  And I still want to see AA literals, something like:

# int[char[]] map = new int[char[]] [
#   `foo`  : 1  ,
#   `bar`  : 2  ,
#   `bob`  : 5  ,
#   `eris` : 42
# ];

The only potential issue with using 'new' is that it is usually understood to
represent a 
heap allocation.  So maybe it needs a companion keyword or some other method to
do a stack 
allocation as one normally would for structs and such.

-- Chris Sauls