Contrary to popular belief, it isn't always a bad idea to have public member variables -- there's no value in forcing your implementation details to go through get/set pairs or any such nonsense.
For instance, consider a linked list class. A linked list is made up of nodes. A typical linked list class will have a private node type. Something along the lines of:
// a list of Elems
template <typename Elem>
class List
{
struct Node
{
Node* next;
Node* previous;
Elem value;
// then some implementation for the node, to
// handle insertions and deletions.
};
// and then the rest of the List's implementation.
};
Requiring the use of accessors for the various parts of the node is of no value whatsoever. The only people who can access the Node class are the people writing the List class -- and if you can't trust them to use the class properly, you can't trust anyone, and might as well not bother. You don't expose your Nodes to any users of the class, so it doesn't matter to them how it's implemented -- after all, the point of using OO is to keep these details hidden from the user.
Implementation details such as these nodes can use public member variables without fear -- the reasons for keeping them private are no longer valid.
It is occasionally the case where it is sound to have "exposed" public members. An example is the std::pair class template. The pair is just a poor man's tuple. It implies no policy, it's purely a means of pairing two types for ease of manipulation. This use is certainly rare -- I can't think of any reason to do so other than tuples -- but should not be ignored. Languages with built-in tuple support (found in most or all functional languages, including the C-like Vault) make the components of the tuple public -- it's the right decision.