Code doodles #4 – obfuscating code, it’s logical!

Found this during an IRC discussion with pingwindyktator. Go visit his blog if he ever writes there and if you can read Polish.

Let’s start with some standardese:

Picture 1. N4606

As you can see, the alternative tokens are defined to behave exactly the same as their counterparts. So the following code is perfectly well-defined and legit, despite the opinion of your fellow reviewer:

auto and answer = 42;
// same as auto&& answer = 42, but using natural language is less confusing

To be more explicit, we can say it’s a reference:

int const and reference = 42;
// both const and reference to int

And if you want to make everyone aware that the value shall not be changed, say so:

int const and final = 42

But managing readability isn’t the only goal to be achieved. You can use it to build suspense:

template<typename... Typenames>
void foo(Typenames and... exciting_objects) // yay!
{
}

Sometimes, though, that is not enough and you have to express it:

template<typename... Typenames>
void foo(Typenames and... boring_objects...) // meh :(
{
}

If you want to explicitly link a class member function to its body:

struct foo
{
	void bar() and {
		// bar() definition here;
		// actually reference-qualified
	}
};

And when you want to write a member function that takes const this and is noexcept, nothing is simpler than

struct foo
{
	void bar() const and noexcept;
	// actually reference-qualified
};

You don’t have to just use and. Use bitand to denote lvalue references, but it’s not as pretty:

auto const bitand value = compl 0;
// -1 on most systems

I’m sure people could come up with better examples, but for me, this is already enough.