# Selection

* Embrace the attribute system.
* I do believe in the power and flexibility of the attribute system. I do not believe that much in making Selection a special concept. Making it a special concept therefore comes at a high risk for me, while the benefits seem small.
* I think the advantages that making selection a special concept can also be achieved without making it a special concept (by using a naming convention and good defaults).
* In this context, KISS (keep it simple, stupid) means to me that to the question what attributes a node uses/generates, I can always answer "look at the node inputs".
* Adding non-overwritable special cases makes this explanation more complex. Examples where more explanation is needed currently:
* The `Attribute Randomize` node uses the `id` attribute.
* The `Point Instance` node uses the `position`, `rotation` and `scale` attribute.
* The `Point Rotate` attribute uses the `rotation` attribute.
* All these special cases just add limitations and force users to use more nodes.
* Just prefilling attribute name fields with these names would provide the same level of convenience without removing flexibility (+ also supporting expressions in the future).
* I do not think that anyone of us has a lot of practical experience when it comes to procedural modelling.
* I'd be very careful with introducing more core concepts based on our limited perspective.
* I think when designing more features, we should try to use and extend the power of the attribute system, instead of limiting it.
* We have to acknowledge that having more than one selection is common in procedural modelling.
* If you only had one selection, the main thing you could build are tubes of some sort.
* Skimming over a few modelling tutorials, it looks like starting a new selection from scratch is very common (not really a surprise). In procedural modelling, you don't have the luxury of just doing a loop select or something similar later on. Instead, one has to remember the loop from when it was created.
* Therefore, in the context of procedural modelling, having more than one selection should not require a different way of thinking compared to having a single selection.
* Another not too uncommon thing is to combine selections using boolean operators like `and`, `or`. This can be done with nodes but also with expressions. Doing this requires more than one selection at a time.

## Proposal

* Every selection attribute used by a node, and every selection attribute generated by a node has a name field.
* We might have to come to a conclusion with the [compact nodes](https://developer.blender.org/T87009) design to make this feasable.
* If no input selection name is given, assume that either everything or nothing is selected depending on the node.
* Some nodes might not make sense when everything is selected (e.g. a Poly Bridge node that connects two selections).
* If no output selection name is given, don't generate a selection.
* For convenience, `selection` becomes a naming convention for a selection attribute.
* `selection` is *not* a builtin attribute.
* It's not bound to any specific domain.
* It's not bound to any specific data type.
* It's just a convention.
* We make it easy to use the `selection` attribute in various nodes. There are multiple possibilities for that:
* Always show `selection` in attribute search (if it is actively used, it will be there anyway).
* Prefill the input and output selection names in some nodes with `selection`.
* Create a one click solution for inserting `selection` into a text box.