.Net Foundation Design Reviews, 17 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitHub Quick Reviews

Description

Issues Discussed:
* dotnet/runtime 57538: Pass interpolated string handlers by ref
https://github.com/dotnet/runtime/issues/57538
* dotnet/runtime 57325: Add BinderOptions.BindSingleElementsToArray flag
https://github.com/dotnet/runtime/issues/57325
* dotnet/runtime 57253: Quaternion.Zero is missing
https://github.com/dotnet/runtime/issues/57253
* dotnet/runtime 57448: X509Certificate2.RawDataMemory
https://github.com/dotnet/runtime/issues/57448
* dotnet/runtime 43934: Consider adding Socket Send/ReceiveAsync overloads that elide SocketFlags argument
https://github.com/dotnet/runtime/issues/43934
* dotnet/runtime 45593: Add .Clear() method to MemoryCache
https://github.com/dotnet/runtime/issues/45593
* dotnet/runtime 47922: Proposal: AppContext.SetData
https://github.com/dotnet/runtime/issues/47922
* dotnet/runtime 50454: Add DiagnosticSource.Write API to assist with trimming
https://github.com/dotnet/runtime/issues/50454
* dotnet/runtime 56082: Make DependencyModel.Dependency readonly and implement IEquatable
https://github.com/dotnet/runtime/issues/56082
* dotnet/runtime 53532: Introduce pause intrinsics in order to support spin wait loop indication
https://github.com/dotnet/runtime/issues/53532

Chapters:
0:00:00 Stream Start
0:02:00 Jeremy tries introducing the stream in German
0:03:06 Pass interpolated string handlers by ref
0:08:16 Add BinderOptions.BindSingleElementsToArray flag
0:46:09 Quaternion.Zero is missing
0:50:04 X509Certificate2.RawDataMemory
1:17:56 Consider adding Socket Send/ReceiveAsync overloads that elide SocketFlags argument
1:28:23 Add .Clear() method to MemoryCache
1:37:35 Proposal: AppContext.SetData
1:42:03 Add DiagnosticSource.Write API to assist with trimming
1:54:09 Make DependencyModel.Dependency readonly and implement IEquatable
1:55:46 Introduce pause intrinsics in order to support spin wait loop indication

A

A

Hello friend, uh they'll, come in on api review uh s ist miner. Let's uh api review versus vyvacan um veer, albin zvay wrote issuing um off gates all right. That was my bad attempt at german.

B

Are you going to hold up scorecards? You know right right, his uh rate, his attempt.

C

I understood what he said, I'm not sure about you guys, but.

A

I think we got the content, I'm sure I ruined most of my prepositions, because german prepositions don't map one to one to english, but um right so uh we have some red issues for things. People are hoping to get into today. I think in the next two hours and uh yeah.

A

This will be my last review for two weeks because I'm actually going to take a vacation and actually actually go somewhere on a vacation, so uh yeah that'll be fun, which is why I keep practicing my german uh other order and we had an urgent request for a very short thing. So pass all interpolated string handlers by ref, five, seven, five, three eight!

A

Do you wanna talk steve, or should we just give it a thumbs up? uh We can do both.

D

um uh This should be knock on wood very fast, um so we've got a bunch of handlers that we previously approved, um and you know they they're all. There are methods that accept those handlers, arguments for all of them, except for the ones on debug.

D

We pass them by ref and for some reason, when I submitted the issue for debug, I didn't pass them by ref, um but I think we should basically have our handlers always be passed by ref, because it gives us well the variety of reasons uh one and this might be a little counterintuitive. I think it makes a little bit harder to accidentally use directly. We really want people calling these methods with interpolated strings and having them be ref makes it even more of a like.

D

What is this thing if you were calling it directly, um but the more important reason is um well two important reasons: one in general, these things end up being larger structs, it's better for perf to pass them by ref rather than by value, and the reason I actually care about it is um if we want to do any kind of clean up inside the handler as part of whatever the operation the method performs is.

D

Ideally it's done on the copy that was in the calling frame as well, and so passing it by ref allows us to clean clean up the one thing.

D

So uh I would like to just change the methods on debug to pass them by ref. This is a breaking change from these apis that we shipped in for the first time in preview seven. So it's a preview, seven to rc1 change,.

C

Yeah, that seems fine, I mean. Presumably the compiler will still call it right with this, with the syntax.

D

No difference if you're using interpolated strings, there's zero impact on the on the syntax. You write, I would only like I had to change our tests because our tests call the methods directly, so I had to add ref in front of the things but right for you. We don't expect anyone ever to call these methods with the handler directly.

C

Makes sense so it's basically the binaries won't work, but the source code will recompile just cleanly yeah yeah. That makes sense. I mean I.

B

And and I think steve, you actually found an opportunity to do some cleanup in this code after you started taking it by ref right. Wasn't that the string builder change you made.

D

B

D

Debug.Writeif we we're just always out so debug assert, like the handler is only ever used if the assert is about to fail um and so like we don't care about cost when it's about to fail, because we're about to crash anyway.

D

um Someone raised the issue in an issue that well what about debug right, if, like you know that maybe you're you're using that in case where you do care about cost, and so it's a one or two line change to change it to use string builder cache, instead of creating a new string builder each time.

D

But then we need to return it to the cache and to return to the cache you really want to, like you know, return it and then zero out the state and the handler, which makes passing it by ref much more um desirable.

A

And basically we're wanting class semantics, but without waking up the gc exactly.

D

All right, the only downside and I'll mention it just for completeness and it's the exa and the same downside exists other places as well. So this is just being consistent with those other places. Is you know if you have an overload? That would also be if someone were calling this directly with the type.

D

um There is another overload on debug.rightif that accepts object, state, and so, if you don't say ref before the argument, it'll bind to the one that takes the object state uh rather than the one that takes the ref handler um you'll immediately find out, because you'll get output that makes no sense. You'll basically get the type name output as your string, and we don't expect anyone to be using these things directly anyway. But that's the only downside I can think of for this.

C

That seems fine.

A

C

I mean the six people that will call the api by hand, as you said, that we'll find out very quickly yeah.

D

As I did when I forgot to change one line of our tests.

A

And probably at least four of those six people haven't done it yet against preview. Seven. So.

A

Okay, so thank you. Thank you, steve. Thank you for noticing it um now.

C

As opposed to after shipping.

A

The later it gets the harder it is to fix yeah after shipping, it's not impossible to fix all right, get back to streaming. Zoom all right, add binder options, bind single element to array, flag, 57325.

E

All right so for this one, uh what we have is you wanted to basically add a api to the binder option. What a bad add a flag to the binder options, and the reason being is that if you compare the two samples there, one that that is a json sample and then another one in the middle, which is a xml sample.

E

If we wanted to bind let's say the json one, there is a way that we can say that the metadata can be an array, but for the xml we can't- and um we have a partner request for having this api ship be added for six, so and then they're also in the meeting today as well, and so what we're gonna do for this is, if you scroll a little bit further down you'll see, we have we're going to add, bind single elements to array which, when it's true, it will treat the metadata as an array.

C

F

E

F

C

Not just make this work, I mean it's not a breaking change in the sense that we would buy into something that and because we would basically buy something it wouldn't have bound before right. We would make an error case. Work.

E

So you asked why, wouldn't we do make it a a breaking change.

C

No, I mean I'm saying like in the xml case right you, as you said, like there's, no way syntactically, you know insanely, I would say to just to differentiate between one or multiple, but we know when we are binding, that we are binding to something that is typed in array right. So why couldn't we just make this work.

E

um Let me think.

C

Because, normally like our buffer breaking changes is when we make something work that didn't used to work. We don't think of this as a breaking chain.

G

Okay, the reason this is a breaking change is uh this is not a breaking change, for example, as you might think, but it is a breaking change for json, where objects that were not bound before will be able to start binding from now. So uh think of this right, we have multiple.

G

The idea is that a single element can bound to mult uh an array originally in json you can actually express or errors, but with this change, even when in a if it can, if a json contains a object itself now, that will also be bound to be erased. It is a change in behavior. In that sense, could we get used to the.

H

H

You should ask your question first, I.

B

I was, I was asking, did the scenario? Are we taking a scenario that used to fail and make it work, or are we taking a scenario that used to return a and we're now making it return b.

G

uh Okay, this originally used to written null most of the time, so it fails to bind most of the past and we are now enabling it actually start returning actual values, uh also yeah. It is a somewhat breaking in the sense that uh there are options where you actually can throw exceptions. Now that would be a conflicting behavior like uh do you want to throw an exception when it is an array or not area right.

B

You have to yeah yeah, because normally the bar that historically has been used for breaking changes is if a scenario used to flat out fail, like throw an exception and we're now making it work. Normally, that would not be considered breaking and would not normally it would not require any new api for configuration, but it sounds like you're saying um people may have taken a dependency on the behavior that it returned null, which is not a failure. It's an actual return value that is correct. Okay,.

C

B

I guess it depends.

I

C

Definition of fail right, basically you're saying in the past, you would bind it as now, even though there were elements, and now we would bind it to whatever the list is right.

H

Yeah, I would be really interested to see someone trying to rely on that, um but a question is since there is an explicit syntax for arrays with json and not for xml like could we change just the xml provider to have this new behavior by default?.

G

Unfortunately, not because at xml provider level right, you do not know what the target type is. Like you don't know. If you're trying to bind to an array or an object in the example provider itself, it only comes when you're trying to bind yeah. That's the point. So until you start doing reflection on the binder, we don't know that data, so it has to be in the binder.

C

G

C

Is basically invariant to the syntax? Is that what you're saying so there's an interaction between the representation and the xml and the actual binder? Yes, so the.

E

C

Whether it comes from xml or json,.

G

Yes, binder doesn't combine the works on the dictionary pretty much.

H

I see right so the provider just gives you the dictionary. So what this means is that if you set this option that, if you do supply an array um that or sorry if you do expect a single value instead of an array that would just stop binding.

G

uh It will okay, so if the flag is set to true- and you provide a single uh element in place, where you need an array, it will work. uh That's the that's the addition of the binding we are doing so we'll.

H

G

Any single element into areas.

H

My question is: if tv showed uh being an array of metadata, it was a single metadata.

H

Oh yeah, it won't bind anymore even if it's a single metadata like in the json, even if there's no array of the json, even if it like matches up nicely.

G

Yeah, if it matches directly, it will bind. So if there is one tv show uh as a single object and you provide it a single object in json, it should bind right.

H

That's the question, so the provider will provide a single element array right and then, when binding to the type, will then remap that single element array to the single value.

H

So so, basically, in this api you set bind single elements to ray to true, but in tv show you have a non-array metadata.

H

Is there any way to bind to the non-array metadata.

G

uh Yes, you can just have a metadata, which is not an array right. You can just have the standard metadata object, which is not an array.

E

uh If I'm understanding the question correctly, um you can, can we scroll up a little bit to the message to the in the description in the description of the message so in the metadata over there? uh Are you asking if like when we set the flag to true?

E

Is it going to make sure like that metadata is an array, but not tv show?

E

Is you mean the differentiation between metadata and tv show, or that's not the question, because my understanding is that it when, when the flag is true and correct me if I'm wrong when the flag is true, any any uh item in the xml that has a name attribute will end up becoming an array. Is that true, uh no.

G

The name attribute behavior has been changed as far as I remember, so uh it will. The idea is that everything, okay uh after this change, if we set it to true the idea, is everything every element can be considered in every that's the behavioral change we are making, but by default it will try to match everything to the strong object, as is if it fails to bind an array directly or sorry as a direct object. It will then check if it is an array and try to bind to an array.

G

So in this example, if you see the tv show metadata error right uh today, if there is no metadata and if there is just only a metadata, so public metadata metadata uh the below example, we should just work because it's one tv show and it contains one metadata.

G

But if you put that metadata array, as you see in this picture, the example below will fail, because uh it is uh deserialized today into a single object under tv show, saying like it is just a metadata object and the binder will try to bind to another which.

H

G

H

Thanks that cleared up my question.

C

I mean I'm not, I mean the scenario makes sense to me. The only thing I don't like is this flag and the reason I don't like the flag is that it basically over time. It means that the complexity of these things grows and grows and grows, and I have a hard time constructing an example where somebody would actually be broken by this I mean yes, you can imagine that people are broken by this, but it seems also reasonable to say you know we invert the behavior of the flag right.

C

We basically say by default, it's on and then only if you're broken, you have to turn it off right. Like I mean it seems generally desirable to have that just work right.

G

That is correct, so if you see at the bottom of the proposal the default proposed used to be true, we are enabling this behavior by default.

G

There might be cases, whereas we said like people are actually expecting it to fail, so they can.

J

G

Opt out, but by default we will enable this behavior. At least that is the proposal we have.

C

I see so the api usage would basically be you wouldn't have to do that as that particular assignment.

G

Yes, the default will be set to true. It can bind objects to address by default. If people see that it's breaking them, they can always change it to false.

C

That makes sense, I think I could live with that. I don't know what what the other thing.

A

I mean the only scenario that I can think of that someone would be uh broken. Broken would be they're loading or they're they're already reading a config file that has an a value that the setter was going to throw on that currently wasn't binding, and so that now it ends up manifesting and now they hit the throw when loading the config when they previously were. It was getting skipped so yeah to me. It feels like maybe just change the behavior, but an opt-out is, I guess, okay,.

C

I mean you could imagine that somebody happens to depend on the property being null right or being basically not initialized right. It doesn't even have to thought it would just be you make a decision based on this being null and no longer it's no longer. Now now it's set to whatever the signal ends up being in the configuration file right and yeah. If you've never tested that configuration, I can see how things.

E

Might go south.

C

Yeah to me is this would not be in place update, safe right. We wouldn't do this on.net framework right, but in in core it seems well, you pull the new version of the package or you upgraded, the you know your tfm and then yeah. That's the kind of changes that I think we would be. Okay with saying you have to absorb that because it seems 99 people wouldn't be.

C

You know negatively impacted by that, at least that's what it feels like.

A

There's a question from chat that asks. uh Basically, why don't we change the xml schema to have the metadata say: metadata is array equal, true.

C

Because it's ugliest yes,.

A

um Yeah, so I I think I agree with emo's having the option to turn. It off seems reasonable, but it should be on by default, just because it it feels like it's. The natural flow.

C

And it's a bit unfortunate that we can't isolate it to the provider because I would say in jason I would be okay with saying. Well, you have to put the brackets if you really wanted an array, but in an xml it just seems you would have to have some container element around it. It just becomes really ugly and- and so like. I think. Ideally, we would just only do it for xml and then say for jason. Well, sorry, you have to put the brackets.

C

That seems a bit more desirable, but I understand if we can't do that, because there's like a layer of interaction in between then so be it.

A

Yep, unless the layer of indirection allowed the different file formats to return a, I found a single object. Do with that. What you will, in which case, then it could only map differently from the xml but yeah. So I do. I guess I will question whether this needs to be api or if the risk of breaking someone is small enough, that it should be app context.

C

Well, that's, I guess fair.

C

I mean my only concern: is that it's very late, so we don't really know how impactful that is. So, if, if what I said earlier is true, it basically pretty much affects nobody, then an app context, which is probably okay. The problem with an app context switch, though, is how does how does the nuget package read that if I'm running on you know know.net core 5.0 with the new version of the package.

A

My understanding is in core the only way that you can get an app context switch is, if you directly call appcontext.set switch in main, so.

C

But it's just a key value pair right, so the library can read it, no matter which, which framework version you're running on right. So we could use the same thing when you're running on dot net 5, with the newer version of the package right yep.

G

Also one one point which I want to raise there right if we want to put this in app context, uh how like, because this new gate packages are targeting standard too, so pretty much people who are using framework can also use them.

G

uh Will that still work on dotnet framework? All the app context features.

A

App context is just a special dictionary of string to boolean um on.net framework. It has support from reading values out of the registry or out of app or the xeconfig on.net, as well as somebody directly calling appcontext.setswitch on.net core, you can only use the api method of control.

A

Okay, thank you.

C

Yeah but app context is itself net standard too. So it's I think in a framework inbox since four six, if I, if my data is correct here, so it's.

E

Yeah one thing I don't know is that with other flags with binder options like there's precedence of having like of other flags and binder options, to kind of change the defaults, but then for this one to kind of suddenly use app context, switch.

C

Well yeah: this is this: is the thing right it's it's kind of like a tasting more than anything, but if, if we believe there is legitimate cases where you want to have it on and off, then I think it belongs uh onto this api right. But if we believe that it's literally just a you know a way to opt out of behavior for some weird corner case, then it doesn't seem it's a desirable thing to carry around right.

C

So it's kind of more like the do you think of this as a compact quirk, or do you think of this as oh, some people want behavior, x and people on behavior. Why, and the way you describe it to me, sounds more like it's a compact quirk where, if you would have shipped this behavior, you know from you know v1 we would have just had only that behavior and nothing else.

C

If that makes sense right and- and I mean you're right- the binding on public properties that one, I would say, is more like you know, in the air of the beholder whether you want that or not everyone unknown configuration. I guess is similar, so I can see the argument being made for those two at least to be options, but this one seems more like well. We really want this to be the default for everybody, except when it really doesn't work for you.

A

Yeah, the the test for me is assume we put this as true by default. um Would you be surprised if you ever saw someone set it to false? If yes, then make it an app context, switch.

C

I mean the only other argument in favor of having an api. Is you can't scope it right per instantiation of the of the bind? Whether this is? If you make it an app context, switch it's for the app all on all off right, which might be a bit too big of a hammer. Maybe.

A

Maybe I don't know how many configs get loaded in a universe.

C

I guess that's fair for them for most apps, it's just you know you do the one pass with asp.net and the in the startup and then call it good.

G

Also again, I want to raise away maybe a weird corner case. I want to see what you guys think about it right. Let's.

I

G

Some app uses both json and xml, but uh only their example is affected and the json they still depend on this null behavior.

G

uh So this type of thing, it is very straightforward, solvable by the api, but I don't think you can actually solve this type of scenario. Using a app context, switch right.

G

They can use buying two different binders for both of these two cases, but if it's in the same app, but if both of them are in the same app, it can't be using app context, switches right.

A

So that that comes back to the when does like are people regularly calling bind more than once if bind is 99 of the time called at most once in a process, then app context is totally fine. If the average process does like 38 of them, then then maybe you need it on a per bind. Call.

C

Well, I think the the the problem that he was pointing out was less about the number of calls, because you can have still one bind uh but, like you have you know, multiple providers like one of an xml for one adjacent file and whatever right, and so they they're all part of the same configuration system now and so they're like logically a single bind. But then you want the behavior for half the providers right and you know neither the api nor the app context which will solve that and my answer to that would be well.

C

You know you're you're in the code. At that point, you have to change your code like you need to change your your configuration system such that you don't depend on the xml behavior right, because.

A

You can't have.

C

Half of the behavior and not the other half.

A

There's a level here of you know: you've you've had this bad value, written in your config for a long time and you basically never tested changing it, and now it's being read and yeah, don't don't write things you don't actually test like.

C

I guess that's true, I think the easiest fix would be you just change your configuration to actually wow. That would.

G

Be the way to fix it. I was just trying to see what scenarios might fail in this, but yeah.

C

Yeah the way I mean the way we generally think about breaking changes for core course. We basically said like okay, we, we are okay with breaking changes if it's for the greater good and the greater good is usually defined, as you know, less complexity, moving forward and more more intuitive behavior by default right, then, the question is okay. If somebody is impacted by that change like how would that manifest itself like is? Is it easy to diagnose if it is easy to diagnose okay? How much? How much churn does it impact me?

C

Is it a one-line change, or do I have to rewrite my app right so, like it's all these degrees- and I think in this case it would be it's easy to diagnose it's relatively straightforward to fix, and uh so that seems making the bar right versus the problem with dotnet framework. Is you you test your app? You deploy your app, then somebody upgrades the framework and suddenly your app stops working but you're no longer. You know you're no longer on the machine right.

C

So that's the kind of thing why on.net family that wouldn't be acceptable versus in quarter scenarios where you upgraded your package or you upgraded to tfm, but in either case you're literally editing your application right now.

C

So if stuff doesn't work right now, that's fine, because you're clearly, indeed you're clear the ability to fix it right and that's kind of why those changes are okay, on.net framework, we still don't want to make changes where oh, you know we renamed the namespace and now like nothing, works anymore, and it takes you like three days to get to a compiled state. Again, you know yes, even though that's a breaking change, it would be too impactful for us to do right. So that's why it kind of depends on how how it manifests itself.

C

The other thing is just behavior right like if the behavior is super hard to diagnose, because it's some threading api, where you change some cell behavior and suddenly you have deadlocks yeah, that's also not great, because yeah, it's a breaking change, but it's very hard to test it's very hard to diagnose when you get hit by that, and so you try to avoid that too and excellent.

C

All right so then seems like we're pretty much okay with even the api. I guess I mean I don't have strong opinions. I can live with the app context switch. I can also live with the property, given that it allows for more scoping for some people. um I would just make sure the default is true.

A

Yes, yeah, if we think we need the option to be public api, then as long as the default's. True I'm in agreement, my personal preference is no api here and just do it as app context and then delete it in the next version, because app context, switches shouldn't exist for more than one version.

A

That's basically what it means. When you decide, you want an app context switches. This is compat, we're fixing it we're moving on.

C

Yeah the problem, I think this is why I think app context switches work better for the stack they work less for libraries, because it's like well for dot net platform versions. You can, I guess.

J

C

Version for a package is a bit hard like what's the next version, that's.

A

True, the the the the oobs may uh may be different.

C

So maybe it's just easy. I mean the other problem, webcontext switches, they're, not really discoverable right. The only way you discover them is by reading the release notes of the stack which, again, if you're, using a newborn.net framework, you're, not reading the.net, seven release, notes right, like that's.

A

No, but if we to make the behavior true by default, you're also not gonna, go look. Look at it.

C

Right but then again, if at least stuff stops working, I mean you kind of assume. Well, maybe I have to call different api or something right.

A

They're both the same something went wrong now, you're looking for a solution and one solution tells you go edit. Your call to bind to pass in bind single element to array equal, false and another one tells you go, call appcontext.set switch. I.

C

Guess that's true, like once you're in the I have to discover it, it's entirely reactive, so yeah yeah. I guess I'm fine either way, so I kind of leave it to the rest of the room to make to make up your mind.

E

In theory, one one more question: if, if we use the app context switch and then uh folks were uh like, there was feedback about keeping this, then on the next release, we could theoretically just add the add this api and then not use that context switch. That's also possible yeah.

A

You can also um leave it for longer than one version, because oobs are yeah complicated.

C

Yeah I mean normally, I would say if this would be early and six, I would probably start with an app competition switch and then see how many people actually complain and if, if it's enough, maybe it warrants an api, um but it's a bit late for that, so I mean we could still say yeah depending on feedback. You may add it later as an api. That's also doable.

C

I think to me practically speaking in app context. Switch is not super cheap either because you have to document it. So I mean once we have it. I'd be really likely to add an api, probably not because we would say like just set the switch and then worst get the switch takes around for longer right, um yeah, but.

D

C

You make a decision today to go with the switch. I just don't think we would add the api to.

A

Me it's app context, which is some notion of temporary and api is forever.

C

A

C

A

Back to how like is this corner case, or is this mainline functionality that somebody would want to toggle.

C

It to me the api, isn't really the thing that concerns me. It was more like the or no we ask everybody that calls vine to pass this thing and that's true right. That was the thing that could that would concern me but like if there's a boolean that you that you could decide to set to fall if you really wanted to, but most people wouldn't, I think the cost of the api is fairly low. Yep.

E

And I just wanted to reiterate uh to make sure the breaking change we're looking at is when we have an xml, a configuration and today, if we wanted to like, we would get a null a value for if we wanted to have bind to an array. But when we set it to true, then we can get properly the data in uh bind it in, but for json there is no breaking change or you also have a breaking change for json.

G

uh Yeah, it doesn't right it's quite hard to define the breaking change in here, but again yeah. It is a breaking change like let's say in the same example right. If the json contains only one element or without the array object, it can still bind to the error in this case, so it is a breaking change in that sense. Logically, it makes sense uh because errors uh one object to erase is, can they can bind. So it's actually not an issue but yeah just pointing. I already pointed this out pretty much the same. Okay.

C

Yeah, I think the behavior is basically what it says by the basis says whenever you bind something that is a single into an array setting this property to true will now make it succeed and that's agnostic to what the provider was it would work for. Xml would work for json, it wouldn't work for anything else. There'd be probably also environment variables. I don't know what they oh they work with erase, but like that's, basically the behavior, where you would be getting so.

E

If we're fine with json having that behavior, then maybe the app context which I'm I'm fine with that too.

C

Yeah I mean we are sorting this for the most part that we are fine with that right. I think it's kind of the we ship it and then we see what happens right, but I yeah.

A

Mr earhart, do you have an opinion.

F

I mean at first I wouldn't vote for the app context, switch and then miriam kind of convinced me when she was kind of sad if we put in the app context switch and we get enough feedback that we need the api. We can add the api later.

F

So now, I'm more closer to the fence.

F

I I the reason I don't like app context. Switches from the beginning is kind of what emo said: it's not discoverable, but also it just. It feels too much like a hack right like if you want to have differing behavior and you already have an options class. Why? Wouldn't you just put it in the options class to be able to define which option you want to which behavior you want? So that's why I always kind of lean away from app context, switches.

F

F

I'm closer to, I think, I think, at the end now I'm kind of like yeah it. It would probably be fine to put this behind an app contact, switch it in the off chance that it does break somebody.

H

All right, the reason why I'm okay, with an app context, which is I'm almost okay and not having the option at all, like for all the reasons listed, yeah like.

C

Yeah, I think, that's generally the way we should see this you, you should basically say if we, okay with an app context, switch. We basically have to say: oh that's only needed by like less than a percent of people right. If it's needed by more people, then we screwed up right.

C

It is really just the to cover our asses in the in the long tail kind of situation.

G

Exactly also, I have this quick question for you guys. How do we even discover app context, switches.

C

There's a they have how they release not so they're actually documented. I think, there's a centralized list somewhere. I believe um and then yeah that's why I said it's a bit harder to reason about them in the corners of a library right, because, as far as the system is concerned, it's just a process by dictionary that you can only set once right. So so, realistically, you know any library could ask for a random string in there right. So that's why it works.

C

Also for this library, which is a new get package which happens to work everywhere, but then also we ship this new get package in a particular version where the dot net stack so normally the way we document these is basically saying. Oh, we know the new version of the dot net stack is our let's say: don't n6 or dot n7, and then we document here the new compact switches that we added, because we believe it might impact somebody right and that's how you would normally find them for libraries, it's a bit more on the well.

C

You know each libraries has their own notion of release, notes or shipping schedule right and that that might be different for those but yeah it's a basic documentation. That's the query.

F

It's basically internet search. It's the only yeah.

C

Yeah, basically, it's stack overflow right.

G

Yes, it looks like only stack overflow because I was trying to search for a list of switches some place, but it's very hard for me to get anything uh but also like. I always have a quick. I have a quick feedback as well right. uh We have an options right there. Why don't? We just use options and if you really need it like, if because we.

J

Already have the.

G

Deprecated attribute that says, say we'll, be deprecating. This next release, whatever.

C

Yeah, so the the general reason for that is so the way app, compats context switches work for us is they are meant to be temporarily right, so they are basically meant to say. Okay, we we introduce a new behavior, we're generally okay with the with the new behavior. We assume most people are not impacted negatively by this new behavior, but we give people an escape hatch so that if they want to upgrade to the new version, they can just get the old behavior back easily.

C

But then, in the long run, the new behavior is going to be the land of the the law of the land, so the app compact switch will eventually disappear. Apis can't disappear. So if we, if we add an api, we have to support this behavior and basically both most of this behavior forever right. That's kind of the trade-off which you can argue in this case.

C

It's just a simple if statement, so maybe the supporting bulb is not a big deal which I'm okay with, but, generally speaking, the idea of an app context switch is we can eventually, you know, delete the old behavior entirely from the product thanks.

F

The place where an api would help here is really like you're consuming two libraries that have their own config sections and those two libraries are using bind to get their to get their configuration and one of them one of them wants this behavior, and one of them doesn't right like turning the app context switch to either one is going to break one or the other.

F

Right, that's like the real risk we run by having a process-wide switch here.

A

But I mean the real fix in that case. Is you fix your config like the the process, the the switch, because the switch is really we had a behavior in the hold on 5.0 version of the package?

A

You now upgrade to the 6o version of the package for some reason, um and then now things are behaving differently, so the app that's hosting it says this one thing that changed: that's invisible, turn it off now they're working again.

A

Now they really what they really have is a bug, go fix your config and then now they can turn the switch back off and then, when they get the version eight of the package assuming or the versions in of the package, assuming that we remove the um the thing they'll keep working that that so yeah the app context is really if it's a behavior that we would have been okay, just changing, but we're afraid. There's like a one percent chance that somebody can't react to it correctly. Then it's it's just an escape patch, very temporarily!

A

That's the idea. Oobs are weird, so maybe we would do a weird thing in a noob, but.

F

The change here is, I had a class previously, I had a class with an array inside of it when I would bind that to a json object, a json file that didn't say that option is an array. It just had it like an object previously in my class after I do bind that array would be null, and now the array is no longer null.

F

It's set to a new array with one element in it. So.

A

The fix is delete the line of config that goes back to the state you were in where you had a line of config that didn't matter so delete it.

F

It didn't matter to this object, but maybe it matters to somebody else. Reading the exact same data, maybe.

A

F

A

F

It's almost getting to the point where it's like: do we add a switch at all, and do we just make this behavior, like kind of what stefan was saying, if we really think this is the right behavior.

A

Like personally, I'm fine with that, which is why I'm moving or why, I think app context is an okay compromise, but I can jam a little harder on. No api is needed, just make the breaking change.

G

Yes, what is stopping people from using the older version of this package.

A

Transitive dependencies.

F

Right they don't.

H

Get to pick it, ships with asp.net as well.

A

um Yeah, but that's that they intentionally upgraded the only people that we really.

H

A

Care about is people using this from an application that they got upgraded to the next major without upgrading their platform.

A

That's the real risk, so transitive dependencies.

F

Well, and you can't, if you want to upgrade to.net six, you can't use the old version of this package if you're an asp.net app.

A

Right but I assume.

F

A

History that you've you're already facing 700 major breaking changes that'll take like eight months to solve uh fixing the line of control is uh shots fired, not a problem version two to.

H

Three was harshly absolutely improved guys. I understand. There's some history there, that was a really harsh upgrade net. Six will be much easier. People.

F

Okay, I I say: let's do the app context, switch and move on and we'll get if this is really breaking people and they needed the api. We'll get feedback yeah we'll do that in seven plus.

A

This is ub, I think, technically, we could add the api in the dot version. Just we don't, but I think we could, because it's not baked into a targeting pack.

F

It is an asp.net.

A

If you get the higher version, that'll that'll win out so you'll it'll pull in the package version. Instead of the platform version.

A

At least that's how the system's supposed to work because asp.net you asp.net 5, you could reference the 6o version of the package and you should see the new api.

F

It does the problem, then is then it's not cross-chained, but it's not like. This is a big assembly, so yeah.

I

G

Switch off, I think you meant.

A

A

We feel the behavior isn't something people really want to switch on or off. This is just compatibility across an upgrade boundary either just make the breaking change or use an app context. Switch to provide temporary access to previous behavior api can be added if we're proven wrong.

A

I think that's our summary, I think so as well so app context or rip off the band-aid. Your guy's choice.

E

um Did you close the issue.

E

C

E

C

How you see the issue- I guess, if you just say, there's still an issue tracking that behavior needs to change, then maybe closing is not the best way of doing it.

E

Okay, thank you. Thanks.

H

A

H

Reopen it and change the tag right.

A

Yeah, please wait till afternoon: okay, unless you're planning on fixing it before the snap, in which case just make a new issue for your behavior, um but emo's tool will track the. It went from api ready for review to closed. As we said, no.

E

A

All right quaternion.0 is missing. 57253.

J

uh So, basically on vector, 4, 2, 3 and several of the other types, we have a zero property explicitly for getting uh the zero concept because it can be more efficiently, intrinsified, etc.

J

The proposal here is to also explode, expose it on quaternion, since it is functionally similar to a vector four, um and it can likewise be optimized.

A

A

It has the mathematical zeroness that someone's expecting with zero. Yes,.

B

A

B

Api proposal here lists uh list quaternion as a class. It's actually a struct, so calling new will return. Basically defaulted, t yeah, yeah.

C

So should this be a field because everything else is a field on this type.

J

No, this is a. This is similar to the vector4 property. On the other types.

J

And we cannot intrinsify fields.

C

A

And is for these, generic math was zeroness defined as a.

J

Property, we have additive identity, we do not have a direct zero concept. Okay,.

D

Yeah, the main thing here was for like helping to check that it was uninitialized right because by default you all the values are zero, so like the is. Identity is probably more useful from the math context, but from the concept of like hey, has anything being done to this quadrant. Do I have something other than a default value from you know, declaring it as a property somewhere.

D

You know there wasn't the same sort of properties. You have with the vector classes to check that state of like this was just a nude up value that I know that it's equal to zero or something is to have those kind of same programming patterns.

A

All right and static properties don't need a read. Only.

A

Yeah, I don't think that makes sense.

J

Rotate instant state yeah all right.

A

C

Nope, only apis of the net doesn't render static.

C

Four properties, apparently because they all show up as instant properties that really confuse me.

A

If only you knew the guy who wrote it.

C

Yeah I'll definitely have a chat with this fill out later.

A

X509 certificate, two dot raw data memory; five 57448, mr jones, welcome.

D

Hello, am I allowed to talk.

A

D

Sure, okay, um so uh currently on x-509 certificate ii, we have a property called uh raw data, it returns a bite array because arrays are mutable, it returns a clone every single time, um and you know these, you know binaries are going to be several hundred bytes to a kilobyte in size. So the idea is to expose a new property um that returns some sort of immutable representation of the raw data that wouldn't require us cloning it every time we give it out.

B

So when we've done this internally for properties that we haven't exposed like on system text, encoding and so on, we've actually exposed it as a span instead of a memory, and the reason for that is we just assume that a span is easier to use because it is kind of a first-class citizen, and memory is a weird construct kind of built on top of that, and um if you want a copy of it, you just call to array and look now.

B

You have your own standalone copy array and you don't have to worry about lifetime management stuff.

D

Yeah and the proposal actually started off as a span, um but there's some discussion further down that you know. Read-Only memory does have some good properties to it like you can use it in async contexts and.

I

D

It's you know a little bit more future proof. If we need to be able to say accept, you know incoming data as a uh memory as well. um I think both would work and, to be perfectly honest, I don't have an opinion either way um I'll defer to the experts on which representation is best.

A

Yeah, the in the discussion- it was you know the the two things that stand out as if we return it as memory, it's still non-copying, but if we return it to span require a copy, our stream.write async, and if you wanted to take the certificate raw data and run it through asn reader to read it to you know, walk the payload manually. Asn reader takes a memory because it holds a reference to the to the data, and so it's was looking at this. From the perspective of you know, we have.

A

The parameters should be the weakest type. They can, but return type should be the strongest type they can and we can return a memory from a memory. You can get a span, but if we return a span, then there's nothing. You can do short of my evil pointer memory manager to get a memory back.

B

So, if we're returning to memory, the memory absolutely categorically has to be backed by a byte array correct. We can't ever back it with anything else, because now you have ownership problems again, correct or lifetime problems. Correct.

A

And then steve, uh I don't think he's come back yet yeah steve pointed out that, well once we do that now somebody could call memory marshall, try get array and unpack the array, and now they have a mutable reference to it.

B

Which is fine like if you're, if you're dropping down to unsafe code, like god, help you I'm not interested in in preventing you from shooting yourself.

A

um Yeah we could, if we wanted to add a put a memory manager between the array and that that simply returns false from try get array yeah, I'm yeah, I'm not interested in doing clever.

B

Stuff, like that.

A

Right and that's a that's a one percent accidental I I accidentally had an array for compat reasons and then was like. Oh, I have an array here.

B

A

B

Guess what I'm, what I'm kind of having heartache with is memory is at its core supposed to be an abstraction. It's supposed to be something where you don't necessarily know what's backing it. But in order for this api to work, we absolutely have to back it with a byte array, which means that people are going to take a dependency on that behavior. And at that point, why not just have an api that exposes a non-copy byte array, yeah.

A

B

A

Then, just like.

B

Be responsible with it.

A

What's our layering for system collections, immutable.

C

What do you mean.

A

Is immutable part of shared framework.

C

um I believe so, yes, yes, it's referenced by the foreign building, a console app, so it must be.

A

I mean like: would this be better if we just returned it as immutable raw data.

C

Well, I mean just because it's in the shared framework doesn't mean you can use it from quality right because it's not in quality. I'm.

B

Not in cortland.

C

A

uh Currently, system security, cryptography, x59 certificates, but in the next release, it'll be just system security cryptography, but still not.

C

Yeah, if you're outside of kolib, you can probably add a dependency on it would be my guess.

C

I

C

Low as you want it to be, so that you need to double check that, because you might actually depend on other modules that transitively depend on yours, so there's a we. We may have.

A

It does seem weird if immutable indirectly depends on crypto, but.

B

Yeah you'd be amazing, but what what's? What's wrong with the idea of just having an api that returns a non-coffee and byte array? And then we just tell people like use this responsibly, because we're returning the concrete type that you would have taken a dependency on us returning anyway.

B

A

I don't know I mean we're, that's back in the when writing up fdg3. I did the analysis of do array returning properties make defensive, copies or not, and the answer was basically 50, 50. and well. This.

B

Wouldn't this wouldn't be a property, this would be a. uh This would be a method like clearly named like get non-copy and byte array, or something like that, but I guess that again the thing I'm having heartache with is: why are we? Why are we talking about returning an abstraction when we're all in agreement that the actual backing store has to be a concrete type and that people will take a dependency on that.

A

Because span's useless as a return value, that's the whole reason. uh Once you've gone down to span you can't you can't go back up to async. You can't go back up to stateful things like asn reader, so returning returning spans is the worst thing you can do to the caller. Unless you know.

B

I think uh christoph spelina would vehemently disagree with you. There.

A

um No, no. What we really like are things that write to spans. You have you have some memory and you want the api to write into the memory things. Accepting a destination span as a parameter are great things. Returning spans. Are you you? Let things work for some percentage of the people and you make things very complicated for the rest.

B

So it is your argument, then, that, because there are already other system, security cryptography apis that work on memory, that this would naturally fit with those apis. So you're talking about this, this as an ecosystem unto itself, rather than just a standalone api.

A

Sort of I mean it's also patterns and practices. We haven't done this a lot so figuring out what it is that we want to do. But you know if you look at asn reader, which is technically not system security cryptography, um but it's.

J

In the same very related.

A

uh Yeah, so it's you have the all these things that return asn data. So after this we could then go look at the asn encoded data type, which also has a raw data property.

A

So you have these asn encoded structures right now we return the copy arrays and then- and you can read them and then, if we're looking for a lower allocation overhead version, then well great. You called that. Now you got the span now you can't call the asn reader.

A

huh We pushed you down to too low of the level too fast.

A

If we had read-only array, then sure the closest we have is read-only memory.

B

Yeah now, if, if, if you're, making an argument that it naturally fits in the flow of like I have this, I called this property got the read-only memory, and now I want to pass it to an api that takes a read-only memory like without doing any type of intermediate translation.

B

um If, if that's the argument that that's being made, that, I think that's a valid argument and I'll I'll, you know rescind my my uh comments.

A

Okay, I mean I can also be convinced, probably for span just. It feels wrong to me. um We haven't heard from oh.

D

A

Tobe you joined.

D

Yeah sorry other meeting ended. I'm back no worries.

A

uh So we were discussing the the virtue of memory over span for uh raw data memory. You participated in the chat, but you know now here you can state which way you would you really feel in your heart of hearts.

F

D

I don't know I, I think it would really depend over on what people do with the results of this um there. You know in cases we return span it's because the vast majority of consumption is just you know, doing something: local on the stack doing a compare, doing a search, something like that. What do people do with the raw data that comes back from an x, 509 cert? um If it's passed to other methods that might be async, then spam doesn't make sense.

D

I mean we're basically, but then again I I largely agree with libya levi. I think, like the only reason we're talking about adding this is to avoid a copy, we're not slicing we're not doing any sort of subset, it's purely hand, something out that avoids a copy, but with read-only memory you can get at the underlying thing anyway. So why not just expose the underlying thing, even if you want to put an unsafe or dangerous or whatever prefix on it, just expose the the raw array and just like you can get from a memory.

A

It's fair, so dangerous get raw data.

B

I mean I've, I don't necessarily know if we need to prefix it with dangerous. um I like what? What did? What is the consequence? If someone changes the spider right.

A

That somebody else who calls it now doesn't get the same thing. So the the two things that I can think of that are the most common of what to do with the return answer from cert.raw data or save it to a file, because it is no matter what format you loaded the certificate from this is the x 509 certificate. It is the certificate, it's not the private key, it's not a it's, not the signed data structure that could have contained multiple of them.

A

It's not the windows, serialized, cert or serialized store it's just the x509 data, so that it would be save it to a file or pass it into the x 509 certificate. 2 constructor, to make a copy of just the public data.

A

D

Are the two most common things? How about would it be if we just took a breaking change and made raw data just return? The underlying array.

A

I mean I don't it's the same, who thought it was a scratch buffer that they could modify.

D

Well, we take a breaking change and we basically say if you're doing that, make your own copy. It's up to you.

B

I I don't know if I would be willing to go that far like I. We we've seen problems with like system, I o path and whatever returning shared arrays in the past uh and people manipulating them, and then things just going south um because parts of the system we're depending on them having uh constant values, and this is but this is a an instance.

D

B

D

As as opposed to a static.

A

Yeah yeah, I mean I can't I can't think of too many times where people would get this and modify it and expect to do meaningful things uh except amusingly for our tests, which not are just testing this behavior. But it's. They know that there's a like hey, go load, a valid certificate now go modify it and run it back through the constructor and see. Do we get? You know errors they're not trying to corrupt the data on an existing instance they're.

A

Just they just know that it's their array and now they can start corrupting it for their own purposes. Yes, we could just change our tests, but.

B

Yeah, I don't see, um I don't see any any documentation uh saying that it returns a unique copy every time. So it is just an implementation detail that people probably will may have taken a dependency on right.

A

Well, I mean that's the problem with returning a raise ever and why yeah I made fdg have the note of if you think you want to return an array from a property. um Don't.

D

I mean we've taken breaking changes like this in the past. Arguably, in places that are even more pronounced, like I think, is it stream writer or a textwriter.newline.

D

It's like a it's a protected array and we it had been making it a defensive copy and we changed it, maybe.net core 2.0 or something to not, and I don't think anyone noticed.

B

huh Interesting, so what do do you do you remember uh which which property it was specifically? Oh, I see yeah uh text writer dot, core new line is that.

H

B

B

Sorry, I'm just chucking a few things um I I could be convinced to take the breaking change.

A

For the second time today, it makes my spidey sense tingle, but I can't.

A

Can't come up with a very strong reason, other than you know, historical precedence and what, if somebody's doing it wrong? Yeah.

B

I mean we have, I guess the guideline, as you had mentioned earlier, is generally don't return, byte arrays as properties anyway, because you can't really reason about it's, not.

A

B

A

B

Well sure yeah yeah, because you can't necessarily reason about whether the property is making a coffee or not. But if we, if we clearly document going forward like this, this could return. You know a a cached copy, um then people can actually start just writing. Optimized code or code, that's at least optimized on future runtimes.

B

D

I I think the only thing that stands out for me on taking this breaking change is in issue 38 864. We actually made the opposite decision, which was to add as much copying as we could, because we.

I

Ran into an issue where somebody was mutating, the underlying arrays and it was unexpected.

D

Behavior so we started adding a bunch of copies to exporting and issuer name and subject name uh to defend against this. So if we're okay with that breaking change, then maybe we can undo some of this, but you know that seems to go in, in contrast to the this particular change.

A

Yeah, were they calling export or raw data? Do you remember they.

D

Were calling export, but I mean it was the same underlying concept. You could do the same thing with subject, name or issue or name, and you know, because.

F

D

Were handing out the underlying arrays, you know, uh you know.

A

Yeah well because I feel like with export that one in my head, it does feel like you're calling a method, that's returning an array. So obviously it's a unique array.

A

So I think, even if we, if we made raw data, say it's just returning the same array over and over and over again, um which would certainly make for loops nicer uh that that's that we should still make export return. A copy.

D

Yeah, I I agree, but we did this, but for the other things as part of that same change, we made copies, for you, know, issuer and uh and such so that we uh handed out some other copies of places.

B

F

B

And by the way, steve when, when you came online, you had mentioned um like what do people do with this? Do they tend to pass it to apis that take a read-only memory of byte uh as a parameter, and the answer was like? Presumably, yes, um so at least as far as the crypto and crypto adjacent stack, um returning a read-only memory isn't the worst thing in the world um it.

B

It still makes me a bit uneasy that we're returning an abstraction for something that absolutely has to be backed by some like a concrete type that people will take a dependency on, but that's actually not the worst thing in the world. I guess like. Maybe we would just even document like this is a read-only memory. It is backed by an array like if you need the raw array. This is how you get it keep in mind. This is unsafe code, yeah.

A

Emo's depth map that he just put in the team's chat says we could take a dependency on immutable collections here. If we wanted to.

D

Can you cheaply get a span or a memory from an immutable collection, because my use cases I want to span I'm going to feed it into a pemrider?

D

That's what brought this whole thing on me is, as I was doing, the uh pam exports and I noticed that raw data was just copying and copying um and pem writer takes a span, um which is why it started off as a span, and then I was okay with memory because well I can cheaply get a span from a memory. Yes,.

B

D

Not sure about that from a mutable collections, immutable.

B

D

Of tea can go to standard.

B

C

Yeah we have as memory. We have s pen now mind you is read only but yes, you can get to it.

B

Well, we I mean we would be returning a read-only anyway, so behavior-wise, it's not uh it's not a terrible thing.

C

Yeah, all I'm saying is in order for you to construct an immutable array. You will always copy there's no way for you to construct an immutable wave without going through a copy at some point, because that's the only way we can enforce it to be right.

A

But we could right now we have the the field. You know we have this um lazy raw data and instead of making it be a byte array, we could make it be an immutable array and then just return that from a new property and then the existing one would call.

B

Just two array off of that like what does returning immutable rate at you that the other data types? Don't you didn't like that, we were returning an abstraction.

B

I mean is immutable array not and well.

B

I guess immutable array is not technically an abstraction. It's just a a limitation over what you can do with a regular array.

C

Yes, that's exactly what it is.

C

But in that sense it's not different from with only memory of byte.

A

Indeed, so that's just if, if we are allergic to returning the memory um like I like.

B

Memory because it's not allergic to it, it's more.

A

Versatile, maybe.

B

A

B

A rash it gives me a rash rather than a statement. How about that.

A

uh It actually looks like um immutablearray.as memory gives you access to the array, so you can make an immutable array, be not immutable. Yeah.

B

I mean you can do anything with unsafe code. It's great.

C

Yeah, once you go onto it, we don't care.

B

um I I guess I'm coming on the side of like just take the api, as it's proposed.

A

Yeah I mean, alternatively, you know if, if we think that the property returning thing is span and that's fine and if you're calling right, async or you're trying to use asn reader, then you have to deal with the copy. We could say that it just seems sub-optimal.

B

I mean you could always just you know, pass in a buffer and then tell x509 start. Please write stuff into this buffer.

A

B

That saves gc own absolutely everything.

A

Yeah that saves gc. It doesn't avoid the copy but yeah.

B

Yeah, well, that's what most people want I mean have. Have you looked at the code? That's that's going into the core libraries and asp.net like we are copying all over the place, but we're avoiding gcs while doing it.

A

So yeah I'm certainly okay with this, because I'm the one who marked it ready for review.

B

Yeah I've given given the scenarios that we want to be able to take this and pass it into other places that accept read-only memory like I can. I can see this api working as part of that larger crypto adjacent.

A

Ecosystem all right and scrolling back through chat because sorry, chad, I wasn't paying attention to you.

A

um Looks like chat is for immutable array or read-only memory instead of read-only spam, so.

B

I think this is given the ecosystem that this lives and I think it's special enough to return memory instead of span generally generally for the typical case, I think I agree with selena um in that. If you return a span, then you give the caller the option of what they want to do with that. If they want to stand alone copy, then they would just call to array and look. You have standalone copy.

B

But this is not that.

A

What are you sorting by emo.

C

It's uh complicated.

A

Fair enough, um all right, so since we're doing this for x59 certificate, two raw data, should we do it for asn encoded data raw data. At the same time,.

B

uh Is there sorry, was there already an api review for that or.

A

No I'm, this is the, should we just throw the second thing in here as it's the same thing on a different class.

I

That's in pkcs right; no, it's an encoding!

I

A

Off of asn encoded data, uh we then have the x509 extensions and the pk cs attributes, but.

B

The raw data property returns the same array instance every single time unless I'm looking at the wrong type. Are you looking at asn encoded data.rawdata as a property.

A

I mean I'm I'm looking just at the api catalog to see where it was, but if we're returning that one direct then.

A

B

Yeah, the the asn encoded data.rawdata property just returns the same instance everything every single time. You call the getter amusingly enough. When you call the setter, it makes a clone.

I

Because, of course, it does thanks brian the construct the constructor makes. The crop makes the uh copy, because the constructor just calls reset yep yeah.

A

Okay, so we don't need it there right.

I

There's a nice comment there that says net framework demands that we return the array without copying. Yes,.

B

Because I guess they actually had scenarios where people may have manipulated. That array probably means we did so internally.

B

Immutability was a mistake.

A

B

Hey look: that's the last issue: marcus seminole.

A

Thank you, kevin.

A

I should actually prove it or something.

B

Are we looking at that next, one with dread or yeah emo.

A

Have you had enough alcohol to talk about the object, serializer.

C

um uh In principle, yes, but we need somebody else in that room. We need andy in here, so I haven't scheduled it. So we should have a dedicated conversation. We should skip this one for now.

A

C

B

Since tanner's, here we could do the pause intrinsics one. Oh eric he's here too, okay, yeah.

C

Yeah, I have zero opinions on the remaining order.

A

um Add it consider adding socket, send or receive async overloads that allied the socket flags argument, 43934 so just simplified overloads that do the right thing.

D

I think the concern is 99.999 percent of calls past socket flags dot, none. So why require it to be specified?

D

um If we did want to address that, I don't know whether adding new overloads or just adding a default arg default value for socket flags is the right thing, although my guess is in some of them, we couldn't add a default because it's not at the end.

B

uh It looking at this, um it looks like cancellation. Token is the only thing that might oh endpoint, uh never mind. Yeah.

B

I mean for so it looks.

A

Like this is the only one that.

B

A

B

Would you be okay with um with just that one having an overload and the others having defaults, or does that asymmetry kind of not sit well with people? I mean.

D

We already have.

B

Asymmetry in these apis because.

D

They've been added to and added to an attitude over the last 20 years. So, um okay, I I don't have a particularly strong. Why.

A

Vomit reaction, so I'll start with. Why are these proposed, as extension methods instead of overloads.

C

Because that's what they are today for some reason I mean.

D

C

For some reason, I.

D

C

D

I think we, my guess is this was open before we moved uh uh so historically, we had added the socket task, extensions thing because um uh we thought these apis were gonna, go down level to dotnet framework in some fashion, and then we kept adding to socket task extensions, even though we knew that wasn't going to happen, and then I think in either five or maybe it was six.

D

We basically added everything from socket task, extensions back to socket and now socket task extensions is just dead legacy, so cool, I I don't think we're adding to it.

C

D

We did it right.

C

Yeah yeah looking at api catalog because he did it in six. um So that's that's good! So then yeah! Let's basically not do this on task extensions, but I think the proposal makes sense. I personally would probably go with overloads, mostly because it kind of scares me because many of them already have a ton of overloads and made me now make things in the middle potentially defaulted like I just I mean cancellation tokens always at the end, and we very carefully crafted them like this way. But I just wouldn't do this for the socket flags.

C

I think I would just keep them as overloads.

C

Also that allows us to actually default values that are not none. If we ever wanted to.

A

Well, to change the defaults later.

C

Well, I mean you could not so much changing as in like imagine, we had a new flag to socket flags. We wanted that to be on by default all right like. How would you do that so.

A

That would be changing the default behavior.

B

Interestingly, it looks like uh some of the some of the cancellation tokens are defaulted and some aren't, which is about weird at least looking at uh apis. I've gotten out, like.

C

B

C

Yeah, I think they were edited as overload so initially originally, I think we probably just did whatever we did on task extensions.

B

Oh yeah, yeah you're right they're they're not defaulted when they are overloads, you're right.

C

So yeah we're not that's the other reason why I would just go with overloads and call it good. Okay, sure.

C

Yeah, once you have six overloads, I think overloads are safer than trying to make things default in the middle. It's just easy.

J

To reason about.

A

What name space is this system that sockets.

C

I believe so, yes, system, dots, system.net.sockets.

C

And the tide that would go on the socket, not sucking yeah but yeah.

C

Seems reasonable.

A

No, I didn't merge in these yet.

A

All right so yeah everything from socket task extensions is gone right.

C

C

Did we mark the type as editor browser whenever.

D

Don't know, but it probably makes sense.

C

Well, they should do that. No, it doesn't seem like we did.

C

D

Sure I can even obsolete it.

C

Yeah, we should probably just mark the type as well.

C

Because at this point, there's just noise in the name space.

C

I think marking the methods makes sense, because I think in c sharp they show you both and it's just they don't bind anymore, which is weird.

A

All right so receive message from took it as ref, and now it wants to not take it.

A

I guess that's default goes in and don't care what comes out yeah. I hope, hopefully, you weren't supposed to remember that for a future thing.

A

If that makes sense in context, then okay.

D

I have no idea if it does, it might be worth double checking with jeff.

C

I don't even know what how these mean.

C

On behalf, I mean any.

A

There there's my uh warning on that. One.

I

A

A

A

All right we went with overloads, we dropped the extension type. I think I did those edits correctly and double check receive message from, because that socket flags was ref.

A

C

um Can you add the editor possible? You already already do that.

A

Oh on the existing.

C

Yeah just add the type as a partial and put the attribute on it.

A

That might compile.

C

A

A

Add clear method to memory cache 45593, which involves adding a method to an interface nope.

B

Have we decided we can't do this.

F

We've said we can't do the interface, but we should be able to add it to the class.

C

C

I mean at this point the question is: what video does the interface add.

F

C

Can we just obsolete the interface.

B

Is it maybe meant for unit testing? It's meant for asp.net loves interfaces, yeah, so unit testing, then yeah yeah. I mean.

F

Even yeah could have been an abstract class for you.

C

And the problem is once we add core functionality to the class, but not the interface. The interface literally is no longer usable. Even for that right.

F

I mean yes and no, but a lot of people, the real reason. People use interface, a lot. It's like you, you try to get, though I memory cache from your di services right.

A

Yeah but the di system doesn't require interfaces all their samples.

I

A

Interfaces, but that was that's not a technical requirement of the system.

C

Well, my point is more like: if we don't deprecate the interface, what ends up happening is we add methods to memory cache that nobody can invoke right because everybody still takes the interface yeah, that's kind of defeating the point, so I would say if we, if we decide that we I mean the other ones are just more like.

C

J

This is where we create imemory cash too,.

C

I mean, if you really wanted to that, would not be a terrible idea, but, like I, I think that to me seems worse than just agreeing that the moving forward is the you know the base type and call it good.

J

I was joking clear and we can't default implement it, because our memory cache only implements I disposable if it implemented something like I get or I innumerable then, given that it has remove, you could have feasibly implemented clear as a dim, but.

A

J

A

Also they're net standard 2o, so they can't be a dim.

B

Oh no they're, ah so I'm looking at memory cache right now and they already have some apis that aren't on imemory cache. um So having an api added just there and not to the interface would be consistent with prior practice, but they also have a finalizer. So whatever.

C

I guess, of course they do. Yes, I mean honestly. Like I mean it depends on what clear is for right. If clear is more for the host to call in super rare cases, then maybe it doesn't have to be in the interface because interfaces more people that just retrieve information from the cache, but like it still irks me that we have this growing discrepancy between the types right. So, ideally, we should just get rid of immemory cash in the long run, I'm getting rid of me, I just mean hide it. Obsoleted, move on with life.

F

I think that's just a larger thing that should be addressed somewhere else like there's, there's literally every time we try to make something in extensions, some new thing: it's we have an interface and we can't change it like. I think that should be its own.

F

Let's get rid of all the interfaces proposal like let's not hold this api hostage for that larger discussion.

B

Yeah, I agree: there's nothing stopping us from adding the api to the concrete type, though.

C

Yeah, I wouldn't go that far. I would just say we should follow the issue now.

B

Because there there is, um we remember, we discussed this uh yesterday too, in a separate form like what what it means to have. You know a bunch of testable interfaces across many different types, not just this one. um Those conversations can all be folded together.

F

We hit the same thing in di with service collection right, it had I-service collection and then we wanted to add a bunch of like try methods to it and we couldn't add it to I-service collection.

B

B

Because if if this really is meant, for you know testability or di scenarios, it would be nice to have something that we can position. As you know, first class across a lot of the framework, not just this. That can evolve as the concrete types also change.

F

I mean honestly, it's not just testing right, it is. It is decoupling right, like the our memory. Cache has an implementation to it, and some library might not want to depend on that implementation right. They just want to say, I need a cache, get it give me it from the di container and I'm going to add some stuff and get it later.

B

Right for stuff, like that, I don't think we should necessarily provide the interfaces that are supposed to be used by the entire world because, like we're clearly going to make an interface for the behaviors that we're implementing and if you need something that our interface can't describe like now, our interface is holding you a third-party hostage, um which is not a tenable situation to be in.

B

F

The point is, the library doesn't really care what the implementation of the memory cache is right. They care.

B

About the functionality that's exposed by it, and if our interface only has three apis that it'll, if our interface only ever has three methods it'll ever expose like that kind of dictates what functionality any given implementation could ever have right.

A

I mean so the real way, according to our design guidelines for doing this is instead of making an immemory cache and a memory cache. It's you make memory cache be an abstract class, and then you make some way of having what the default implementation is, whether you call that default memory, cache or just you know, a static method on memory. Cache of give me the default implementation and then using something like di, they can say, bind uh you know the singleton of memory, cache to memory cache.default.

B

And yeah yeah yeah, the the weird thing about that, and I know steve you were actually running into this very recently, was when you have virtual methods now, depending on virtual methods. uh It affects what optimizations you're able to make.

A

Indeed, I like it, I'm not saying it's a that evolution is trivial in that case, because evolution is possible in that case, yes, yeah.

B

It just means that if we were, if we were to introduce a clear method, for instance on an abstract based class, we would have to have you know a really good answer for should clear, be written in terms of any other virtual method that might exist on the class that someone may have overridden, or should it be its own completely unique implementation?

B

Does that mean and yeah yeah, so does that mean the default implementation, no ops or froze.

F

A

But right, that's the you know the asp or the stuff that came from asp.net, so most of microsoft. Extensions is a class and then an interface of the same name that copied the the public surface area. But that's.

A

This is why we don't do that.

B

Yeah, I'm I'm looking at the class right now. It looks like they have no virtual methods other than um the dispose method, so yeah. So.

A

Sure, because they use the interface as the.

B

Yeah yeah virtual.

A

B

I'm I'm just double checking to make sure what you wrote was correct and I believe it has yeah.

A

And yeah jeremy cape uh jeremy kurzinski points out that uh there are other things that we did for six, which I don't know if we're already showing up that we added on the class but said we couldn't modify the interface for this exact type. Okay sounds good.

C

All right can you can you link the issue I just filed? I just felt five 57596 to keep track of this interface stuff.

A

So I see it here.

C

Oh yeah yeah, because I because I linked it to you.

H

A

A

J

This one's probably me, uh basically, we have op app context and it allows you to get data set switch and try get switch. But if you want to set data, you have to go through app domain and after main people just really shouldn't touch. So we should make sure to expose the correct api on app context.

J

It already exists, it's just and it's public, it's just not in the ref assembly.

F

Do we know a reason why we never put in the ref assembly before.

J

uh Yes, yawn listed it somewhere down below and it basically boils down to. uh There was plans to not expose. uh uh There was plans not to expose abdomen at all, and then we ended up exposing app domain and it just never ended up happening yeah.

J

So it's basically just oversight.

J

If you want to do it today, you have to you, have to get the data through app context, but set it through app domain, and that just doesn't make sense why the the apis are functionally separate in dot net core right.

C

I mean it seems cleaner to me to to do this and then basically not use app domains for that yeah I mean, what's what's.

A

Weird is this: if you're trying to use um you know the app domain set data concept but you're you also care about framework, so you're on net standard too. You still have to switch to app domain, but I do agree that it's weird that we put the get without the set yeah.

B

So the only one one thing that we might want to do- and this would be purely a dock issue- is um unless you're calling set data at the very beginning of your application.

B

um The values that are in app context are likely to be um are likely to be either cached or starting to get baked in uh as legit compiles more and more stuff. um So we should just make sure to tell people like hey set. Data is really really meant to be a startup thing like if you call it in the middle of your application running, you might not get the behaviors you expect.

B

A

Like I don't even know what the app, because that's true for app context, get and set switch basically.

J

A

Don't know what the data is.

J

Data is basically switch for anything, that's not a boolean, so you can set strings. You could set a guide in there. You can basically set whatever you want. um This is just a global dictionary, right, yeah, basically uh and so functionally um as soon as something gets, the value, the first time, if you and caches it in, for example, static, read only which is common behavior for switches, uh then modifying in the future, will not impact anything. That's already cached the value, but that's relatively true of any property in existence.

J

um I think I think I agree with levi it's good to call out on the docks, though,.

B

Yeah yeah, it's just a doctorship yeah.

A

And actually, thinking about it, I don't think get switch is cached. I think it's just most of our uses of app context. We use a local app context. That, then, uh is where the cache that's the read at once and maintain consistent behavior, correct.

B

D

B

A

B

We also um the legit could uh could say: oh I'm, I'm now, caching, this thing all right now, I'm now starting to check the methods in this class where you had a before field and a constructor that went and read the value of this and set it into a static read-only field. Well, now the cogen's actually being baked with that. So there's no way through reflection to ever change that anymore right, like random stuff, like that yeah.

A

Hey objections.

C

A

Add diagnostic source right of t to assist with trimming five. Oh four, five, four air earhart.

F

Yep, so this one's a bit tricky but I'll try to explain it as best as I can so we have already diagnostic source dot right and you can you just give it any object and it basically uses reflection over the object and so in when we were doing trimming in 60.

F

We marked this api, as um requires on reference code, because it's it's basically a serializer right and kind of the, maybe not the issue, but the inconvenience we ran into is that, since this api is object, we couldn't stick uh dynamically access members on a type and to say like to preserve all the members on this type. And so, if you look at like the bottom um example, this record began.

F

Request diagnostics um like if you have a here, we were using we're using um anonymous types as the the payload into right and you kind of there's no way to like mark the anonymous type, as you should preserve this member this member, this member, because you know people we're going to need those properties when we get reflected when diagnostic listener, dot right is, is being called and so the so the solution here.

F

The proposed solution here is to add new overloads to write that takes a t that we can add dynamically access members to so that way the properties are preserved. By default.

F

It's still, it doesn't make the api 100 trim friendly, because if there's pro you know properties off those properties, we still can't the trimmer still will trim out those things, but at least in the case where you're, using anonymous types or even you, don't have an anonymous type. But you don't want to go mark you you don't want to manually, have to mark all the properties as as trimmer. Please keep these this way at least the top level properties get automatically marked for trimming or kept for trimming.

C

But you also couldn't right anonymous types: there's no syntax would even allow you to do that.

F

Right yeah, we I'm pretty sure I might have yeah. I guess in the conversation when I came up when I came up with this proposal, it was because I was changing a bunch of our code to make it trim safe, and I basically had to make it not use anonymous types to make it right.

C

I mean, I think, that it's reasonable.

C

I don't know what else it would do.

A

Abandoned at subject, yeonen.

C

I didn't get that damn it.

A

Has anyone any objection.

F

I mean, I guess, though, owners of diagnostic source aren't here, but it's been out since march and nobody's.

A

F

A

Yeah I mean this, it looks fine to me. The generic will get preferred for anything other than args being uh explicitly typed as object, um and then it just gives your linker something to paint.

F

Yeah, you still get the warning as a call go ahead. Stephanie.

H

I'm just going to ask like assuming that there was like a dynamically access member types, public properties, recursive or something, um and that like would that be useful to serializers. And would you be able to get rid of the requires a reference code attribute and would that even be possible, like long term,.

F

I can point you to the issue that talks about exactly that.

A

Yeah, but it's if this was done, then these this would now all of a sudden become uh quote-unquote friendly in that it's terrible, because it's everything is in scope, but it's it at least knows to paint that then got it right.

C

So the attribute itself will be meaningless for the other parameter that is typed as object, because it would only keep things that are on object.

C

Not the actual type that's being passed in.

A

Well, there are no options.

C

Existing overloads.

F

Right, the existing overloads are just pure all out unsafe, like nothing's, going to be preserved on by itself. Because of this call yeah.

C

That's what I'm asking so if you would put dynamically accessed members, I guess that doesn't get doesn't apply to parameters. It only applies to types right.

F

Right, yeah right.

C

F

Has to be a type that's attributed with it.

C

So they say that means if you want to attribute a parameter, you always have to introduce a generic. Then.

F

I mean it assuming that the your parameter is typed object, then, yes, like any api that does reflection over some, so any object like get type and then start creating the properties off of it. That's just the trimmer cannot recognize that pattern at all. It sees there's any kind of object going into here. I have no idea what properties are going to be on that object right, but.

A

If this, if the 99 percentile of these implementations just called value.2string, then you wouldn't put this here, because it's statically verifiable.

F

Yeah, none of the implementations of diagnostic source, just called tostring right.

A

F

They loop over the properties. They, it literally calls.

A

F

Doesn't get typed.

A

It's the reflection that it's doing that's the problem, not the fact that it's typed as object.

F

Right, yes, you can have apis that take an object that yeah only call get type or two string or equals, and.

A

This still actually won't quite solve everything, because if you have a a local or if you have an expression that is typed as a as a middle type in a hierarchy, but you have a fully derived instance. It won't know that it's keeping it off the derived type right, because this will only preserve the static closure I mean well, so it helps.

F

No, you can solve that, though right is you don't call value.gettype? Instead, you say typeoft dot, blah and then no matter what.

A

No, I mean in this in this method, if somebody calls diagnosticsource.right and they have a the thing that they're passing in is in the is of a variable typed foo, but the value as a bar extends foo.

A

It won't preserve the properties off of bar.

F

That's right right, but that doesn't necessarily make it unsafe because, like what I said, if the implementation says type of t, dot get properties, yeah.

A

F

Right like then, no matter what, whether the trimmer, whether you're trim or not it'll it that you know statically only uses type of foo.

C

Right, you can only see what basically your type was yeah, but.

A

This is just going to turn around and called cast it to object and call this one, which presumably mean or which doesn't have the type information. So for this specific scenario, is what I'm saying.

F

And what I'm saying is, I don't think that's a hundred percent slam dunk that it's just gonna turn around and call right with object. It.

A

Has to why this is not abstract or virtual. This is oh, you can't do anything other than called the existing one.

C

So it kind of is a slime doc you kind of have to do, but I guess the behavior is still meaningful right. You would only expose basically what the link I preserved, which you know. If you did everything correctly, it should be the set that you shouldn't be observable. Basically, what I'm trying to say.

F

It will be observable for the reasons jeremy just said.

C

Okay, then, I didn't care because.

F

Value dot get type, would return type of bar in that case, and so you'd get all the properties that are on bar.

A

F

You're only going to remember it's only going to preserve the ones that are on. Oh.

C

If you didn't trim basically, so if you, if you call this wire trimming, you would get different different behavior than if you wouldn't call it bar trimming well with.

A

Trim, if yeah it would, if you called it with trimming, it would depend on whether or not it thought your program ever cared about some property hanging off of the bar. For other reasons,.

C

Yeah that sucks.

J

F

I, like diagnostic source, is just completely on trim unfriendly, because the program doesn't declare which properties it actually cares about. It's the user, that's running the app that's trying to like turn on diagnostics, about it. They're saying give me. You know property1.property2.property3 off this thing and that's where we're getting the reflection from, and so it's it's not even your app, that's doing the reflection. If that makes any sense, it's like an external thing from your app that's declaring, which properties you care about.

F

Okay, if there's you know the hands are up, that's why we slapped it with records and reference code, because the trimmer will unless it, unless it's literally preserve everything about this object, the trimmer can't tell what properties it needs.

C

Should we leave it, as is then.

F

The value it does have is the anonymous types like.

A

Anonymous types, sealed types, um things or anywhere that you have your your expression type and your runtime type match it. It does solve the problem for you, it's just. You know.

C

Yeah, so you make it better, but not perfect. Yeah polymorphism.

F

And recursive are still problems, which is why it's still attributed requires a reference code. Yeah.

A

So yeah, I think it I think it's you know for just a little bit of il payload. We can improve some experiences, so it seems reasonable to me.

C

Yeah, I agree: okay, given that it's already best effort anyway, it's at least a better best effort.

F

Right, it's more of a convenience to help you a little bit.

C

You only have two minutes left, but the next two issues seem both easy. You should take a look at them.

B

I'm all for speed running api review. Let's do this.

A

Chat did comment that you know: spending 40 minutes on an issue didn't seem as quick and that's what our slow was. So I told them 10 to 20 hours.

A

That may actually be a little balling it but yeah. Let's try for quick.

F

The last one should be super quick, all right.

A

F

So we have this struct called dependency. um It already overrides equals. The apl proposal is to add I equatable to it.

C

And also market read only right.

F

A

That is the first half of the issue. Title.

C

I mean they both make sense to me.

B

Yeah, I thought we had an analyzer that uh that said, if you have a struct which overrides equals it should also be. I equatable, I guess.

C

Probably, but we probably didn't have run that in v1, okay,.

B

Yeah, this seems straightforward.

A

Yeah, um if I recall from my exploration and things non-read-only to read-only, is non-breaking so.

F

Correct right, it only has two properties. Both of them are get only.

A

Yeah and are taken in the constructor yeah I mean it also applies to the three methods but yeah.

J

A

All right, 40 seconds.

C

So tanner this one is fast. If you do the right thing,.

J

Yeah, so basically it's a hardware intrinsic um and I'm.

C

J

Necessary, let's go.

J

When working with threading, um we exposed some primitives like spin weight and such today, but those don't provide as fine-grained control over uh directly emitting effectively a pause. Exposing these intrinsics would allow us would allow users to write their own um more fine-grained spin loops that are effective for their high performance. Threading scenarios.

A

Is are yield and pause actual opcodes here.

J

A

Okay and what's the reverse element bits and the.

J

Cpu, that's the person creating a partial um and just listing the last thing in there. Okay.

B

Header are these: um are these off codes uh close enough in behavior that we would also do like a a common abstraction over the two? I.

J

Asked about that and uh if there was no consensus on whether we wanted that or not.

B

Okay, and if we, I guess, if we had such an abstraction in the future, we would actually probably put it on thread or something like that.

J

Right and there's potentially enough differences between these platform-specific ones, both in terms of number of cycles, they weight, among other things, that you might not want a common abstraction for them. The common abstraction is then, just like spin weight works for me.

B

Do you do you see us using this immediately within the dcl.

J

We already have our own very uh fine-tuned, algorithms that use these intrinsics on the c-plus plus side. Okay, it's possible. We could move some of that too managed with this, but that would require more in-depth discussion and investigation on whether it's worthwhile fair enough.

A

All right: um well, we both have cleared everything that we think that we could do today and we have run out of time, and with that I will see everyone in about three weeks all right. I declare this meeting adjourned. Choose.