[phobos] std.compiler

[Jonathan M Davis]

On Sunday, October 30, 2011 02:12:40 Alex wrote:
> Hi,
> 
> OK, so I think we need to get rid of std.compiler ASAP. I'm planning
> to move all of its code to druntime (core.compiler), as I believe it
> makes more sense to have it there (considering std.cpuid was moved
> there, for example).
> 
> Thus, some questions:
> 
> 1) Any general objections to this?
> 2) What do we do about std.compiler? Do we just remove it without
> further notice, or do we keep it around and deprecate it?
> 3) Can we make all variables in core.compiler 'enum'? This would be a
> breaking change, but since the module only became useful recently, I
> don't think it matters.
> 
> If we choose to deprecate std.compiler, then I have the following questions:
> 
> 1) How should I indicate in std/compiler.d that the module is
> deprecated? (I've been told to use pragma(msg, ...).)
> 2) Is a public import of core.compiler good enough, or do we do
> aliasing like we did with std.cpuid -> core.cpuid?

If we're going to deprecate std.compiler, then we'd mark it as "scheduled for 
deprecation" in its documentation. Later (typically about 6 months later), we 
would mark it as deprecated (both in its documentation and with the deprecated 
keyword). If at that point deprecated had not yet been improved to the point 
that we could give it a message, then we would use a pragma to display a 
message.

I don't know much about std.compiler (or why you'd even use it for the most 
part - it seems like a pretty rare need), but if we have essentially the same 
thing in druntime, then std.compiler should be scheduled for deprecation and 
core.compiler (or whatever it is) should take over.

If core.compiler needs to be altered with breaking changes for whatever 
reason, then they should be done sooner rather than later, but given that the 
number of people using this sort of module is likely to be quite low, and if 
core.compiler is fairly new, then breaking changes aren't as big a deal. But 
if we can make them in a manner which allows for a clean migration, that would 
still be better.

- Jonathan M Davis