I was going to say "as opposed to a little less than an hour's walk", but in the US there is the question of how many 14-lane highways and Costco parking lots you would need to cross during that hour.
The general argument is that if you are a proto-government/warlord/gangster, you want to encourage/coerce your subjects into agriculture as the output is easily taxed and stored. This turns out to be wildly successful for creating large hierarchical societies, which in turn forces their neighbors to do the same to survive.
Unlikely. The new collection literal syntax exists as the dual of the pattern matching syntax, which itself exists primarily because you can't reference a generic type by name without specifying the type parameters.
If you want to write out Dictionary<Guid, ILookup<int, List<MyEntity>>> instead of having it inferred then go for it I guess.
I'm interested in new offerings in this area, as all of the existing options are pretty janky. A couple of thoughts:
Operation.summary is typically derived from the documentation for an API operation, and should not be used as the operation title as it is far too long. Instead use the operationId and path.
I can't get it to render schemas for a bunch of my OpenAPI documents, and there are no error messages to guide me. Does this handle recursive schemas (which can never be fully expanded)?
Collection literals are a pointless extension of the pattern matching syntax added to get around the fact that there is no way to name a generic type in C# without specifying its type arguments.
It's yet another double down on object initializers instead of writing constructors and factories, and unlike using a factory you have to fully express the result type of the collection instead of having it inferred (they are "target typed", another feature that probably should not have been added).