Following on from this weeks stand up

[mwpowellhtx]

Why was the conversation closed and locked? Many claims of "misunderstandings", great, explain HOW it is a misunderstanding, in accordance with the "preview period".

[mwpowellhtx]

Lambda short forms.

I would expect something like this. This is interesting, yes.

DO lamb = (s, out i) => ...

// I see, I see.
lamb.Invoke(text, out var value);

[mwpowellhtx]

Re: OpenApi and the basis stemming from the JSON configuration file. Recall, this is the basis of the conversation.

So much of the conversation during the stand up revolved around the string literal "null". Whereas, I think the intention ought to have been properly null. No need to break any changes in that regard.

null in the JSON specification is not a string literal. In rather the same sense, true, false, are also not string literals. But in terms of keyword grammar, tokens, how to read that is as a keyword.

One case for instance, the proposed preview change:

"height": {
  "type": {
    "null"
    , "integer"
  }
}

Whereas the baseline, I'm assuming, would be just fine, no need to break anything.

"height": {
  "type": {
    null
    , "integer"
  }
}

From the JSON specification, what a value can be:

[huoyaoyuan]

This repo is not the correct location to discuss this. It should go to /~https://github.com/dotnet/aspnetcore .
The previous discussion didn't mention OpenApi. It's very hard to get the context.

[mwpowellhtx]

My apologies I wasn't clearer the context. Everything sort of being glommed together and presented under one unified banner. My misunderstanding in that regard.

[CyrusNajmabadi]

Please open individual discussions. Creating one Uber discussion for a variety of topics across many owners is nearly impossible to track

[elgonzo]

You confuse things here. You will have to familiarize yourself with Json Schema to understand what you are looking at.

What you see there in the video (and in the snippet you included in your comment) is not a json string "null" representing a null value in an array.

What you see there is a part in a Json Schema, a declaration of the allowed value types for some json properties (like "height" or "weight" shown in the video, for example). Note the type property (type is a Json Schema validation keyword) being an array ["null", "integer"] declares that for example the "height" property in a json document validated against this schema is only allowed to have either a json null value (which would be a json null literal in that json document), or a json number value that is an integer.

Put differently, "integer" is a json string and not a json number/integer, right? So, what is that string for then? It's the (string) name of some type defined by Json Schema - a type that encompasses all integers representable by json number values. And in exactly the same manner, "null" is also the (string) name for some type defined by Json Schema - a type that encompasses only a single value null.

If this won't make you click and you still remain confused about why there is a "null" string and not a null literal, like others have said please open an individual discussion in the appropriate place. But please beforehand familiarize yourself with the basics of Json Schema, otherwise it risks ending up being a laborious discussion with many misunderstandings....

[stephentoub]

cc: @huoyaoyuan, @CyrusNajmabadi

[huoyaoyuan]

I don't have permission to lock discussions. But surely, there's better place to discuss these topics.

[mwpowellhtx]

Re: UTF8 versus UTF16, let's be clear the down range ramifications. There is still the string literal size restriction, yes? So UTF8, while an interesting stop gap measure, does not fix the underpinning size restriction, correct? Only serves to postpone factoring choices, such as that, yes? Not saying here, either way, whether anything should be done around that size constraint. In addition to which, if any of the literals require UTF16... then those factoring choices are the path foward.

[huoyaoyuan]

There is still the string literal size restriction, yes?

There is no infinite storage. The new limitation will be much larger.

Only serves to postpone factoring choices, such as that, yes?

There's nothing to postpone.
The restriction more than 1MB is very unlikely to hit in real world. Typically usages tend to store strings that large as resource file, not string literal in code.
There are many operations requiring UTF16, especially on Windows. Currently C# has UTF-16 and UTF-8 string literals, both of which will be stored in the same encoding when they are loaded.

Actually I don't think this compiler feature should be mentioned too much. Users should just use UTF-16 literal when they need UTF-16, and UTF-8 literal when they need UTF-8. Everything is handled transparently.

[mwpowellhtx]

Please don't misunderstand the take aways from the stand up, there is still the size constraint. I'm not suggesting whether anything whatsoever should be done around that part; read: it is what it is, and how to navigate the choices. Opting for UTF8 is not a magic fix; and in cases where UTF16 is a must have decision, then eventually, factoring decisions must be made.

[CyrusNajmabadi]

Why was the conversation

Because csharp language questions should go to dotnet/csharplang. Also, combining N discussions into one just adds court clutter and difficulty. Marking messages as answers for example