Error: function std.stdio.setmode is not accessible from module a

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, November 03, 2016 03:25:31 Kirill Kryukov via Digitalmars-d-
learn wrote:
> Thanks for the explanation, Jonathan! OK, I'll try adding my own
> binding for the time being, and submit a feature request.
>
> I guess this does not count as regression since it was
> undocumented, as you say. Although I would have thought it was a
> documentation deficiency instead. Working, not obviously wrong
> code stopped working without an alternative method available.
> Perhaps it's OK if it can be added to druntime the future.

It's a C binding, and there aren't supposed to be any public C bindings in
Phobos outside of etc.c, and even that is pretty much a legacy thing, since
bindings for 3rd party projects would normally go in deimos now. So, it's
clear that it was accidental that setmode was public, and any time that you
use a symbol that doesn't have a ddoc comment on it, you risk that your code
will break later, even if that symbol really should have been private or
package. It's not in the documentation, so it's an implementation detail and
not part of the Phobos API. And there has been some recent work to make sure
that undocumented symbols are either properly documented or made private or
package, so anyone using undocumented symbols from Phobos definitely runs a
risk of their code breaking, as you experienced.

> Also I am confused by it being both deprecation and error. I
> thought that deprecation message was just a warning about
> something that will stop working in the future, and the code
> should still compile. However in this case dmd first informs me
> that something is deprecated (it's not clear what exactly is
> deprecated). And then immediately fails with an error, on the
> same function call. Is it another separate diagnostic issue, or
> is it working as intended?

That part is definitely weird. I don't know what's going on there exactly,
but it probably relates to how private symbols used to be considered for
stuff like function overloading just like public symbols, and the access
level was only considered after that (meaning that private symbols could
cause symbol conflicts), whereas that was fixed a release or two back. But I
don't think that the symbol is actually completely invisible now like that
deprecation warning implies, just not considered in overloading. But I don't
know. Regardless, it's a diagnostic issue separate from setmode
specifically. You can reproduce it easily enough with just creating a module
with a private symbol and trying to use it in a module that imports it.

So, that may very well merit a bug report. It's certainly not how
deprecation warnings normally work, and I don't know under what
circumstances you could get that warning without the error. The only time
that I'm sure there's a difference is when there's a symbol conflict with a
private symbol, and previously, you would have gotten an error, whereas now,
you wouldn't, so there's nothing to warn about, just an error that went
away.

- Jonathan M Davis