[Tag] for CollectionService tags

[Anaminus]

Add a [Tags] symbol to support construction of instances with tags. Similar to [Children], except the elements are just strings:

-- Single tag construction.
New "Folder" {
	[Tags] = "Foo",
}

-- Multiple tag construction.
New "Folder" {
	[Tags] = {"Foo", "Bar"},
}

-- Nested tag construction.
New "Folder" {
	[Tags] = {"Foo", "Bar", {"Baz"}},
}

Support for states?

local tag = State("Foo")

local folder = New "Folder" {
	[Tags] = tag,
}

tag:set("Bar") -- Adds "Bar", removes "Foo".

local tagA = State("Foo")
local tagB = State("Foo")

local folder = New "Folder" {
	[Tags] = {tagA, tagB},
}

tagA:set("Bar") -- Adds "Bar", "Foo" still retained by tagB.
tagB:set("Bar") -- Adds "Bar", removes "Foo".

local tags = State({"Foo", "Bar"})

local folder = New "Folder" {
	[Tags] = tags,
}

tags:set({"Bar", "Baz"}) -- Removes "Foo", adds "Baz".
tags:set("Foo") -- Removes "Bar" and "Baz", adds "Foo".

This could make use of #10 under the hood if that is implemented. Alternatively, it could detect keys instead of values, but seems somewhat less convenient.

Another consideration is whether [Tags] represents all tags on the instance, or only the tags known by bound states.

local tags = State({"Foo", "Bar"})

local folder = New "Folder" {
	[Tags] = tags,
}

CollectionService:AddTag(folder, "Baz")
tags:set({"Bar"}) -- Removes "Foo", should this remove "Baz"?

[Children] has a similar consideration, so [Tags] should match whatever that does.

[Anaminus]

Since tags are unordered like properties, a possible alternative API:

New "Folder" {
	[Tag "Foo"] = true,
	[Tag "Bar"] = true,
}

Though this eliminates the possibility of binding a set of tags. On the other hand, this would be a good solution if binding sets of tags were expressly unwanted.

[dphfox]

This is an interesting idea! I'm assuming this is talking about CollectionService tags?

[Dionysusnu]

I would go for the first option, having a tags symbol like children. On a similar note, this should probably be added for attributes too?

[dphfox]

On a similar note, this should probably be added for attributes too?

Tracking that here: #1

[dphfox]

The design of this API will probably be guided by #1

[Aloroid]

Tags shouldn't be designed like Attributes. How would it even work in actual code? All keys need a value, so do we just have to set it to true in all cases because yes? Do we make the value a boolean which controls if it has that tag or not? It also looks a lot harder to guess what the value that we set it to means.

New "Frame" {
    [Tag "MyTag"] = true
}

This looks incredibly awkward to read imo. In comparison to the original proposal,

New "Frame" {
    [Tags] = {"MyTag"}
}

This looks way better in my eyes as we aren't pretending to store some magical value.
It also makes using states more pleasing on the eyes.
[Tag(tagName)] = true vs [Tags] = {tagName}