What's the value of using symbols instead of string literals to reference dictionary keys?

It replaces a 'magic string' with a 'magic variable name', which is worse than the normal solution for magic strings, which is to move them to a constant.

If I have code in one place that says:

   dict["key"] = "value";

and code elsewhere that says:

   var value = dict["key"];

I can make that code better today by adding

  const string KEY = "key"

and then using dict[KEY] in both places. I can change the key in one place, and if I misspell the constant name in either location then the compiler tells me I have a problem.

With the new syntax, I can now write

   dict.$key = "value";

and

   var value = dict.$key;

but if I go ahead and change one of these:

   dict.$newkey = "value";

I'm not going to get a compiler warning when I try to read $key (am I?). Unless there's some smart tooling support, where's the win here?

Key symbols aren't becoming a new type - I don't get to write

   var key = $key;
   var big_key = ["key with spaces"];

(so far as I'm aware - though I actually quite like the idea of a datatype that represents this kind of non-manipulable string identifier)

I guess the new .$ syntax combines with the null-propagating ?. operator, so you could have nested dictionaries and access them with:

dict?.$subdict?.$subsubdict

which looks... horrible. And suffers from the fact that there's no null-propagating equivalent index access operator, ?[], so I can only use this trick on keys that can be written as C# symbols.

I really feel like I'm completely missing what the use cases are for this capability...

I'm thinking it is the first step to a data type like Ruby's symbols. For the case of spaces I could see the underscore (_) getting used.

    var bigKey = $key_with_spaces;

But if they were adding symbol support, it would have to work for accessing actual members, not for just faking string indexed members as if they were members. Symbol support would let you do things like this:

  public double GreatestExtent {
    get {
      Symbol directionOfGreatestExtent = $X;
      if (this.Y > this.X) directionOfGreatestExtent = $Y;
      return this.#directionOfGreatestExtent;
    }
  }

(I'm making up some sort of syntax on the spur of the moment here)

Clearly this can be written easily enough without symbol support, but you could argue that the intent of the logic is clearer here than it is in some alternative approaches.

But the thing is that the kind of symbol they've given us isn't a syntax where $foo is a literal which means 'a symbol which accesses the member foo on the target', but instead a syntax where $foo means 'a symbol which accesses the indexer on the target which takes a single string as an argument and passes the string "foo" to it' - just like ["foo"] does.

If I have my co-ordinates stored in a dictionary, I don't need this symbol support to be able to write that kind of logic:

  public double GreatestExtent {
    get {
      string directionOfGreatestExtent = "X";
      if (this["Y"] > this["X"]) directionOfGreatestExtent = "Y";
      return this[directionOfGreatestExtent];
    }
  }

In fact, it isn't even possible to really make use of the new $key support in that scenario because, as I said, they're not providing any mechanism to store the $key value and reuse it; you're forced to mix string literals and these key symbols:

  public double GreatestExtent {
    get {
      string directionOfGreatestExtent = "X";
      if (this.$Y > this.$X) directionOfGreatestExtent = "Y";
      return this[directionOfGreatestExtent];
    }
  }

I don't see how being able to make that change to this code is a step forward...

Good explanation, thanks.

I don't understand the advantage of the dollar syntax though. One character shorter, and makes it look more object-y, obscuring the perf difference.

(Two characters shorter.)

At least in python, I would love to have syntax like that. (I would use :: instead of .$, but maybe :: is already used in C#.)

Maybe it's just because I work with JSON a fair amount, but I frequently have an it-might-as-well-be-an-object that happens to be stored in a dict. And in theory, this means I need to do foo['bar']['baz'], which is hard to read and unpleasant to type. In practice, I often use a class which overloads attributes as being dict keys, so I can use foo.bar.baz, but this has its own problems. foo::bar::baz would be great.

If you have a 'it might as well be an object' in C# it's trivial to change it to an object with anonymous types and then blam you've got all the advantages of statically typed objects.

I, as the next programmer, would hate you if you started trying to use C# as a dynamic language by abusing dictionaries, you're losing all the advantages of C# while still suffering the disadvantages.

My gut reaction is that I'm not sold. With HTTP requests for example, I want to say `if 'id' in params`, whereas `if hasattr(params, 'id')` feels unnatural. But I also know that I'm accessing `params['id']` at programming time, so it would be great to shorten that to `params::id`.

(And this ignores converting to JSON. The library I use is designed to be passed dicts. You can teach it to accept arbitrary objects, but that's kind of a hack.)

I can see the use case for json, but hardly for anything else. What's wrong with just using a class here? Seems very similar to how it would work in java script.

Any time you have a dict with stringy keys that you know when writing the program. HTML attribute lists, database records, http request parameters, config files.