Use "$" as the Scene Unique Node symbol

[Mickeon]

I had an idea on a whim, but I currently find difficult to articulate it in a proper... proposal, and I would like to see what the community at large thinks first.

This is following Scene Unique Nodes, whose functionality uses the "%" symbol across the board.

In GDScript, the $ operator is a neat shortcut to get_node(). Quite useful, integrated, neat.
Let's really really make this the "get this node" operator.
$ has a pretty... uniquely recognisable shape. I believe using it to mark a Node's uniqueness would be great. There isn't much to confuse, because $ in GDScript already has a great correlation with nodes, and most other languages don't make use of the symbol, either.

And to add to this, a $$ operator could be used to specifically fetch Unique Nodes. It's like a powered-up $.
Using the already existing symbol that is about fetching Nodes to fetch Nodes but differently is a neat way to familiarise with the new concept and it feels less arbitrary.

In a way, it would also implement Make the $ operator in GDScript cache node references (or add a $$ operator) #996 in a nicely, more unique way.

Imagine the following code:

This would, of course, disallow naming nodes containing "$". but even then, generally speaking, why would one do that? Because of the operator's existence in GDScript, referring to them in code as $"Some$Node$Name" is quite puzzling on its own.

[dalexeev]

Options:

1. #. By analogy with the #id in HTML/CSS and the icon in the scene tree will be clearer as well. % is more associated with discounts than with a unique identifier.

The main problem is the intersection with comments in GDScript: $"#Node" will work, but $#Node will probably cause problems. Also, unlike HTML ids, node names are unique only within the scene, not the entire scene tree or branch.

2. @ is already used for autogenerated names (which are also unique), and besides the @ symbol can't be used in node names. The difference is that autogenerated names use two @ characters, for example: @@42. We can use $"@Node" and $@Node. But this can also potentially confuse users, since autogenerated names are unique for entire scene tree, unlike scene unique nodes.

3. Some other character, such as ~. It just seems to me that $$ is not a very good option.

4. Leave %, but change the icon in the scene tree.

[Mickeon]

$$ is not a very good option.

Could you elaborate? I have a few clues as to why, but I would love to hear it from someone else.

[dalexeev]

I can't say that I'm strictly against it for one specific reason. Rather, it is due to a combination of individual reasons, less significant individually. And because of my experience and the associations that I have. I'll try to list:

1. Make the $ operator in GDScript cache node references (or add a $$ operator) #996. I am against this proposal, but it has a chance to be implemented. And I don't know in which case the $$ syntax would fit better.
2. $$ makes me associate with PHP (variable variables). It's not a very good argument, but I admit it.
3. Doubling usually means composition (see p. 2), amplification (** and *), or similarity (&& and &). There is an exception: == and = for such different operations as comparison and assignment. To me, this is an example of an unfortunate standard that causes errors (= and := are better, I think). $ is shorthand for get_node. In my opinion, scene unique nodes are not related to composition, amplification, or similarity for get_node (I can explain why in more detail). Scene unique nodes is a different functionality, which means that the symbol should also be different.
4. According to p. 3, it will be easier for beginners if they see a slightly different syntax, so at least they will not make wrong assumptions.
5. In a more complex context (for example, var path = "NodeA/$NodeB/$NodeC"), the $ sign looks like the start of a substitution (to be fair, % too).
6. Small risk of accidental typos.

[Mickeon]

In a more complex context (for example, var path = "NodeA/$NodeB/$NodeC"), the $ sign looks like the start of a substitution.

This is a fair point. It's such a shame, it feels so close to a connection I'd deem perfect. I feel like get_node() and an hypothetical get_unique_node() are so closely intertwined...