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?

Thanks!

Regards,
Alex

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

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
>