On Fri, 12 Apr 2013 12:18:30 -0400, Manu <turkeyman@gmail.com> wrote:

> On 13 April 2013 02:07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> On Fri, 12 Apr 2013 10:27:11 -0400, Manu <turkeyman@gmail.com> wrote:
>>
>>  I maintain the position that it needs at least a year in the real world
>>> before you can truly be confident in it. New things shouldn't be barred
>>> from post-release tuning on account of "omg it's a breaking change!".
>>>
>>
>> I hate the 'omg it's a breaking change!' mentality as well.  This is an
>> UNRELEASED product.
>>
>> I also hate the idea of creating another javax.
>>
>
> I don't understand this problem? Why is there a problem moving it when it's
> ready?
> It's already understood to be experimental, and the user has already
> accepted the contract that changes can be made (including moving it to std).

Intentions don't always equal reality.  If enough people make a stink, it could result in exp being the "official" release of some modules.  See standard location of Java's xml library.

I like the pragma idea because it does not stop compilation, serves as an adequate warning that things are in flux, and turning off the pragma breaks no code whatsoever.  It's basically a warning that your code may break.  But if the API is stable, it will be fine, and no changes are needed.

With the exp version, you either keep exp.module around forever as a public link to the std.module, or you force people's code to break even though no API has changed.

-Steve

On Friday, 12 April 2013 at 16:31:50 UTC, Steven Schveighoffer wrote:
> With the exp version, you either keep exp.module around forever as a public link to the std.module, or you force people's code to break even though no API has changed.
>
> -Steve

I like the pragma idea better, but I don't see why an exp.module link couldn't just be deprecated then removed. Even if you have to keep it around for ages, it's hardly going to get in the way much.

On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> pragma(msg, module.stringof ~ " is experimental, subject to API changes");

I like this better:

version(UseExperimentalProcess) { }
else pragma(msg, module.stringof ~ " is experimental, subject to API changes");

That way I can turn off the warning by passing -version=UseExperimentalProcess on the command-line. That of course means I take full responsibility for using experimental code.

On Fri, 12 Apr 2013 12:40:46 -0400, John Colvin <john.loughran.colvin@gmail.com> wrote:


> I like the pragma idea better, but I don't see why an exp.module link couldn't just be deprecated then removed. Even if you have to keep it around for ages, it's hardly going to get in the way much.

There's nothing wrong with it, it's just cruft.  And in order to remove it, you necessarily must break code.

I just like the no-cruft method better, seems pretty much equivalent to me without the code breaking.

-Steve

On Fri, 12 Apr 2013 12:49:09 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> pragma(msg, module.stringof ~ " is experimental, subject to API changes");
>
> I like this better:
>
> version(UseExperimentalProcess) { }
> else pragma(msg, module.stringof ~ " is experimental, subject to API changes");
>
> That way I can turn off the warning by passing
> -version=UseExperimentalProcess on the command-line. That of course
> means I take full responsibility for using experimental code.

The issue I have is e.g. if std.process (a locked-API normal module in this instance) uses std.log (an experimental module subject to API breaking changes).  I am not using std.log directly, so my code is not subject to breakage if std.log changes.  I assume that since std.process and std.log live together, a change to std.log's API will be covered with an appropriate change to std.process.  But I still see the warning without version=UseExperimentalLog.  People will simply use that flag and it will become trivial.

-Steve

On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> The issue I have is e.g. if std.process (a locked-API normal module in
> this instance) uses std.log..

It's just that warnings start to become really annoying after a while. I'd rather be warned every time I create a new project and use std.process (I will likely forget to pass -version=Use..), than be warned every single time I compile without the possibility to silence the compiler.

On Fri, 12 Apr 2013 13:17:07 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> The issue I have is e.g. if std.process (a locked-API normal module in
>> this instance) uses std.log..
>
> It's just that warnings start to become really annoying after a while.
> I'd rather be warned every time I create a new project and use
> std.process (I will likely forget to pass -version=Use..), than be
> warned every single time I compile without the possibility to silence
> the compiler.

Hence my lamenting for a way to stop it :)

At this point though, we don't have anything equivalent to #defines.

Hm... how about this idea:

1. Add std.exp.module with the API as it will be WITHOUT warnings
2. Add std.module with your suggested version statement, that publicly import std.exp.module
3. Internal phobos modules that use std.module privately will import std.exp.module directly to avoid the printout
4. upon official release, std.exp.module is moved to std.module, and the warning is removed.  Modules in phobos that privately used std.exp.module are updated to import the official version.

The only issue I see with this is, if we ever get dynamic libraries, a recompile will work, but an update of the dynamic lib will not.

I think a little compiler help here would be immensely useful.

-Steve

On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Hence my lamenting for a way to stop it :)

So that's what that was because I couldn't understand it (need a
coffee refill honestly). :p

> 2. Add std.module with your suggested version statement, that publicly import std.exp.module

Yeah it might work, I just hope it doesn't run into one of those nasty cyclic/public import bugs. E.g. http://d.puremagic.com/issues/show_bug.cgi?id=9919

But it probably won't be a problem. 9919 is about cyclic imports, as long as phobos doesn't import the module with a public import all should be fine methinks.

On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
> 1. Add std.exp.module with the API as it will be WITHOUT warnings

exp.module?

On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam@here.lot> wrote:

> On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
>> 1. Add std.exp.module with the API as it will be WITHOUT warnings
>
> exp.module?

Right.

-Steve