-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default Type for Collection and Object Initializers (List and Dictionary) #5865
Comments
In expression-bodied methods this wouldn't be ambiguous since currently |
Why propose a dictionary initializer that deviates from existing syntax? // dictionary
var dict = {
"key1": "value1",
"key2": { 1: "value", 2: "string" }
}; to // dictionary
var dict = {
["key1"] = "value1",
["key2"] = { [1] = "value", [2] = "string" }
}; |
@aluanhaddad the purpose is to provide a lightweight syntax for dictionaries, your example is not much different to what is possible right now with indexer initializers. Indexer initializers as a generalized feature make sense because they can be used on all types with an indexer, not just dictionaries, on the other hand, since dictionary expression defaults to |
@alrz Because I do not think a third dictionary initializer syntax is a good idea. We already have {
{ key1, value1 },
{ key2, value2 }
} and {
[key1] = value1,
[key2] = value2
} both are already understood, and the latter is already lightweight and consistent with object initializer syntax. Additionally, what makes your proposed syntax lightweight is the constructor type inference, not the omission of 2 characters per dictionary entry. Furthermore the comment in your first example // list expression defaults to List<T>
var list = { 1, 2, 3 };
List<int> list = { 1, 2, 3 }; implies that the types targeted by the new syntax can be overridden. Is this correct? If not then this proposal is of extremely limited value. For example, If I can't initialize a readonly collection with the new syntax, I'm not interested. |
@aluanhaddad The former is not an indexer initializer, it calls the Dictionary expressions are not intended to be used for initialization they are standalone expressions which return a dictionary.
No, I just wanted to show that the list expression returns a // currently possible
int[] array = { 1, 2, 3 };
// list expression
var list = { 1, 2, 3 };
// your case
Collection<int> collection = { 1, 2, 3 }; basically, extended array-initializer syntax to support other collections.
This one actually depends on collection initializer specification, since currently it simply calls the |
I totally forgot this because they were so often used with indexable collections, I stand corrected.
I suggest creating a separate proposal for this feature. Note that the title of this proposal is "Syntax for List and Dictionary (Extended Collection/Array Initializer)" which is why I thought you meant initializers. What you are proposing is a literal syntax for creating |
@aluanhaddad I've been thinking about this and your arguments, I come up with two ideas: I admitted that I'm not a fan of ranges, I just mentioned them here for the sake of completeness. so I'm thinking about narrowing this proposal to "default type for collection and object initializers" as you thought it was. and propose a new syntax (surprise) JSON literals. |
Since most common types that are used with collection initializers, are lists and dictionaries. It would be nice to provide a concise syntax for creating them by making
List<>
andDictionary<>
default for collection initializers and object initializers respectively.Currently following statements are legal.
With syntax proposed in this topic you'd be able to write:
It should be able to infer the default type by usage:
new Foo { List = { 1, 2, 3 } }
initializes the existing list (if notnull
) with listed elements. However, as long as it's not ambiguous with anonymous types, we can use anew
keyword to explicitly create a new list:new Foo { List = new { 1, 2, 3 } }
.{ [1] = 1, [2] = "" }
returns aDictionary<int, object>
.The text was updated successfully, but these errors were encountered: