# General

Nearly everybody has some concerns about using String as the favorite datastructure in this use case. I will try to sum up these concerns and have a look at WHY these concerns occur and WHEN they are valid or invalid.

# Quotes

NPSF3000 says:
> The thing here is that a string would not do the job. I'm not sure why
> you would use the wrong data structure for the job. It's not simpler,
> it's wrong.

ArtOfCode says:
> Countries fit this definition (he means the "List" definition) pretty well: related but distinct.

Brythan says:

> This is vulnerable (the Usage of a String)

furthermore

> I would go with a Set, as it better describes the data. You don't have a String of countries; you have a Set of countries [...].

200_success says:

> Option 1 is sloppy. By that logic, Guinea is a country in Oceania.

# What's this all about?
My view on this is: There is a lot of confusion about adressing the correct level of abstraction.
I have two glasses to put on. The "language mechanical/technical" and the "semantic".

If we talk about datastructures that support speed then we are on a technical level. If we talk about a disjunct set of countries we face the semantic level.

Technically using a String would do the job for some situations and maybe these are the only situations the use case describes.

Semantically you have a subject. Because the semantic is not modeled into an equivalent datastructure. Nearly every answer provided adresses this. The semantic of your String is not "a set of countries". It's "a concatenation of country names". As some answers pointed out the "vulnerability" of this approach. The reason for this vulnerability is exactly the datastructure that does not match the semantic.

After all this may be not a problem if you intentionally use a structure that deviates from the semantic to improve performance. But you have to know that any deviation from the real structure goes with drawbacks. You get redundancy, vulnerability, inextensibility, unmaintainability and all the stuff that code quality decreases. These drawbacks may be jusified to the goal you want to achieve. 

BUT: This does not release you from the responsibility to provide the "correct" datastructure representation of the semantic as other algorithms maybe want to work on it. You should always provide a sufficient correct model of the part of the reality the use case needs. After that you can think about mapping it to a datastructure that may have drawbacks but the algorithms will work under certain metrics.

So my core statement is:

Beside ANY performance subjects I do not want to adress: The String will technically do the job for ONE use case. But you have to expect drawbacks in OTHER use cases as the datastructure representation does not match reality as use cases came from reality. It is a distorted model of the reality and this is expected to be acceptable for a small area but error prone for other areas.

# Metaphor
Think about a chair and a desk. You may have the idea to omit the chair in your model because you can also sit on the desk AND you have al lot of space left to put other things there. So why use a chair anyway? ***Technically*** you could put everything on a table. ***Semantically*** a table is not meant for that because both and a chair may have properties that are not that obvious but the algorithms want to work on it. One person may sit on the table, two or three will certainly break it. One person may sit on the table for an hour but not for a whole day. You will have drawbacks if you use objects in a way that they are not made for. So the concatenated names of countries.

# Suggestion
Not that surprising: I would go for the "Set of Countries". But if you think the perfmormance can be better with another datastructure you should map the correct representation to the datastructure that provides more performance WITHOUT touching the model that represents reality best as you do not want other algorithms to take the burden of the drawbacks.