What's going on with std.experimental.lexer?

[Jonathan M Davis via Digitalmars-d]

On Thu, 05 Jun 2014 10:57:35 +0000
Dicebot via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Wednesday, 4 June 2014 at 21:12:25 UTC, Brian Schott wrote:
> > I've been looking at ways to optimize the D lexer's operation
> > using SIMD instructions. I'm not yet sure if I'll need to
> > change the lexer generator's API to do this. I'm going to wait
> > until I have my proof-of-concept code and some benchmark
> > results before asking for a voting thread or creating a pull
> > request.
>
> I still thing we should use it more like `std.staging` - once
> your updates are ready, go through review/voting and keep module
> in `std.experimental` for at least one DMD release before adding
> to Phobos core.
>
> This also means relaxing API requirements a lot for initial
> inclusion.

Yeah. std.experimental really should be for stuff that's gone through the
review process and is essentially ready for inclusion in Phobos but needs more
real world usage to make sure that it really is fully ready to be merged into
std and then have its API frozen. It really doesn't make any sense to put
anything that's in more flux than that in there, because the release cycle is
just way too long for it.

Now, Brian's lexer might effectively be at that point already, I don't know.
It's been reviewed before, but I generally haven't had much time to look it
over for those reviews and don't know what state it's currently in. So, if its
API is close enough to final at this point, then it could probably be put in
std.experimental, but if it's still in a lot of flux, then that probably isn't
appropriate.

We do need to figure out what the official process is on this though so that
it's clear when it's appropriate for something to go in std.experimental,
otherwise we'll have folks who keep trying to put stuff in there which really
isn't ready yet, and we'll keep end up arguing over what can and can't go in
there.

- Jonathan M Davis