A) what has been described so far doesn't take into account revamped modules, only new modules. However revamping modules also needs to be taken into consideration (there was a discussion before on whether we should have std.process2, which was agreed to be bad).
Here's a suggestion that would work for both new and revamped modules: put experimental/revamped modules during staging period under (to take std.process example): ./phobos/std/process.d //current one ./phobos/experimental/std/process.d //new one, still called module std.process now instead of having to modify D source files to change 'import exp.process' into 'import std.process' as has been suggested by some, here we would only need to change compiler flags: rdmd $DFLAGS -I$phobos_root/experimental main.d => uses experimental/std/process.d if import std.process is mentioned rdmd $DFLAGS main.d => uses std/process.d if import std.process is mentioned B) To handle fine grained selection of the experimental new/revamped modules, we can refine the preceding scheme with per-module identifiers: rdmd $DFLAGS -I$phobos_root/experimental -J$phobos_root experimental/std/process.d: module std.process; version(experimental_std_process_version_latest) mixin(import("experimental/std/experimental_std_process_version_3.d")); //latest revision else version(...) //maybe some intermediate revision given by a number else mixin(import("std/process.d").removeFirstLineContainingImportDecl); //default one C) Furthermore, instead of version(AllowExperimental){} else pragma(msg, "RED FLAG"); that was suggested, we can leverage UDA for more flexibility: the logic would enable behavior such as controlling whether to print warnings depending on whether user code or library depends on experimental feature. On Fri, Apr 12, 2013 at 1:25 PM, Steven Schveighoffer <schvei...@yahoo.com> wrote: > On Fri, 12 Apr 2013 16:15:33 -0400, Andrej Mitrovic > <andrej.mitrov...@gmail.com> wrote: > >> On 4/12/13, Steven Schveighoffer <schvei...@yahoo.com> wrote: >>> >>> On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <s...@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. >> >> >> I'd rather we keep it under "std" to avoiding stealing a name that an >> external library might already use (it's not stealing per se but it >> might introduce conflicts). > > > I'd like to take this opportunity to say I don't care what the name is :) > That wasn't any part of my suggestion. Whatever was decided as the "place > to put experimental modules" is what I meant. > > -Steve