Remove anaphoric macros.

[jdoliner]

Anaphoric macros are code that's understandable to only one person at the company, they require compiler pragmas to get them to compile and they're incredibly ugly. We should get rid of these ASAP.

[srh]

Some of them, OPT1 at least, also modify local variables like arg, while others don't, and I'm not sure if it's necessary for some reason or not.

[mlucy]

I concur. (Also, all of them should modify arg; which ones don't?)

[srh]

Only OPT1 and OPT2 if that exist modifies the local variable arg. The others do not.

[mlucy]

Ah; I misunderstood what you meant.

[srh]

Is OPT1 and OPT2's behavior necessary, or could they have made a new arg variable in local scope? I've always been curious about that.

[mlucy]

There's no reason; it's arguably a bug actually.

[AtnNn]

@mlucy have you started work on this issue? I'm going to give it a shot.

[mlucy]

@AtnNn -- I would really strongly prefer that we not do this until 1.9 or 2.0 when the RQL changes have slowed down. There's nothing worse than having an interface change under you when there are a bunch of RQL terms in code review.

After that, though, it would be wonderful. This is an important enough interface that I think we should talk about the new one; could you write up a RQL proposal with the new interface you're proposing?

[AtnNn]

I don't have anything specific in mind, I just find the current macros hard to work with.

[jdoliner]

I think the new interface is approximately what a C++ driver for rethinkdb would look like. Rewriting stuff would be pretty straightforward if you had that.

[AtnNn]

could you write up a RQL proposal with the new interface you're proposing?

What @jdoliner propose sounds about right: approximately what a C++ driver for rethinkdb would look like

Here is what it could look like: 63f3231455dd826b5744966adf5887fe7dcf8274

[mlucy]

I don't think GCC 4.3 supports C++11 anonymous functions, does it? (Otherwise, that interface looks awesome.)

[AtnNn]

I updated the atnnn/minidriver branch to not use lambdas.

I would really strongly prefer that we not do this until 1.9 or 2.0 when the RQL changes have slowed down.

I will stop working on that branch for now.

[AtnNn]

RQL changes have slowed down. I have rebased and updated the atnnn/minidriver branch and put it up in review 908

[coffeemug]

My opinion (@AtnNn, @mlucy -- feel free to ignore it) is that we should still hold off on making this change. We have a lot on our plates; refactoring code now might introduce bugs that puts even more on our plates and makes stability work harder. I'd rather focus 100% on fixing issues that users face, and do this post 2.0 when things calm down a bit.

[jdoliner]

I'm strongly in favor of doing this now. Code gets a lot easier to make stable when more than one person has any idea what it means. This will have the precise opposite effect from what you're describing @coffeemug.

[srh]

@coffeemug: It's already in code review and it's great.

[mlucy]

I'm way backed up on my reviews right now, but I plan to get to this soon.

There might be some merge conflicts with Review 907, but there should be minimal difficulty aside from that. Now is as good a time as any.

[coffeemug]

Ok, I remove my objections.

[AtnNn]

This is in review 1005, assigned to @mlucy.