About lambda short forms, and other preview items

[mwpowellhtx]

Q: around lambda short forms ... out in particular. I'm assuming the same variable declaration guidance still applies. So in Mads brief illustration, i, for example, would still need to be declared in some way, correct?

[mwpowellhtx]

On the question of a field keyword... what is the naming guidance around that? And could we automagically, for instance, specify underscore prefixed? i.e.

int _value;
public int Value { get => field; set => field = value; }

Not sure what question that really addresses, unless there was an ability to disguise the desired prefixing strategy. Or that you would not just go ahead and declare the field to begin with.

[mwpowellhtx]

To further clarify, as far as I am aware, the @keyword allows one to mix in actual keywords, for instance, could do @params, or @null, which I do not recommend, regardless. But this detail has been there for awhile.

[mwpowellhtx]

Not sure what Wagner's point over partial class has to do with the topic, however.

[huoyaoyuan]

On the question of a field keyword... what is the naming guidance around that? And could we automagically, for instance, specify underscore prefixed? i.e.

This is a misunderstanding about the feature. You don't need to declare the underlying field. This is a complete property definition:

public int Value { get => field; set => field = value; }

[mwpowellhtx]

String literals WHAT ... Woah, wow. Good to know one the one hand. But assuming there is a memory barrier there, doesn't whacking the string from 16-bit to 8-bit UTF only postpone the inevitable?

[mwpowellhtx]

And the natural follow on question if you MUST still have UTF16 characters, then you're just SOL, have to consider factoring alternatives, etc.

[huoyaoyuan]

It's purely an compiler implementation detail about how it stores the strings. It's totally transparent about using the strings.

The main reason is that IL string heap has a length limitation of 2^24 bytes (8M chars). See the design at https://github.com/dotnet/roslyn/blob/main/docs/features/string-literals-data-section.md .

And the natural follow on question if you MUST still have UTF16 characters, then you're just SOL, have to consider factoring alternatives, etc.

We speak non-Latin languages. UTF16 is the optimal globalized storage format.

[mwpowellhtx]

My opinion, based on the JSON spec, representing null in JSON as a "null" string literal... big mistake. And violation of the core JSON definition. Note, null is actually null, in JSON. AFAIK. And based on the verbiage flying around to justify that decision, someone surely must have called attention to it before floating in a stand up.

[mwpowellhtx]

Best guess without analyzing lines of code, claims of breaking changes and so forth, would not be the case, if y'all followed the JSON spec. You are doing null things with string literals that you should not be doing, and expecting a null response.

[huoyaoyuan]

JSON and C# language are totally unrelated. For JSON, JsonSerializer.Deserialize("null") correctly returns null instead of string "null".

[CyrusNajmabadi]

@mwpowellhtx you are deserializing Jsom already encoded into a.net string. Note that the contents of the string are what are deserialized, not the container type (System.String).

Hence the contents of the string are things like:

null
0
[A,b,c]
"Foo"
{ }

Etc.

You are confusing the content with the string literal representation itself.

[huoyaoyuan]

For lambda short form:

It allows you to write (ref i) => instead of (ref int i) =>, just like how you are allowed to write (i) => instead of (int i) => today.

---

The majority of design and discussion for C# language is in https://github.com/dotnet/csharplang repo. You can find details of design decisions there.

[CyrusNajmabadi]

Agree with @huoyaoyuan. These are questions for csharplang