# uint8\_t + enum For Statuses

This one is more of a little tip/trick that I like to use - it's not necessarily something you need to know in order to write smart contracts.

There are plenty of times where you'll need to store some type of status in a table, or struct. `True/false`, `open/closed`, etc. Since you can't modify table structures without going through a complicated process, I've learned over the years that it's best to always plan in advance, and allow for the possibility that you might need more than 2 options.

For this reason, I use `uint8_t` to store these values, instead of a boolean. Then I combine this with an `enum` in order to improve code clarity / readability.

Let's pretend for example that you have some actions on your contract, and you only want specific users to be able to execute these actions. So, you put a flag in your table called `is_authorized`, like this.

```cpp
struct [[eosio::table, eosio::contract(CONTRACT_NAME)]] users {
	eosio::name		wallet;
	bool  			is_authorized;				

	uint64_t primary_key() const { return wallet.value; }
};
using users_table = eosio::multi_index<"users"_n, users>;
```

The problem you will eventually run into, is that you might add some new action to your contract, which requires higher authorization than a regular user, but less authorization than the users you originally created this flag for. Well, now you have no way of adding a 3rd option.

This is the reason that I use `uint8_t` instead.

```cpp
struct [[eosio::table, eosio::contract(CONTRACT_NAME)]] users {
	eosio::name		wallet;
	uint8_t  		is_authorized;				
	// 0: not authorized
	// 1: has all privileges
	// 2: has some privileges but not all
	// 3: is_blacklisted
	// Can add more options as needed
	
	uint64_t primary_key() const { return wallet.value; }
};
using users_table = eosio::multi_index<"users"_n, users>;
```

With this approach, your contract remains flexible and is able to adapt to any new features you may add in the future. If you were simply using a `bool`, you would've had to create a new table in order to extend the current privilege structure.

There is a problem here, though. When other parts of your contract are comparing against `uint8_t` to determine a status, it becomes difficult to keep track of what each number is supposed to mean. This is where `enums` come into play.

```cpp
static const enum AUTH_TYPES { 
	NOT_AUTHORIZED, 
	ALL_PRIVILEGES, 
	SOME_PRIVILEGES, 
	BLACKLISTED };

struct [[eosio::table, eosio::contract(CONTRACT_NAME)]] users {
	eosio::name		wallet;
	uint8_t  		is_authorized;				

	uint64_t primary_key() const { return wallet.value; }
};
using users_table = eosio::multi_index<"users"_n, users>;

ACTION mycontract::dosomething(){
	users_table users_t = users_table( _self, _self.value );
	auto itr = users_t.require_find( some_user.value );
	
	// Checking their auth
	if( itr->is_authorized == uint8_t(BLACKLISTED) ){
		check(false, "you are blacklisted");
	}
	
	// Modifying their auth
	users_t.modify(itr, same_payer, [&](auto &_user){
		_user.is_authorized = uint8_t(SOME_PRIVILEGES);
	});
}
```

This allows you to use `uint8_t` for storage, but also allows you to keep the code clean and readable, which is always important (for yourself and for other developers).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://waxdao.gitbook.io/wax-smart-contract-development-guide/tips-and-tricks/uint8_t-+-enum-for-statuses.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.