www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Protected module members -- regression?

reply Mike Parker <aldacron gmail.com> writes:

programmers sort of series on the blog. Inspired by the recent 
conversation about private-to-the-module, I started one on that 
topic. Then I encountered this:

```
module a;

protected int wrong;
```

```
module b;
import std.stdio;
import a;

int main() { writeln(wrong); }
```

I've always understood that protected module members are illegal. 
The docs explicitly say so. Yet the declaration of `wrong` 
compiles. Instead, trying to use it results in the deprecation 
message about symbol visibility that was added a couple years 
back when access modifiers were incorporated into symbol lookup.

I assume this is a regression and filed it as such [1], but I'm 
curious if the compiler has ever actually complained about 
protected module members.

[1] https://issues.dlang.org/show_bug.cgi?id=19340
Oct 29 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, October 29, 2018 4:37:33 AM MDT Mike Parker via Digitalmars-d 
wrote:


 programmers sort of series on the blog. Inspired by the recent
 conversation about private-to-the-module, I started one on that
 topic. Then I encountered this:

 ```
 module a;

 protected int wrong;
 ```

 ```
 module b;
 import std.stdio;
 import a;

 int main() { writeln(wrong); }
 ```

 I've always understood that protected module members are illegal.
 The docs explicitly say so. Yet the declaration of `wrong`
 compiles. Instead, trying to use it results in the deprecation
 message about symbol visibility that was added a couple years
 back when access modifiers were incorporated into symbol lookup.

 I assume this is a regression and filed it as such [1], but I'm
 curious if the compiler has ever actually complained about
 protected module members.

 [1] https://issues.dlang.org/show_bug.cgi?id=19340


Really, if you want to know, the surest way is to test older versions of the
compiler. Someone may post that they remember it being an error in the past,
but I doubt that they could give you a compiler version if they did, and
honestly, it's the sort of thing that most of us would never have tried,
since it makes no sense to use protected outside of a class.

- Jonathan M Davis
Oct 29 2018
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 29 October 2018 at 10:47:11 UTC, Jonathan M Davis 
wrote:


 Really, if you want to know, the surest way is to test older 
 versions of the compiler. Someone may post that they remember 
 it being an error in the past, but I doubt that they could give 
 you a compiler version if they did, and honestly, it's the sort 
 of thing that most of us would never have tried, since it makes 
 no sense to use protected outside of a class.


Easy enough. The latest version to *not* issue even a warning was 
2.070.2. Mike's code compiles quite happily. Starting with 
2.071.0, the compiler starts issuing a warning about visibility. 
Going by the changelogs, I think this is the most probable cause:

https://dlang.org/changelog/2.071.0.html#dip22
https://wiki.dlang.org/DIP22
Oct 29 2018
parent Uknown <sireeshkodali1 gmail.com> writes:
On Monday, 29 October 2018 at 11:48:24 UTC, Stanislav Blinov 
wrote:

 On Monday, 29 October 2018 at 10:47:11 UTC, Jonathan M Davis 
 wrote:


 [...]


 https://dlang.org/changelog/2.071.0.html#dip22
 https://wiki.dlang.org/DIP22


I was going to post a link to the code on run.dlang.io with 
compiler output from all versions, but surprisingly har files are 
not supported when using the "all dmd compilers" option : 
https://run.dlang.io/is/XRqhpd .
Oct 29 2018
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/29/18 6:37 AM, Mike Parker wrote:


 programmers sort of series on the blog. Inspired by the recent 
 conversation about private-to-the-module, I started one on that topic. 
 Then I encountered this:
 
 ```
 module a;
 
 protected int wrong;
 ```
 
 ```
 module b;
 import std.stdio;
 import a;
 
 int main() { writeln(wrong); }
 ```
 
 I've always understood that protected module members are illegal. The 
 docs explicitly say so. Yet the declaration of `wrong` compiles. 
 Instead, trying to use it results in the deprecation message about 
 symbol visibility that was added a couple years back when access 
 modifiers were incorporated into symbol lookup.
 
 I assume this is a regression and filed it as such [1], but I'm curious 
 if the compiler has ever actually complained about protected module 
 members.
 
 [1] https://issues.dlang.org/show_bug.cgi?id=19340


D has a history of ignoring inapplicable attributes. I would expect this 
is probably the same thing.

for example:

pure int x;

The reason (I think) is that you sometimes put attribute: for a bunch of 
things, or attribute { ... } and it would be super-annoying if you got 
complaints about using illegal attributes for some of the items, when 
you really just wanted them to apply to others. I think internally, the 
attribute label, attribute scope, and plain attributes are implemented 
the same way, so it *may* be hard to split out the single attributes 
from others. But this is entirely conjecture, as I have no idea how it's 
actually implemented :)

-Steve
Oct 29 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 29 October 2018 at 15:45:16 UTC, Steven Schveighoffer 
wrote:


 D has a history of ignoring inapplicable attributes. I would 
 expect this is probably the same thing.


That would have been my inclination, except that the spec 
explicitly says this [1]:

"protected module members are illegal."

I went back to the D1 docs because I was sure I had seen that 
years ago, and there it is [2] in the same words.

When I get a bit of time, I'll test it out on some ancient 
compilers. I guess at this point it's safe to assume that it's 
never been treated as an error, meaning it isn't a regression but 
a long-standing mismatch between the spec and the implementation, 
and the actual regression is the deprecation message that 
shouldn't be applied here.

[1] https://dlang.org/spec/attribute.html#visibility_attributes
[2] 
https://digitalmars.com/d/1.0/attribute.html#ProtectionAttribute
Oct 29 2018
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 29 October 2018 at 16:20:03 UTC, Mike Parker wrote:


 ...meaning it isn't a regression but a long-standing mismatch 
 between the spec and the implementation, and the actual 
 regression is the deprecation message that shouldn't be applied 
 here.


Isn't two years sufficient for that deprecation message to become 
hard error which it was supposed to be anyway?
Oct 29 2018