.Net Foundation Design Reviews, 17 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitHub Quick Reviews

Description

Issues Covered:
* dotnet/runtime 29937: Support polymorphic serialization through new option
https://github.com/dotnet/runtime/issues/29937
* dotnet/runtime 53211: Debug.Assert overloads with interpolated string handler
https://github.com/dotnet/runtime/issues/53211

Chapters:

0:00:00 Intro
0:00:46 Support polymorphic serialization through new option
1:16:01 Debug.Assert overloads with interpolated string handler
1:43:32 Loss of quorum

A

There will be a new one.

B

Hello: everyone, um despite the fact that, on tuesday we said there wasn't a meeting today, um the calendar did correctly say it so uh surprise um we're reviewing jason polymorphic serialization, which, uh instead of our standard github quick reviews, title I've actually tried to title today's uh series. Episode stream thing: words great all right. I should not be talking so I'll. Let someone else uh supporting polymorphic serialization through new option. This relates to json serializer, two niner niner, three seven and I will click.

C

Okay, so um let me give some background on this feature. um This is actually one of many polymorphic serialization features that we're planning for system text, json uh 4.6 we'll only be focusing on this one, which uh is, I guess, an extension of the way that we currently do polymorphism but restricted to system.object member types.

C

uh So I've written up a simple example here, consider this type hierarchy. You know inspiringly named foo baron baz.

C

Currently, if you try to serialize instances of either type in this hierarchy and you serialize it using the static type foo, then the json schema would always invariably be derived from the type 2, which is the right default behavior in my opinion, but there have been requests for extending effectively polymorphic support for arbitrary class hierarchies again.

C

I should maybe point out that current under the current behavior uh shift in token five in system text json, when you have members uh either be you know the root type or you know the property type of a nested uh object, we'll type uh object.

C

uh Then the serializer will dispatch to the converter generated from the runtime type of the given object instance.

C

So this is a proposal to extend this to plus our hierarchies. uh Could you scroll down a bit please so yeah, that's fine! uh So under the current proposal, the idea is that you basically decorate the base class with a json polymorphic type attribute and now, when you try to run the same thing uh with uh you know, serializing foo bar and bars using foo as a static type. Then, actually it will end up using the json converter, corresponding to the individual runtime type of the provided parameter and that's more or less the design.

C

um uh Forgot what I was gonna say, but uh yeah basically polymorphism applies to uh netflix values as well. So you know uh if you have a property of type foo again, uh you know it will dispatch to the corresponding uh to the to the converter, corresponding to the runtime type, and it will serialize all the relevant properties for you.

C

uh I, it might be worth pointing out that this feature has absolutely no provision for this realization. It just provides a mechanism, for, I guess, dumping all your sensitive uh properties of your type hierarchy on the wire.

C

And um that's uh uh the there. There is another design proposal that has been cut from dotnet six, that concerns um uh support for both serialization and this realization. It is a an orthogonal feature and it involves serializing type identifiers on the wire which I know excites, barry um uh and does.

D

The attribute apply just oh sorry, oh no go ahead. Does the attribute just apply to the thing being serialized or would it work on properties.

C

Under the current design, it only applies to the type definition, although I guess we could extend it for uh for members as well properties.

E

Eric the the type scrolled off the screen right, so I missed it, does baz derive from bar or from foo.

C

uh It derives from bar.

E

So bar doesn't need the attribute as well. You put the attribute on the base class and then the entire hierarchy is serializable.

C

Good question, uh so the the attribute is not inherited by derived types, so just because we've declared foo to be polymorphic uh that doesn't transfer to any derived type, so bar is not by extension, polymorphic and the rationale behind this is this is extending what we do with uh object, because you know object is always polymorphic. You can't opt out of that behavior, but any type deriving from object is not automatically polymorphic. Because of this.

E

So that I'm missing, I'm not understanding the the sample at the end there, how is c serialized out, uh which.

C

E

If I only add jason, polymorphic type tofu, how.

C

Am I so the it it only informs uh how the so so. Basically, it only informs the static how the static type foo is meant to be serialized, so any uh any derived type from foo will be serialized polymorphically. But if I were to replace the angle replace foo with bar in the angle bracket, when I was serializing baz, then it would not do a polymorphic dispatch.

E

Right, but just to make sure I understand it when I mark foo uh not only does that allow bars properties to be serialized out. It also allows baza's properties to be sterilized out, even though bar doesn't have the attribute. So it's recursive through the whole hierarchy.

C

Right, provided that the static type is free.

E

Okay and that that avoids the the reason we and there's a lot of debate about what to serialize. You know, based on what type you specify and the concern was around your derived types might have sensitive state. We believe that that is sufficiently medicated just mitigated just by attributing the base type, but someone's not. You know you annotate your employee class as serializable, and then someone derives from that. You know hourly, but then someone derives from that with social security number.

E

It's that's still going to serialize out the social security number we're okay with.

C

That, um uh to be honest, to be very honest, that was not considered when I was designing this feature, so I.

E

I also don't have an opinion or answer. I just want to make sure we're we're doing things that are consistent with decisions that have already been made.

C

Right uh so that was not considered, and uh that was primarily because the design was sorry. This feature was designed with people that were kind of uh so so I I I would say that this design was uh offered to people that explicitly wanted the entire type hierarchy to be uh emitted onto the wire. As is um I, I recognize that this has substantial.

C

uh You know data lake ramifications, but that was basically what users were asking uh in this issue uh now we could change this and uh change it into a model where you have to explicitly obtain individual derived types, but I believe the appetite was to you know. I have an open, a hierarchy.

C

I might be having an assembly that defines another derived type, which I don't have access to in the base type, um and I want that to be emitted onto the wire as well uh for what it's worth, uh the other polymorphic serialization feature where uh you're actually emitting type identifiers to the wire in that design derived types have to be explicitly opted in. If that makes sense, and that relates to security considerations on this realization.

F

So why don't these security considerations apply? Here I mean you say that people may want to serialize the derived type in another library that they don't have access to, and you know that that that seems to me to be a very good reason not to allow it because that derived type may you know you may have some innocence um class somewhere and then the derived type has a username and password in it.

F

um So you I mean you know generally how I'm going to feel about this feature period um and allowing people to explicitly opt in objects that they don't own uh feels wrong. um The the other question that I have- and I was gonna leave it to later, but now that I'm starting to rant, um I may as well throw it in here, is: will any framework classes have this attribute applied by default? And if the answer is yes, what do I need to do to stop that happening?.

C

uh So, in order to opt out of something that has the attribute already applied to it, you would need to so the same flag can basically be specified in the json serializer options class. So it is exposing a predicate uh that you can set and you would be able to sort of opt out of polymorphic behavior for a given type, even even though it might have the.

F

F

It's still up to the developer, to do that. Is it not rather than the owner of that type, so say, for example, um aad has a a type that they don't want to be polymorphic to be serialized in such a way, but someone will derive from it and slam it on the derived. I'm just I'm I'm concerned that people will apply this to things that it most certainly should not be applied to and start doing really. Weird things I mean like anything. I believe it should be opt-in.

F

You know it should be attributes all the way down for opting into this sort of thing. Otherwise we end up with where we used to be with xml serializer, um which would you know you're having to opt out individual attributes, rather that are unsafe, rather than often the ones that are safe.

A

Yeah, it seems to me, like you, want this attribute on the derived type and then, basically, when you serialize an instance, you find the base, like the yeah, the closest base. That still has the attribute right. So if, in your example, if, if you scroll up again, if let's say bar has the attribute and foo has the attribute and it's realized bass, then bass would be serialized as bar yeah. I.

C

A

This is the closest one. It still has the attribute. That seems more logical than the inverse, because the other thing I don't like is now in your example. If I seo lies as foo, I get more state than if I serialize as bar and the instance is a bass, and that seems.

G

Very unintuitive.

A

C

Like why would you.

A

Get more state when you have a when you say.

C

I would say that I would say that this reflects the current design of system.object, which is already polymorphic, and it effectively behaves that way. So, basically, there is a boolean flag that has been hardwired for the system.object type and whenever you have a property or a root value that has a static type of object, then whatever exists in uh sort of the converter corresponding to the runtime type will be emitting onto the wire. So I would probably say that this uh security consideration already applies to system.json.

A

C

A

So fair, but I think it's also fair to say object is special. I wouldn't necessarily say that, and this we should take that design and roll it out for the entire hierarchy, because every.

G

A

Is special for boxing and you know it's just a you know, untyped anything kind of thing right, so I feel like. Even if we have this discrepancy, I think people would maybe even find this still intuitive but, like I think the proposal here doesn't seem intuitive to me.

C

Yeah and again you know what what you mentioned about this only applying, so you basically said that uh you find it strange that the attribute is not inherited by derived types. But again this is reflecting uh the design of uh uh you know how polymorphism currently works, where only the top level type is polymorphic, but anything under that type is not right.

A

C

A

But, based on what barry said, I think it, it is fair to say, like I think the deriving is the is the wrong direction. I would just say all the things that you know all the leaves have to be annotated and if somebody derives from a leaf- and you know, adds more state unless they apply the attribute, that state is never going to be serialized and I think that's generally the right behavior, because then, basically, you get 100 controlled and people don't accidentally leak state ever.

F

The other thing is, I mean I, I understand the argument that system.object does does this already, but system.object is the the main case that shouldn't of something that should never ever be marked as uh polymorphic serializable.

F

um It is in fact the the reason why this this thing, probably shouldn't exist. If you know if we applied this, if we applied this to system.object we've reintroduced um remote code execution, we have basically reintroduced binary formatter, yet again so using system.object as a base for the design pun intended um is probably not the the right way to think about it. It might be.

A

But also it was glorious, I mean. Let me let me try to understand what eric was saying. So basically, what eric was saying, I think, is that if you have a property on a poker today that is typed as object. We would serialize the type whatever the actual runtime type is. Is that is that correct, correct, so.

D

Stepping back like.

A

A thousand, oh sorry, no! No! It's not to a bearish point like is this. Is this considered a bug or a feature like because I mean at this point the question becomes like if we think that's a that's a major issue, maybe we should just make it opt in rather or opt out or whatever the the. I guess. Opt-Out will be less breaking. Obviously, because we ship that behavior already.

G

I mean this was definitely a feature it was discussed in v1 um system object is treated especially, and it's become it's because it's explicitly system object. It means that you know you can assign any type to it and it's it's actually explicit because of that um type. So it was thought that if you do have um a system object type, we want to also support. If you change, if you want polymorphic support, you have to change your type of your property or element to system object to kind of opt-in.

G

That's what we decided in v1 on the serializer, which also then allows you to do a round tripping um and during de-serialized we create adjacent element type, which is a loosely typed. You know way to get your data, so I mean it was definitely a feature. Not you know not a book.

D

Can someone explain to me how the attributes better than just the serializer option or serializing object? I don't get the use case to be honest,.

A

Well, you want it strongly tight right. I mean if in your dto, if you have let's say a property called strategy, and that has a virtual method on it that you expect derived types to override it's kind of shitty. If you have to like cast this from object to strategy every single time you access the dcis object right, I thought you were talking about serialized.

A

Well, I mean, I think you.

E

Know doesn't support this time. This design doesn't support deserialization because it's not emitting any type data.

B

Oh yeah, this is, writing only.

D

Oh, this is right.

B

So I still don't get it.

D

Like I don't get what the attribute's getting us over the global option or just serializing object.

H

Right, why, wouldn't you just say, serialize angle bracket object, open paren bar bath.

B

Yeah that gets.

H

You, the behavior, that you get here.

B

Well, object is, uh and I think that's for reasons it ended up only going one level deep.

H

No, he said it uses the run time.

B

Really well, the well.

G

You know it'll go as many levels for after this one.

E

Or a property of type food, uh I would have to change that property via type object to get the polymorphic behavior right.

D

E

D

What about the global option that was at the top? I'm sorry.

E

Right, well, I'm just talking about the why it's not just change food to object in the generic type parameter, because.

G

E

The okay, I have the same question as stefan, though about. Why is this design better than just having an opt-in option on the options? How many times can I say, option in the same sentence that basically says do polymorphic for everything.

C

As in one global flag,.

E

On the options, so instance, global city instance of the options being used.

C

So if I, if I get the proposal correctly, you're saying that there should be one boolean flag in the serializer option, that basically opens the flat gates and makes everything polymorphic.

E

Yeah, I'm asking- or I think, stefan's asking: why is that? Why is this design better than that design.

C

um So that was actually the initial proposal, so if you scroll up into the original post that steve actually proposed, that was the design, and I guess I ended up not doing that, because I assumed uh that people might want. uh You know finer grain control over. You know which hierarchies you want to do to you know to impose this on.

A

Make sense yeah.

D

I mean at that point: would you want it to be like member attributes right like if it's applying to like whether you interpret the member as an object versus it's like concrete type but like, and that does honestly seem a little niche niche whatever.

B

I mean I can see both member level decoration, which came up uh earlier and the type one like if you know that you're having um you know some sort of you know three variant thing with a base class that you're trying to send over the wire you'd, be like it's the base class and do this polymorphically just figure out which set of parameters you need to encode and that you've decided. This does apply to your type. But you don't want everything to do that.

B

It's just this one little piece of data and you can write it with a converter. But I I'm not saying it's. The most valuable interpretation is, I just see it yeah.

A

I mean, I think the the key scenario for member level would be, if you don't own the types right well, that's then the, but then the problem is kind of skeptical right yeah. I guess that yeah I mean honestly. If you have that, then why would you ever want to remember level.

A

F

I mean, if you don't own the types write your own poco and then just do a transfer in and out stop messing around with other people's stuff. Bad slap in the rest.

D

A

Yeah, it's just hard in practice.

A

Or more work, I should say um to me: this is why I don't like member level is. It feels error prone.

A

B

To me, this seems like.

A

Well, I mean, is it I mean honestly like if I, if I declare the types that I want to polymorphic behavior, for then I mean.

B

A

Function of the type it's not a function of where the type lives right well,.

B

But now we're back to steve tobe's point of you know, take our our model of you. You extended a type because of programmatic reasons, uh you're, not necessarily aware that it's being serialized somewhere and you're, not aware that you know the base class of your base class of your base class just declared itself to be json polymorphic that wasn't part of your object design when you made something be a property instead of a method. uh You didn't.

A

Know it was going through the json serializer.

B

So you didn't put jason ignore on it.

A

So I would agree with that. That's why I would say like to me. I think the design we have should still not talk about basis to talk about the the most derived state. You should basically annotate the leaves like that's my opinion like I, I would not say treat strategy as polymorphic and now suddenly everybody who's deriving from strategy gets polymorphic behavior. I think that's that's wrong. I think you should say here's the types that I want to serialize and.

C

Something is derived.

A

From that find them find the closest one, that's markedly sterilized.

C

In that design, would you still make it possible for the user to say you know screw it? You know just opt-in for everything, so open hierarchy. uh Would that be a valid option under the design you you're considering.

A

I mean I, I would wonder why you would want that, because I mean at that point like if you literally say take anything at that point. You probably have something like you know, literally object like do you actually care like I mean because I mean in almost all polymorphic cases you talk about a you know: a closed hierarchy right.

C

Yeah, I I mean for the record, I don't believe in open hierarchies, but uh I I would say that uh you know uh there might be use cases where, for reasons that are beyond me, you know a user might say. I don't know what the hierarchy will be at runtime just opt into everything. uh You know I. It sounds like a valid scenario for me, particularly given the fact that we already do this for object.

B

I mean it just makes.

C

It be the json string of.

B

F

Well also, it also makes it into yet another um remote code execution if you're, you're, you're just gonna opt in an entire hierarchy of stuff. I mean at that point: why don't we just run on apache struts or in java struts, because that's that's what we're reintroducing so rce.

B

Requires that we support polymorphic deserialization, which, yes, this proposal does not support.

F

ah Okay, I kind of figured that at some point someone will suggest this, because we've done it one way it's going to have to be deserialized back the other and that's kind of what I'm concerned about.

C

No, so so so this proposal does not emit any type metadata on the wires. So this realization is unless you're deserializing in a dynamically tight. You know uh runtime. uh You know this realization is out of the question, uh the other feature that has been cut from sex, uh which does support emitting metadata and deserializing. That actually requires opting into individual derived types.

A

But I always think these things are related. Like I mean, why would I want to have one, but not the other ever like it seems to me if you have a closed hierarchy at some point, you would want deserialization, and so I think, whatever mechanism we have there seems you know we should design it such that when you use the other side like it's not a completely like competing proposal right and I think for the other side, as you said, you probably want a you know you list every single time you want to deserialize yeah.

C

I would say.

A

Sorry, yeah and.

C

Then you basically have some sort.

A

Of tag or type information that you emit right, if at which point like an open-ended hierarchy, would just feel odd right.

C

I I would say that there are valid use cases for both features and they would not be used for the same purpose. uh You know the other feature emits metadata on the wire and in some cases it might be noisy like uh if you're, if you're emitting, for example, a polymorphic collection, you end up having a json object with some metadata and then a nested array, and that might be undesirable.

C

If you know whoever you're sending this data to, uh does not care about this realization, they just want, I guess, a rich representation of your object graph uh in json. uh That would be the use case for this feature, the other feature where you are emitting metadata and where you are doing all this opting into derived types and what have you uh there you're more interested about round-tripping data in sort of homogeneous.net processes?

C

And it's you know more applicable when you want to like serialize discriminated unions- and you know things like that, uh so very different use cases.

A

More server to javascript yeah, I mean I don't question that there are cases where the receiver is not done. It just seems like there will be cases where both exist and it and I'm just asserting that it would be nice to have a design where sealed station and deserialization feel, like you know, counterparts to each other rather than completely disjoint feature sets with different opt-in mechanisms.

A

G

Just note that there is another feature that we have and it's called extension data. So if you do serialize with this feature um that won't serialize metadata, if you add the extension data attribute to a dictionary property, we will put the you know quote unquote overflow properties inside of that dictionary, so you can kind of get round tripping with this model. It's just that you have to look inside this dictionary to get the other state.

A

So what do you consider overflow state, basically state that is on the derived instance, but not aesthetically typed as such.

G

Well in the center yeah, so in a scenario.

A

That eric pointed out, if.

C

G

Serialize something like baz polymorphically, the variable type is foo or whatever um they'll sterilize it. You know polymorphically and if, when you desterilize it back to foo um as long as who has a data extension property on it,.

C

G

Will be assigned to this dictionary and for this release we have, since we have the json nodes class um instead of a dictionary or json element, it can be a json object which supports edits. So um this feature, along with the new json object, plus the existing extension data, would allow you to kind of do round tripping in a kind of a not perfect way, but but it would work at least.

A

I mean I, I think it makes sense to say, like you know, let's discuss civilization, independent of desertization, but I I feel like from a design standpoint. It seems desolation would mostly prescribe a closed hierarchy right. So the thing is now. If we, if on this feature, we have a you know a global switch that says you know any type. Basically right, then that would basically mean we wouldn't be able to deserialize that right and so then the question is: what's the like: how do we do that?

A

We can't really throw an exception at that point, because what would we even do? um Because we can't tell necessarily, but that's why I'm not a fan of that design like I I would I would prefer civilization, is basically you list all the types you want either. As you know, an attribute on the type or you know the supported, polymorphic type property on the json serializer options, because that one at least I can see how we could make that serializable.

A

It's very deserializable without introducing massive security holes, um and then anybody who has an open hierarchy and just know the types I'd be. Like sorry like, I said, can't do that, but it seems to me like you should be able to write an algorithm that finds all the types and puts them in there like I mean because clearly you have a closed process right with you know at some point you walk the object graph and you should be able to tell the types at that point.

C

At run time here.

A

Yeah, which I mean you populate the stila direction, to see the other options at one time right so, like you, you might have to write some code that does that, but, like that seems you should be able to list the types you want.

A

But at that point the person clearly clearly opted to the behavior right and then they should not be shocked if the types that they're listed there are actually being serialized and deserialized.

C

So I guess the question, then, is whether we want to change this into a model where uh you would have to opt in to specific derived types, and you know one lazy way of doing this. I put it in the chat, is you know we can just change the predicate from accepting one type parameter into one that accepts two type parameters, so the base type the derived type and returns a boolean, and that would make I guess both the people that want a more restricted model.

C

Happy and also the people that you know don't care and want to. You know, opt into everything.

A

So what would the types be in this.

C

A

C

So so you, instead of a funk from type to bull, you would have a fund from type to type to boo, uh so the first argument would be the base class. The second argument would be the derived class and it would return a boolean indicating whether a runtime type of the derived type should be serialized polymorphically, given the static base class.

B

So declared type comma, runtime type to yes or no.

C

Yeah and uh matching attributes, obviously.

I

um Very terrible performance that would be cached.

C

B

Well, I mean somewhere you're going to have to well. It means you're going to have to call get type on every object, because you now no longer have a static way of unless there's also.

G

A thing that you have to put on the property.

B

To say this property supports polymorphism, you would say for every for every value you ever see. You have to call get type, which um I mean, maybe that's cheap. I was just given the impression you know like 15 years ago that that was less cheap than you might think.

C

No, I think I think, you're making a good point, because uh you can't really pre-compute everything uh for a given base type.

B

Because, like it makes it would make sense once you've decided polymorphism might be appropriate here as a filtering mechanism. The question is, how do you determine polymorphism might be appropriate here, and maybe it's if you register this delegate, then yep your you call get type on literally every uh sub value.

A

How would we, like I mean? How would this work with source generation? I mean source generation would only work with the attributes right, so you wouldn't be able to support the func. The terms that talks in terms of reflection types right, so you you would basically say like. If you wanted to opt in other people's types, you would basically have to invent some sort of assembly level attribute or sorry another zombie double that can actually be put on the json. I forgot what it's called the json context where you can say you know this.

A

You know serialize this thing as a in a polymorphically kind of thing right um and so wondering like do we do we do we want to introduce the supported, polymorphic types thing that talks in terms of function? We know we can't do the the the source-based thing or are we thinking like yeah people that don't care about source generation? They will just use this one and people that care about source generation. They will they'll apply the attributes.

C

Yeah, the the funk thingy is certainly for people that are not using source generation for the context of the type. These types, at least.

B

Yeah, my my recollection and please correct me if I'm wrong is that source generation basically ended up with it, produces two paths, one where you didn't have custom options and one where you did so in the warmer. You don't have custom options. It would know there would be no polymorphism, so it would still be able to do fast generation.

B

It's if you used custom options that now it's going to not be able to trim anything out, because you may have done literally anything.

J

Yeah, we have two modes with this with first generation, where in one word it's why you describe where you tell us predefined set of options you can support in, like serialization logic and in another mode. We basically do what this related serializer does um at runtime, what a compile time instead, so all the reflection that we can do statically, we can do it, um so we create the same like json type infos like the same type of information.

J

So the features that we would need to use reflection at runtime to support to understand is what we would be able to support in this question. So if the implementation for for understanding the closure means being not reflecting on types, then it's irregular, um you know wouldn't be supported in society mode. So the couple of modes researched in this.

J

G

So lay only in the in the source gen is it possible to detect? If we have this attribute approach um that we need to call object.git type and serialize a different set of maybe additional set of properties or forward to a different area code that knows how to serialize the base our drive types.

J

So for sourcing you need to indicate the base type and all the the possible runtime types then um at runtime you would have to call type gettype, which I think is fine, and that type that is returned needs to have been indicated beforehand at compile time, then that way we can look up the metadata like we have a mechanism to to retrieve it.

G

But without without metadata I mean we don't have to solve this now. This is uh like a low level discussion, but but I was wondering if there is a fast path option with this feature that doesn't require looking up to this dictionary. For example, I.

C

I think in principle, in fast path, source generation, you might be able to replace object.gettype with uh runtime type tests. If you know the the list of derived types that are supported- and I think I only shared some uh code, that was a pseudocode that was doing precisely that.

J

I mean it's, it's still, based on at least that was still based on calling get type. Is that a thing that we can do at runtime in the fastback, so just call get type on the type, and then we can still call generated serialization logic for all of the derived types, but you mentioned other type checks. uh What would that look like.

C

uh So so, basically it would be a switch statement on the individual list of derived types. If you do source generation, you could say you could generate that a switch basically a switch statement that checks through all the supported types in your hierarchy and dispatches to the individual converter.

J

But we still the entry point. There is still the declare type at that point. So yes, what are we switching on the result of get type.

B

C

B

I

C

The result of us.

J

Oh, I see I see, okay, well, is it order.

B

Get type requires that the reflection object of that type be created which maybe is only expensive the first time the type object has to be created, but the is check is a runtime thing that doesn't actually involve reflection.

J

Apparently yeah, that's fine.

C

But but I think that's a different discussion, I guess uh we there's certainly ideas we can iterate on, but I guess I guess that seems to suggest that perhaps a model where you explicitly specify the derived types might also be more friendly uh for the fastpass search and.

J

C

J

Would absolutely need to know them because otherwise won't won't have generated anything to support their serialization.

B

Yeah, which okay.

B

I don't know if that means it's a you know, collection of types that are polymorphic safe and if you see any static type, is one of these types, then any if the runtime type is any of these other things which you can filter to the appropriate scopes or a dictionary so that they have to provide the forward mapping for you in an easier way. But so I don't quite know what it would look like.

B

The problem with the attribute model is, if you're putting on the base class, all the known derived types, which is what the soap formatter did. I think is that you can't have your type hierarchy span assemblies, because the base type won't know about something in a future assembly. So you have to figure out how you can paint these things at what layer you could do so.

A

Well, that's why I generally think that it, you should always do it from the derived rather than from the base, because that also rewards the cycle and it avoids the. I have to know what my drive types are doing problem where I don't know whether it's safe right.

B

Right but now you're back to the when the serializer or the or the generated code is doing a thing it needs to understand. When I see the node uh value here, where value come from, there wasn't a value. uh Some other word value came yeah. uh When I see the node value should I even be looking to see if polymorphism is appropriate for this node, and the only thing it knows is that value was declared to be of type foo.

B

So somewhere this the fact the type foo needs to make this other new system wake up and and start taking action or you need to paint this property as supports polymorphism.

G

So I mean in summary, then I think what we're saying is that we have a closed tire type hierarchy of all the possible drive types, and we know that at design time you know we can do fast path. If we don't know it at design time, then the fast path, you know won't work or it has to do some different approach.

G

And we, and with the current model, uh where we specify the serializable attribute on the base type, we don't know all the drive types right. So if we want to support the fast path, we need the the other model where we specified on the drive types instead,.

C

But I mean: could it be the case that, when you're opting for a specific derived type, you might be enabling polymorphism for a different base class where, for which polymorphism would be inappropriate like to give you an example? uh If I have you know an interface ifoo that is not marketed as polymorphic, and I have some class implementing that interface and a derived class from that class, and I marked the derived class as polymorphic, because my intention is to serialize the. I should be naming all these things.

C

I'm sorry, but suppose you have an interface ifu, a class foo that implements ifu, and then you have a class bar that inherits from class foo and you decorate the class bar as being polymorphic, because when you want to serialize properties of type bar, you want polymorphism, but that has, I guess, the side effect of uh inadvertently opting into polymorphic serialization for anything that is of type ifu uh in context where uh you know polymorphism wasn't expected at all in the first place. Does that make sense?

C

So, if you're, if you're, let me uh restate that, if you're opting into polymorphism on a derived class basis, uh you it might make sense for you to specify in relation to which base class. You want this to happen or which uh interface which subtyping sorry, which super type in general.

B

Yeah, that was my dictionary of types to collection of types.

A

And that's kind of I mean I think if we ignore interfaces for a second right, because for I think it seems to me that we look at base types, it's a linear list and I would say, as a derived type, you should be able to know whether that's safe, because you clearly know the chain of the base types.

A

I think once you support interfaces, it gets more complicated because yeah now you have this parallel multi-level hierarchy, right where there's no longer a chain necessarily.

A

But that also begs the question like: do we even want to support interfaces in this model? Like? Is that really a thing people want to do.

C

uh The the designers proposed does support interfaces and the reason for that is when you do it at the base class level, then interfaces don't become like multiple uh uh interface. Inheritance doesn't become a big use in the context of polymorphism.

A

C

A

Like I think, we already established that that's not workable right, so we so we would have to say it needs to be some combination of opt-in at the leaf at the at the base note, but also at the leaf node and so yeah. I guess if you say you express it in both pairs, maybe, but that seems overly verbose for normal hierarchy.

C

For what it's worth, if we're sort of to look for inspiration, I guess on other designs, data contract serializer also specifies polymorphism at the base class level uh via the known type attribute.

A

Yeah that one, I think I don't like for the reasons jeremy mentioned, because basically that only really works when when the they has been basically the hierarchy is self-contained in one assembly or in your closure at least right. If the base type is in a base assembly, then you're kind of screwed with that model.

C

A

C

Kind of wondering, if we kind of support the happy path that presumes that everything lives in the same assembly and we provide an escape hatch for everything else via the options.

C

B

Yeah, so I mean does that so the known types we're putting known something like known types on the the base type, um meaning that that would be using the static property type for a object tree.

B

Does that mean that the serializer option is? I have the screen so that.

B

Dictionary of type to what types are allowed to be substituted for it.

C

H

How do you add.

H

Let's get that is the case.

C

I mean I'm sure that wouldn't be the final shape, but it would be, dare I say, isomorphic to that shape.

G

B

G

This once I think in most cases, you said this once did not add.

B

The answer is once you have called serialize the first time. The options are sealed and you can't add more once you start serializing with a set of options. You're you're done you've chosen all your options.

C

Yeah and we we already have such a mechanism for sealing custom converters, for example, so.

C

But my concern about that approach is: we are effectively forbidding the nuclear option like the global flag work that just you know, dumps everything on the wire, because you know some people. If you look at the issue, uh it's passionate discussion going on some people are expecting precisely that.

C

And that that kind of brings me back to maybe we should be considering a predicate like design.

C

Which wouldn't discount the possibility of attributes following the model you showed? Jeremy.

B

Yeah, I'm just back to. If, if you have the predicate, how do you know to invoke it?

B

Is it always? Is it member level opt-in? Is it declared type level opt-in like that? That's the part that I don't understand with the predicate suggestion.

G

Well, ultimately, for a given type, we know what to do correct. It's not dependent upon anything.

B

Well, I mean that was another question I was going to ask is: is is doing it at the type level appropriate or is it really a member level decision of when I am mypoco.value?

B

These are the types that make sense to be here, but not all foos necessarily want to be polymorphically serialized.

G

B

So I had a similar.

G

Question I didn't ask yet and that's you know this dictionary proposed dictionary run time. um It does depend upon the type you're trying to serialize as the entry point to the dictionary, the key. So it's just not the simple type to say: hey, I'm polymorphic or not. It's you have to know um the the base type. I guess before you know the drive types. So it's hard to catch that way, if it's just at the type level- and you know whether something is should be sterilized polymorphically, then that makes it you know very efficient.

G

But in this case um it's dependent that you know effectively the type of the variable serializer, the element type.

J

So it's a quick question on whether we're we gonna call get type on in a case where we don't want to do any runtime reflection is what's the answer to that. Yes or no. We cannot call get type in those scenarios. That's reflection right when you want that knows, because if we can't call get type or runtime, then that means an options be serialized. Options based feature um will not work in search then just available.

J

H

Why are we saying we can't call git tape.

J

Is that yeah and that's my question.

B

I heard it's a performance issue.

G

um And so it's.

B

I'm just asking is that going to impact the serializer more than this feature is willing to spend.

G

Well, I think, as long as we have a flag or something to look at to determine whether to opt into this feature, you know that's fine. We check the the global option, the predicate or whatever, and then we call it get type.

B

If the predicate was eric's, revised, uh declared type and run time type, then you've already called get type. So it's the. When do you decide to call object, get type to then invoke the predicate to find out that it returned false right. I.

G

Just meant the global setting at all right I mean for all types.

C

So, uh going back to the original conversation like, given that we've established that rc, you know remote code execution is not a concern in this particular design. uh I, I suppose opting in individual derived types is really stemming from concerns that we might accidentally leak sensitive data in from the object hierarchy.

C

um So I'm kind of thinking, given that this is an opt-in feature, uh is that is that something we should be overly concerned about, and again I'm saying this being cognizant that you know object already is globally opted in for everything and I'm kind of concerned that we might be complicating the api service a bit too much here.

B

Well, but the difference is it object when you make a member or a property, be a declared type object? That is at this point in the graph you have made the decision to do one level of polymorphic uh data emitting: that's not universal for the type.

B

So it's not you know any object that could have gone there anywhere else that it appears on the graph uh did that. So this is changing that notion and now, all of a sudden you're making universal decisions based on type hierarchy that didn't apply previously.

B

So that's right, sort of where opting in a member of this member wants to be polymorphic is now again. You have the question of: is it one level or infinite levels, and uh and such that's closer to the, I declared it as object, but I also want value limiting from assignment, and I want to be able to invoke members off of it without casting and and other things um so like.

B

They are different and I do agree with emo's point that we shouldn't design something that works here for writing and then, if we have something later for reading that it's a completely different system and we feel that everybody ends up with the two systems needing to always interact and it's frustrating. So we should be considering deserialization. Even while saying we shouldn't support it.

A

Yeah, I think the the the.

B

Other question that.

G

A

To the earlier question of, do we you know, can we just have a hammer and make the hammer hop, and the problem is if the opt-in mechanism is the only way to make you know general scenarios work, then everybody will use that one global switch, but now they're also opting into a ton of potentially unsafe behavior, and that to me is the anti-pattern right we should. We should have a system that is relatively easy to use, while also being safe right.

A

Okay, I feel like as soon as we have a mechanism that says you know your market type and every drive type and to me whether it's one level or infinite levels doesn't really matter, because even at one level you don't know all people that derive from it right, so you're still opting in other people's classes, not knowing whether they intended this thing to be serialized.

A

Eba right- and I think that's that's- why I don't like this global switch, where you just say: yeah it's opt-in, yeah, but if that's the only way to make it work, then people will use it, and now they have like bombs in their code. Potentially right- and that seems bad- that's why I think we should. We should make the design usable enough that it's statically you know safe, while also making sure that enough things are expressible without people having to resort to a global switch.

A

So if we need a global switch, I think the design is screwed. Basically, I guess that's what I'm saying.

C

So I I'm picking up on your concern about needing to provide a way to deserialize here, but you know as it stands this feature, uh you know the way that we're emitting data on the wire there is no way we could deserialize this in a you know, anything that runs a nominal type system.

C

Basically, uh so perhaps the answer then is we should probably focus on the quote: polymorphic visualization feature, which is basically that other thing that emits metadata on the wire- and we only support that uh design and not this one and for users that want to just you know, emit everything on the wire. Our recommendation would be, you know, just use object.

C

And there's another there's another aspect uh worth pointing out here. uh This feature is very asymmetrical, but in the case of object there is no asymmetry and the reason for that is specifically for object. Deserialization is possible.

C

It is not real polymorphic visualization, but whenever we have a property of type object, we we we hydrate a json, node or json element instance and return that so in this case we're talking about a fully round tripable solution. Right in this proposed design. There is no round trip, as such, at least not in the dot net type system right.

C

So maybe that is a signal that we should and again you know if you scroll down in the document, I have an open question section and one of my concerns is: we have two things named polymorphism and I'm calling out the fact that users are bound to be confused by this, because they will rightly expect that uh you know you serialize using this one gadget. Why can I not serialize it with that other gadget that will be releasing in seven? um And you know, perhaps you know one possible approach here.

C

Is we not call this one thing polymorphism? We call it, you know foo and we name this other thing polymorphism and we direct everyone to that.

G

Yeah, I think you know, honestly, that was a driving factor in the 30 days, for this feature is that I and others were concerned that whatever we did for for just serialization only with no metadata like you have here, the concern was once we add the metadata that it will be confusing and there'll be two sets of knobs and you know can can both be used. um How do you select between them that sort of thing?

G

So I I do appreciate you bringing up that concern, because um we uh we almost need to design both features completely and agree on them before we can ship part of.

G

A

Yeah, I think if you have the round triple one, though I think people could use that for this scenario as well right, it would just mean there might potentially be one more property. That says you know basically either a tag or a kind or a type right, so that you can visualize it back into something saying.

C

Yeah, uh I I would say that it might annoy you know: javascript consumers, perhaps.

B

Well, but I mean this is basically round trippable polymorphic serialization except don't emit the type identifier, so it's! This is a if we do closed polymorphic serialization.

B

Based on that the you absolutely have to do closed deserialization in order to be any sense of safe. um Then then it's special casing, which is, I think, steve harder's. We kind of have to design them together in order to get an actual user experience.

B

So I I see it as a it doesn't have to annoy javascript people aside from if they want json.stringify, which is I don't care, what it is just write it down, and then you know to be frank: they can write that in terms of jason, writer or jason or yeah I mean like they can write it. It's we don't have to provide it for them. We don't provide everything in the.

B

B

Well, that made the room, quiet.

A

Yeah I mean to me, I I I feel, like that's kind of what you said earlier, I think is the is the key part here. Is we should design the system with desertization, I guess in mind and then see where the differences lie.

A

If there are any like to me, the real difference is just you have one more property that has some sort of type identifier associated with it and that to me just means on the javascript side, you have one more property than you maybe were bargaining for, but that to me doesn't strike me as a deal.

C

In some cases, you're changing the the json type of so when you're serializing an array, then you're changing an array into an object that nests the actual payload. So that might be a source of frustration for people that are not deserializing the same payload using system.json.

C

So, but why would we do that.

A

Like why wouldn't the race stay the same.

C

So, if you're, if you're serializing a polymorphic collection type like some a type that is polymorphic but emits json, that is in the shape of adjacent array uh you and- and this is our for what it's worth- that's also our approach in the reference preservation implementation. We are nesting that array into an object that contains the additional metadata that we need. So this is this is not just adding another property. That is certainly true for the case of pocos.

C

But as soon as you go into like more complex scenario, uh arrays uh you, you change the schema of what you're emitting. uh So you know again, if you're round tripping with system tech json happy days, but if you're sending it to some front end, then you know it's probably not what they were asking for.

A

But that's also, maybe something that we can just dial right to me. It seems I mean I understand the difference between, let's say an array that is of type object, array versus string array, but I see I I don't know, I'm I'm skeptical that on the dot net sign you would type something as an object array and then expecting it at runtime to be a string array like that seems fringe to me as well. Like I think, what you're more likely is.

A

You have an array of some base type and then you have like derived types in that array potentially. So that makes sense right, but that you could just say rays are always serialized as a race. There's no polymorphism there and it's just when a movie deserved, if it decelerates exactly into the type that the object has right and that's either. You know in a way type or some sort of collection type, but it's all aesthetically now and then we don't support polymorphism for the collection itself.

C

Yeah, I I wouldn't disagree, but I'm just pointing out that this is already what we're doing with reference preservation. So these are interventions that we're doing to, I guess, uh to accommodate.net.net serialization scenario uh which might leave artifacts for other.

A

Use cases yeah that makes sense. I mean like yeah when you do things like reference preservation, you clearly can't keep the schema 100 the same right, but like uh um yeah, that's interesting thing I mean. Maybe the visualization has a few more switches to make it so that the schemers, basically a backwards, compatible to something that javascript would like right and that might not be as powerful on the net side than for you know.

A

For example, we couldn't do polymorphic collections right and that that might be a reasonable constraint for people um or it might not be right, but we could probably have switches for that. um Oh yeah, it seems to me it's very hard to design just one side. I think it's okay to ship one side if you have a design for the other, but I think I would want to see it decide for both sides.

C

Yeah, uh the design and implementation is ready for both, but I kind of decided to keep them orthogonal because you know fundamentally, they are orthogonal. They might be sharing infrastructure under wraps because fundamentally they're both polymorphism, but uh I I strongly believe that they are catering to different use cases.

C

Now. That being said, there might be some. You know, design, hidden somewhere waiting to be discovered where uh you know you can magically marry both and.

B

Polymorphic deserialization.

C

B

uh So imagine you know you're, just you're saving something to a file and you're loading. It again so you're only talking to yourself. um If you have the closed set of types that you can deserialize as then, it wouldn't make sense to serialize as something outside of that closed set of types in a polymorphic serialization.

B

So that's where the two blend, together of the the way that the read mode works, affects how you would paint things for the right mode and we want the painting to look consistent.

B

Even if you turn off write down the type identifier so that the serialization could work it's if you're in the case, where you're talking to yourself versus the case, where you're talking to somebody doing just javascript.eval or sorry, javascript's, eval or the safe thing, json.parse um that you know that you want it to be comprehensible of how you're indicating this type is doing something other than just static serialization or this member or whatever.

B

D

You may end.

B

Up with you know, properties on the attributes that say how this is participating. It may end up being some some different settings on the serializer, but the the way that you indicate the closed c. The closed polymorphic hierarchy probably should be the same between the two.

C

uh What is certain is that you would probably need different sets of attributes for the metadata emitting serialization brand and the non-metadata emitting serialization brand, and that is because, when you omit metadata, you would need to specify the subtype identifier in the attribute, whereas in the you know the simple polymorphic case you don't.

C

uh So I guess the question is: would we need to um uh shoehorn people into specifying attributes, even if, by virtue of some other knob, we stop admitting these identifiers on the wire or do we need a separate set of attributes that are appropriately named.

A

Yeah, that's an interesting question. I mean to me kind of what jeremy said earlier is the key part, which is the if you deserialize, you probably need to serialize right polymorphism right so then for the people that need to deserialize you, you want to have a set of attributes where, where both sides are symmetric right, that doesn't necessarily mean that people that only want to serialize have a different set of attributes. That seems fine to me, because that's kind of at that point you're more.

A

I guess for you, it's more important to get the output in the shape that you wanted. That makes sense, but that's I'm catering to the javascript guys. So I want to preserve the schema as much as possible and whatever right. So that might be a more advanced thing, but you need more control knobs right, but if you, if you only want to deserialize that presupposes, you are serializing, and then you really want symmetry in the attributes.

A

So you don't accidentally get yourself into a situation where you can civilize something, but that you can't deserialize or the other way around right. So that's that's why? I think for for some subset of these scenarios, I think some you know symmetry is key, but that doesn't mean that you know we have to be 100 symmetric right. It still means there can be scenarios that are outside of that bubble.

B

Right like to take data contract serializer, that would be you know something like the known derived type attribute on the base class and then, if it wanted to support polymorphic serialization, then it also adds a json type identifier, attribute name or something right like and and oh now, it's a read write instead of a write, only.

C

As in an optional parameter in the same attribute.

B

Or a second attribute, so one of them specified the close type hierarchy and another attribute specified the and I'm uh I can be deserialized or something like it. But it's it's right. Only as a subset of read, write and I think from read write you can decide that there's a way to simplify it, to write only, but if we start with right only we may end up with read, write, looking completely different and that feels wrong.

G

C

G

Reason attribute, as you had any other design, couldn't be used for the write-only case. I mean if whether or not you specify you know unknown type identifier you could. If we want to close type system instead of the open system, then that makes sense to reuse the same attribute.

C

I I still feel, though, that we you know are following what data contact serializer is doing. I would prefer if all these things were derived what were defined on the base type rather than opting in into individual derived classes.

C

I understand that the you know it feels to me that the canonical use case would define a schema in one project anyways, and I think we should just be providing an escape hatch fire configuration for anything else.

B

What would that escape hatch be.

C

uh I think, following the.

B

C

Be everything or the dictionary? Well, the kind of dictionary-ish thing that you showed earlier. I guess that guy yeah and for what it's worth uh a similar design exists in the polymorphic digitalization proposal, uh which I have completed by the way. So uh you know, perhaps it might be beneficial if we uh reviewed that as well.

A

So then, is there more feedback that you're looking for to get or it should be just table that and say you know you may want to go back to the drawing board or is there more nuance? No.

C

This this is good feedback. uh The only thing the only thing I'm deducing from this conversation is uh we kind of made the decision last week to uh cut the polymorphic deserialization feature from six because of the substantial amount of refactoring in sort of the course realization implementation that it required so uh merging. I was hoping we could get this done for six, but given that we might need to uh design this in unison, uh we probably need to push everything for seven. At this point,.

A

Makes sense to.

A

G

That we had an offline meeting discussing this previously we did have a set of workarounds people have, and we can certainly share that there's many. um So honestly, I don't think people are totally blocked by not having this feature, but it is a super heavily requested feature.

G

A

I can hear jeremy's typing there. We.

A

B

All right, so I think uh I think that we clearly early landed on is we want closed hierarchy instead of open hierarchy and then once we got into that state, it's we wanted to make sure that deserialization and serialization at least, are capable of looking the same for the I'm sending to myself polymorphically and then from that we could come up with a simpler serialization only which is I'm sending it to javascript, but we don't want to do that. Otherwise we may end up with two different models.

B

So I think these are my two things which we then hit needs work closed. I don't know.

B

um Is there anything.

B

That is worth entering into the minutes here that.

B

um I didn't write down.

A

I mean I'd, be okay with like approving something for sex if you still have time, but I am hesitant to do that without having more of a good understanding of what that means. For the other side that we're not going to ship in sex. So.

C

In order to get to that point, uh we I would probably need to create a prototype that can probably accommodate both. uh You know both features under sort of the revised design uh and I'm kind of feeling we're already a bit too late uh in so so. If this is not going to make preview seven, then I don't think we should be shipping it at all.

A

I would agree with that too yeah I mean we shouldn't rush. It I mean that's, you know the harder part of the civilization so that we're happy with. um I just want to make sure that I don't want to be the party pooper here. I just want to show it but make sure that we we don't ship something that in four months from now we are like. Oh, what do we do to ourselves.

A

Not that this ever happened.

C

B

All right, so I think that covers.

B

This issue yeah, maybe fixed by that's a that's a new one. For me,.

B

You know they acknowledge that bay and b are two different words yeah. I know we shipped it. I lost.

B

All right, um what was your plan for today? Emo.

A

Are we that was the plan for the day, but, like I mean given that we still have some time left, we should definitely look at the other ones. We have.

B

Do we still have people.

A

um I mean steven still seems to be here steven: do you have enough time for the debugger third sure.

B

Well, now it's sad that I updated the stream title all right, all right, so that'll teach me.

E

This is uh this is mostly discussion and then we can decide if we want to do it and if we do, I think the api largely writes itself, um as I think everyone here knows. We for c-sharp 10, we've added new functionality for string interpolation, where string, interpolation isn't just about creating strings.

E

You can write custom builders and you can then use string, interpolation syntax to generate effectively one of those builders, and this allows apis to define uh as an argument to the one to a method, uh one of these builders and then the compiler will generate if someone calls it with string interpolation, the compiler will generate an appropriate sequence of instructions to generate that builder.

E

One of the interesting things.

G

E

This is um the the builder pattern supports conditionality, so um you can have one two arguments to a method- one that's say a boolean and one that is builder, and you can write it such that the builder is given that boolean before it has to evaluate any of the string interpolation holes and if it doesn't like the value it's given, it can effectively choose not to evaluate any of those holes.

E

The compiler generated code basically can generate a branch that says, if some condition, according to the builder, then don't do any further work, because the builder doesn't care about these arguments at all, um and so, for example, if you're writing a logger, you can use this with the logging builder to check, say log level and if the log level isn't of sufficient level to be the level associated with that event, then you can skip evaluating any of the holes associated with that log message rather than having to manually add a guard clause that says if log level is at least blah, then call the log at which point you're evaluating the arguments.

E

um So this is relevant to this discussion, because debug assert is very similar to such a logging method. um You know, debug assert, basically takes a boolean and a string message, um and you know if, if it's very common, to see string interpolation for that message, you know um value blah did not fit between the range blah and blah or something, and you string interpolation for those holes.

E

um Now, generally, we don't care about those costs because well, debug asserts are just for debug typically, um uh but there are variations of this there's trace, assert and then also there are situations where it is so expensive to do the the thing in the uh the in the hole that even in a debug build um you can save yourself some pain by um putting a guard claws, in which case the ability to not even have to specify a guard is interesting.

E

This particular discussion came about because we had one such case uh when I had done some work in system, random, I'd added, a whole bunch of asserts to make sure the right things were happening and one of those holes was being filled in by a floating point value and apparently a floating point values uh two-string in debug builds of correlate is like uber expensive.

E

It was causing problems to the point where we actually added a guard clause around that assert um because it was causing uh miscoral to fall or core live to fall over inject and debug builds.

E

um So the discussion was well should we consider adding overloads to debug assert that are specialized for string interpolation such that only if the assert is going to fire only if the boolean condition is false. Do we want to evaluate the interpolated string, and we could do that if we so chose by writing just as we've done elsewhere, a custom builder, um you can see the the arguments the the builder is defined to take that boolean condition into its constructor and the assert methods.

E

um Take that builder. Exactly thank you and the assert methods. Take a builder as the second argument um saying, or second and third argument. I guess saying that they are past the condition parameter from the assert.

E

So basically the compiler will feed through whatever boolean value is passed as the first argument to the constructor of the second argument, at which point the constructor of the second argument, basically feeds that out to that out, will assert it's a little convoluted, but it works, uh and that will decide whether all the rest of the append depend depend depend methods that the compiler would generate for the interpolation happen or not.

A

So, in other words, the compiler basically would say if the constructor to the interpolated string handler has an out. It's basically always the condition for whether it's basically guarding the all the calls later.

E

That's correct.

A

E

um And you know, obviously the constructor gets to decide what value that out is set to, and in this case, if I just feed through the condition from the input, um so we could do this if we chose to. I think there are two top level decisions to make here and then a whole bunch that follow. If we, if we wanted to add this one is, do we care about debug assert?

E

Do we want to, you know, spend more il in a debug build optimizing for not evaluating, string interpolated holes, um it's a debug build, so we probably don't care about il size, um but it's additional methods here and it's some additional complication etc. um The nice thing is, you know we every place where we do.

E

You know you. Never a search should never fire. So all the work that you do in string, interpolation in the message to an assert is is: should you do it all the time and it should never matter so. This would eliminate that work in a in a debug build um the the more interesting discussion to have- and this is a discussion that one can also have when talking about logging is, we would be taking something that currently always happens, and we would basically be turning it into something that effectively never happens.

E

So if someone had a mutating uh something that some mutation inside one of the holes, you know they did x, plus plus as the hole in the string interpolation previously, that would have run in the debug build, and now it won't. um My.

H

E

H

We're not running.

E

The resource release, but that's correct, um and so my personal opinion is well, if someone's doing that, I'm not kind of okay breaking them uh again only in a debug build, um but it's a discussion worth having. Probably I.

B

Mean I I can definitely say that for private tools that I've written myself, I I think in 16 years of being a net developer, I've switched visual studio to release mode like four times um like if it's a little tool for myself debug is the only build I ever build because it's the default and I don't care um the so the the it's just debug. It doesn't matter.

B

Actually, basically, it's every application or you know, 90 something percent of applications, but our answer for people is: if between.net versions, don't do major version roll forward and test your app before you release it. So I think that if you have mutating.

B

Assert messages you should, you would figure it out quickly. Yeah.

H

Library in a library, you're, never publishing your debug build, or you probably shouldn't be right to nuke it. So it I mean I I guess I don't.

B

Well, for a library it still comes down to, they would have to recompile like if, because, if you write, the dollar quote syntax- and we don't add this or you compile against tfm that doesn't have this, then that gets built as a literal string unconditionally, which is the the work that steve's proposing. We avoid here it's when you recompile against net six that now it would turn this into the conditional statement and not run the string. Concats.

E

That's a key thing I I didn't mention, but the compiler from a from overall resolution perspective, the compiler prefers uh arguments that are builders over arguments that are strings.

E

So when you did, you know we would just recompile, you know uh our build and all of a sudden we're getting the you know we're getting the new behavior that which we'd be adding this exactly because of that right. This would have no value uh if that did weren't the case.

E

Yeah so from my perspective and others can disagree with me, if we think that saving these costs and debug builds is worthwhile, then this seems like a pretty reasonable thing to.

H

Do we've already hit a case right.

E

H

B

Yeah, I so to me it's I can see where there's a risk in breaking it. This is the kind of thing that is very much uh like this. Isn't a runtime break, it's a recompile break, so major version rule forward actually doesn't even affect it.

B

This is a this is a you had to recompile your code and every time you build, you should test, uh especially if you've changed your tfm and the uh so the the people that it would break seem minimal and we do know places that it would be valuable and frankly, the more debug is like released the more you can do sane testing with debug. So I think it's all virtue. It's like when windows did the major effort to get rid of all their tripping asserts, so people could actually try running. Debug builds like to me.

B

This is goodness.

H

I I agree in in general at first I was like: why would we even care? But then, when, when steve said, paul here's an exact case- it's like well other people are going to have those kinds of cases as well like it's kind of annoying that core clr, you can't really use a debug build of it or I can't because as soon as you run tests, they take forever right this. This doesn't solve that, but it gets it's in that vein. Right.

J

H

So I I think we should do it, assuming I think we should at least approve it. Maybe we don't necessarily have to do it in six, but I see no reason why we shouldn't approve this api.

E

I mean the work here is really simple, so if we prove it like it would take, you know a couple hours to get it done.

B

Yeah and then um I was thinking you didn't need to out the bull asserted, uh because the append formatteds could all just end up in literal could just ignore it if the condition was false, but I I agree: outing the bull and making the compiler write the. If means we, we don't even pay the method, entry exit cost so.

E

Well, you, the bool, is required, because if you, if you don't have the bool, then the compliant, you are going to end up executing you're going to end up calling all those append methods, at which point the argument to those methods will have already been evaluated.

H

Right, so if it was a method, call.

E

H

Passed in right.

B

So it would avoid, actually it would avoid the string concats, but it would it would, and it would it.

E

Would run side effect decode right, it would avoid.

B

E

Of a two string, uh but you know if we chose to ignore it, but um it wouldn't have it wouldn't avoid. Whatever code was like required to compute the value passed to these methods.

B

Right, you have, uh I got an identifier, I didn't expect the things I expected were and then open, curly string.join do some other things. It's like exactly. You still called string.join and with this approach you don't so yeah um so definitely for debug assert. It seems good to me. um I don't know what tracea search it does trace. Assert is like debug extern, except not limited to debug.

E

A

It's limited to trace right, uh maybe I believe so and I think trace is defined for release as well. I think that's not that cd is the default configuration.

B

Right, so that one is slightly more interesting now in the side effect and code, because that still ran in release builds and now it wouldn't again, I'm still of the opinion that we, you changed your tfm and rebuilt, like you, should have noticed that your x plus plus didn't happen.

A

I mean that's generally the bar right. I think, if any I mean it's sad if something super subtle on recompile changes without any errors, but I have to say we have done more impactful breaking changes and it was fine. I mean when c-sharp decided to normally capture 4-h variables. For example, I mean sure somebody broke somewhere, but I think it's for the better, and I would say this is in the same vicinity to me.

A

I mean my other question would be like you didn't talk about logging, but didn't logging have the same desire at some point.

E

A

E

We haven't, haven't gotten there yet.

A

B

And then yeah so then, now we move next to the we could's and debug write if and debug write line. If again it, it feels it feels like people who write that kind of don't think about the cost of the the thing that goes after the comma because in their head it is exactly this. It didn't matter unless, unless it was going to do work sorry, unless the condition failed, so it seems.

B

Totally reasonable to me certainly trace assert and debug assert both get to name their internal type, assert interpolated string handler, uh assuming that they can debug right. If is backwards, though right, because that would be if the conditions true do the work.

B

uh If the condition is true, do the work yes uh and assert is if the condition is false, do the work, so it would want a different. It would.

E

Need a different type.

B

We would need a different handler for a right.

E

Line um we could use the exact same one like not, you know we could use the exact same type for debug and trace, um and then it's just a question of you know where we put it. Are we okay with trace, referring to a nested public type inside debug, or would we want to put that type somewhere else?

E

I have no concerns either way: we've yeah, we've hidden it from intellisense. It's you know not meant to be used. Do.

B

We yeah emo, have you seen any proposal as to what this is going to look like in intellisense.

A

Okay, no, I mean it's, I mean my general assumption is like. Unless I mean I mean it's probably not pretty right now, but it's probably also not the worst in the world, and unless these apis are way more mainline, I don't think they will ever do a feature that does something special in the ide, because it's probably not worth it. For the you know, six sides that we use it today right.

E

I think there's going to be some feature. I just don't know what it's going to look like for builders, where intellisense is going to treat them specially. So when you, you know, dot, assert, open, paren you'll see some special syntax. That suggests you can do an interpolated string here, um but I don't know what that's gonna look like exactly.

A

Well, that's why that's kind of what I meant like to me, it's kind of unless we use this in more places. I am skeptical that this makes the bar. I.

B

A

B

Itself be enough that enough people see it that it becomes worth it. So that's.

F

B

uh But that's where the like, if you, if intellisense assuming that you're on the current version of vs etc, if that's not even going to show the type name of the builder, then I would seriously not care if trace was reaching across and accessing an internal type off of debug. Sorry, a nested type off of debug it's.

B

But if, if they're going to show up, then that's where it's like.

B

The struct is small: maybe we just copy and paste it as a nested type to follow our pattern and and shrug.

B

Because the debug one should in a release, build shouldn't appear and it should trim out of the final application, because all the conditional calls would go away so that type usage would go away. The tracer would survive if you call trace.

A

Yeah I mean it sends me a bit that we can't easily share them, but yeah.

B

But I mean this: does I don't remember the pattern, even though we only made it up like a month ago, but I do feel that it was primary method, name interpolated, string handler as a nested type on the type that was going to use it, and so that just means we would copy it. Just because trace and debug are the same thing split across two types. So they end up with the same thing, split across two types.

A

Yeah, I'm funny that way like I wouldn't sleep over. If you used it.

B

All right, so I think we're saying yes and also to all the weak hoods.

A

H

An uber question I have is: do we just do these one at a time, or do we take like a holistic approach to places where people want to put strings in interpolated.

H

Like, for example, event, source right.

H

What like, what's our uber approach to when and where we should introduce these in apis, I mean.

E

I think, unlike span where it was you know, every api might need to take spans. There's a much more limited subset where this is relevant um here, it's either there's some conditionality.

E

So there's you know an efficiency argument related to that or there's some special way. The formatting needs to happen, and so the builder is relevant to that. um There are there's one other place, I'm aware of that we've identified, which is text writer, there's an open issue for that, but even for something like event source, I'm not entirely sure what that would look like, because it's generally strongly typed uh in terms of the the events.

E

If someone someone on it like writes their own custom event source with their own custom logging methods that takes the exact data types they care about, and then it's up to the implementation of that method. What to do and it needs to do to kind of store the data in a fairly strongly typed way as well, and it's usually not doing it as a string.

E

E

I don't know exactly what that would look like um you know I could you could imagine like today. You have you jet. The pattern is generally, if event source, my eventsource.log dot is enabled my eventsource.log dot foo. um I don't know how we'd write a generic build or not an arbitrary builder to use in that foo method. That would check that particular event. Sources is enabled.

E

um Maybe it would we? There is the facility to pass in this as an argument, so maybe we would do it that way and then we'd we wouldn't actually ship any apis for event source, but we would ship a builder that someone could use in their own event source methods um that would sort of do the right thing, um but that probably requires more thought.

E

um I don't know if there are any others to your question about uber we've sort of addressed the main use cases we knew about, and then I think we've sort of been treating it as a as more arise. We can add more um like utf-8 formatter, we sort of said well, we don't know if one would actually care or use it. So, let's wait for feedback.

E

But if there are others you think are useful, we could certainly consider them.

H

Okay, I think you answered, I think you answered my question with the first part, what about it's? Only really when there's a conditionality aspect or a specialized formatting right, so.

E

This place really makes sense the places where we have them so far are we have some overloads of string dot, create that allow you to customize the formatting via an I, um an I-format provider or with some pre-allocated buffer space, and we have one for writing into spans instead of creating strings so again controlling how the formatting happens, and then this is the only other one that we've decided on, and this is the conditionality one. We have an open issue around writer because that's oh.

G

Sorry we have one for.

E

String builder two, which is about formatting directly into the string builder and one for text writer, uh is similar to that. It's you know we have to figure out exactly what it means, but maybe it's emitting a right call for each individual thing or specializing. You know the formatting to do it more efficiently into its internal buffer or something along those lines.

E

Okay, I do think we should. We should strongly look at one for the extensions logging stuff. I think that's a valuable place to do something.

H

Yeah that'll probably be 7-0 time frame.

E

Yeah, that's fine.

H

Do we have an issue on that at all? Do you know.

E

I don't know I mean I was pushing pretty hard for it when we were talking about the source generator stuff, but all the effort got focused on the source, generator stuff.

B

B

Are you long line.

B

All right system, diagnostics, debug, assert, boolean, interpolated and assert boolean interpolated interpolated, with the assert handler uh write if with interpolated and interpolated comma string, because I don't think we care about special formatting category based on the name category.

B

I would assume so yeah um and then take the two rights and make the right lines. These I'll use the right if interpolated string handler and then I copy and pasted this for trace except I removed. The two does not return ifs on the uh asserts, because that I made an assumption, correct assumption. Okay, because so it looks like it's asserts, except they aren't non-returning and then rights and right lines. uh So.

A

Your conditionals are all messed.

B

A

Yeah, the old trace, not the bug on trace.

B

A

I know that it matters, but I guess no, it doesn't matter because it's actually the new type right, add new methods. Yeah.

A

And why does the insert not return, I mean the the assert will fail fast too right, presumably.

B

The assert will the trace won't is what steve said.

A

Oh trace doesn't do anything in the search field.

E

I don't, I honestly don't know what trace assert does. uh I think it just emits uh an assert message to the underlying or a fail message to the underlying um trace listener, but I have to double check. I mean technically. Even debug assert, like the 99.99999 percent case, is that debugger cert um fail fast. If it, if you pass and false it is possible to plug in it to delete all the existing trace listeners and plug in your own. That causes that not to happen, but for the purposes of nullability.

E

You know we basically said it's 100 right.

B

Yeah the default traceless trace listener.fail is just rightline a message. It doesn't also then exit.

C

B

So um all right.

A

Make sense, then,.

A

Jesus, we still have 50 minutes left like be able to do the other one as well.

B

A

Guess nobody's here right, yeah.

B

We don't have people here for that.

B

uh I don't know that we can say that we still have quorum.

A

No, I don't think we can. I just looked at it. I think at this point we just have to say we.

B

Had quorum when.

A

We started that.

B

Issue and everybody who left, I gets uh an implicit abstain, but I don't think we have quorum now. So.

E

No one else cares about. Debug builds.

A

H

Is there any really easy one on here.

B

I mean: is it? Is there any easy one that we think that we only four people is enough to say approved.

E

B

E

B

Analyzers, you think they're easy for us to just give permission.

E

B

Or uh long debates I wasn't implying anything by it. I was just speaking my thoughts aloud. Okay,.

E

You scroll down just a tad.

B

That's the bottom, there object suppose exception. Overload is the bottom.

H

Looks like we get 11 minutes back.

E

H

Yeah all right.

A

Enjoy your lunch, gentlemen,.

B

No, I didn't use.

A

B

To open, but I can use it to close.

A

All right see you next week see ya, enjoy your weekend.

B

Bye, everyone wait there's an order of this. I have to.