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.

[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.

[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.