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

[Kirill Kryukov via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 11:17:49 UTC, Jonathan M Davis 
wrote:
> setmode was never publicly documented, and technically, you 
> weren't supposed to be using it from there (since it wasn't 
> documented). It was fixed in 2.072.0 so that all of the 
> undocumented stuff in std.stdio was made private. It was never 
> intended that setmode be part of the public API in std.stdio. 
> But of course, since you were using it in spite of it being 
> undocumented, your code broke.
>
> Now, setmode is a C function from Windows, so it should be in 
> druntime where you could easily import it, but unfortunately, 
> it looks like it's currently missing from there. Rather, the 
> bindings for it were just put directly in std.stdio instead of 
> in druntime where they belongs. So, if anything, the bug is 
> that druntime doesn't have it. So, it would make sense to open 
> a bug for that. But if you want to still use it without it 
> being in druntime, you can just declare the bindings yourself, 
> as annoying as that may be. e.g. this is essentially what's in 
> std.stdio:
>
> version(DIGITAL_MARS_STDIO)
>     extern(C) int setmode(int, int) nothrow @nogc;
> else version(MICROSOFT_STDIO)
> {
>     extern(C) int _setmode(int, int) nothrow @nogc;
>     alias setmode = _setmode;
> }
>
> It really should be put in druntime though.
>
> - Jonathan M Davis

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.

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?

Thanks,
Kirill