[phobos] std.compiler

[Alex]

Hi Jonathan,

Thanks for the input!

This is how I've done things so far:

https://github.com/alexrp/druntime/commit/29318fd3e75d22395bbc66853c72c57646663d80
https://github.com/alexrp/phobos/commit/4d552d7088664e9aef1b15c1d7b81c5d05834fc6

I think it is reasonable to use pragma(msg, ...) this early in
std.compiler since it was practically useless up until 2.055, and even
then, as you point out, it's a fairly obscure 'feature' that many
aren't likely to ever need (in fact, I don't know of any code that
*does* use it...). The rare need is also exactly why I'm moving it to
druntime. I can change it to just be a soft deprecation message in the
documentation if desired, though.

I don't think we can do much as far as enum and breaking changes go.
It is essentially a change in signature, so it's bound to break
compatibility. But any code that relies on it being immutable (and not
enum) is probably doing something it shouldn't be doing anyway.

Note also that I've renamed some symbols for consistency. I've added
aliases in std.compiler to maintain compatibility with these.

Regards,
Alex

On Sun, Oct 30, 2011 at 2:58 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> 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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>