I've long had it in my mind to do a sort of "D for C++/Java/C#" 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

On Monday, October 29, 2018 4:37:33 AM MDT Mike Parker via Digitalmars-d wrote:
> I've long had it in my mind to do a sort of "D for C++/Java/C#" 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

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

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 .

On 10/29/18 6:37 AM, Mike Parker wrote:
> I've long had it in my mind to do a sort of "D for C++/Java/C#" 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

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

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?