I feel like this would be better as a library with a struct, so that a contract could have more than one auto-incrementing number. Structs don't have private fields though, so that would blow out the nice encapsulation, but I don't think it's too big a deal.

@frangio can you explain in more detail what you mean?

Yes, sorry for the terseness. 🙇‍♂️

What I wanted to say is that implementing this functionality by inheritance doesn't feel right to me. The main reason why I feel this way is that it only allows for one auto-incrementing counter per contract. Conceptually, "auto-incrementing counter" is a new datatype, with an operation "next", so I would expect to be able to create several instances of it.

Solidity allows the creation of new datatypes using libraries and structs. In this case it would be something like:

struct Counter {
    uint256 _prev;
}

function next(Counter counter) internal returns (uint256);

Used as:

Counter private ids;
...
    uint256 newId = ids.next();

This enables having multiple counters and doesn't add to the inheritance graph of a contract. On the other hand, whereas the contract implementation in this PR is nicely encapsulated by having the nextId_ be private, structs don't have private members, and users of the struct can modify its members arbitrarily.

I think Solidity should have private struct members, but that isn't there yet. (Is there even an issue?) In the meantime, I think I still prefer the struct implementation to the inheritance one.

Thoughts?

@frangio I've update the contract using that spec, and I like it better! Can you give it a last review?

fixed!