Rust Programming Language Language Design Team, 21 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2021-04-21 Design Meeting: extern 'wasm' ABI

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Okay, it's recording now the question is: do we want to read the doc silently to ourselves or does alex want to present the doc to us, uh or both? It looks reasonably short, want to take five minutes to read I'm in favor of reading all right. Let's.

B

Read for five minutes? Yes, yes, okay, yep sounds.

A

A

A

A

A

So it's been five minutes. I see a lot of people writing questions, some quick questions more time to read.

B

I recommend we jump into talking um yeah and that's okay. Actually, let's ask that's right. The point is to ask anyone if they need more time to read right. That's what I'm first, but the point is not to write more questions right. The focus is: there's no need more time to actually read the doc.

A

Yes, all right, three, two one: let's do it um I'll happily take some notes, uh but there's this question cue: uh maybe we'll go down them alex you can pick which one you want to answer. First,.

C

Sure I mean how do you go and just like go down top to bottom and like read,.

A

C

All right, uh so what makes wise and binds and rely on is this existing cabi? um So this is an implementation specifically thing in wise and binded. Obviously, but the idea is that wise and by engine is all about communication between rust and javascript, and javascript is working with the wasm module that is actually working with, and so uh we have to like wasn't binding the tool and the macro has to under has to generate an a a abi that both javascript expects and the tool expects to be generated.

C

So the idea is that every type has a well-known api for how it crosses this boundary between javascript and rest, and then the javascript code generator can just assume the rest type. Signature looks look that looks that way, so, basically we're using extra in c, because we need the agreement and then the difference happens where uh right now there's a the way that it works is the macro you generate. You write a function that has an argument and then that argument is expanded to another argument in an avi style form.

C

So we kind of lower like the argument that you give to the api, but it's a one-to-one mapping like a one-to-one mapping of the parameter that you wrote in your rust function as a parameter to what's actually going into the cabi function and so, for example, strings are passed as a pointer and a length which is two values, and so we we rely on those two values to be splat into. The argument list where, like even when the cabi function takes one parameter.

C

It's actually two parameters at the api level and that's because the javascript expects that so the different. If the difference here is that in the c api like the canonical c abi with clang, that single parameter, which is two 32-bit values, is passed indirectly and the javascript could agree with that. The javascript could do that, but it doesn't today. And so, if we were to land this change on nightly, it would break anyone it like wasn't binding would have to change.

C

It would only be compatible with that version, so that would just cause a lot of breakage a lot of issues there, but does that? Does that make sense for why it's relying on the existing one, that's kind of.

A

Difficult to migrate, uh I think so I think you're saying so. I first of all, it seems like some of this logic is baked into where some binding uh is that.

C

Correct has everything to do with um how the macro expansion currently works and how the macro expansion assumes that, like we can take your given type that you wrote in your function and then use traits to project that to a different associated type, which we assume is an argument and like an extra in cabi. And then we make assumptions about that projection as an argument. What the api should be.

A

Yeah, so you can use traits to map rest types to simpler arrest types that the api sort of natively understands right. So, like.

C

A

So and then there's extent javascript code. That is also based on that assumption.

C

Right there's the cli, which then says that, like oh okay, your rust function took a string as an argument. Therefore, I'm expecting the apis. You take two parameters, which is the player in length.

A

And so you kind of have there's a bit of a problem of making them updating them. Both it's like a chicken and egg problem.

C

It's it's not so much that like it would be given a compiler. It would be pretty easy to just write and update wise, my gen to do the correct thing like we can just say that javascript expects it to be indirect pointer. The bigger issue is mainly beta, stable, where like. If we were to land, this then, like basically some version of like there's just some breaking point where like.

C

If you have this rust version, you can use the spasm punch and then below or if you have, that rust version you can use the spasm branch in it above and that breakage has.

D

C

Something that I wanted to do.

D

And it's not possible to use like a config version or something you know once that stabilizes, because you also need to change the javascript code generation, which happens ahead of time.

C

Right, the cli would have to like read the wes in binary and then understand what version of rust produced that wasn't binary and then it would have to like dispatch based on which version of rust, which abi is being used, and things like that.

A

What is a cli? Oh sorry,.

C

A

Line interface.

C

I guess the the wiser dash bind gen cli sorry. This is all very specific to wasn't bingen as well, so I I could try and boot up a lot of context.

A

I think I get the idea, it's a pain in the ass because it changes the behavior and you have to coordinate that across all these tools. Right.

C

I don't mean to say this is impossible, like I'm very glad this is an unstable api. I don't want to stabilize any of this until we have a lot more certain about all this so like this is all possible to an extent, but this is also like this isn't the only motivation for for adding.

E

So clarifying, then the goal is to have a version of rust that supports both abis simultaneously as a as part of the transition, and that's why we can't just change the c avi correct.

C

So like with this proposed api, the idea is that we would add this to rest. I would wait for that api to reach stable rest, and then I would change, wasn't binding to saying uh I'm going to use extra and wasm everywhere instead of extra and c, and then that version of weizenbandgen is only compatible with some version of rust, compeller and above, but you get like a compiler if you use the wrong compiler.

D

Would you imagine that there would be a future version of awesome binding where you would switch back to using extern c.

C

No, uh the semantics of extern c are not what I want, I don't think, is what anyone wants for wise and mentions use case like there's. No purpose of passing a string with the planner length indirectly, like the blur line, should be arguments so like through the semantics of the semantics of what happens today. What arguments go? Where is exactly what I think everyone wants for bison blind, and so I wouldn't switch back to extra and even if extern.

E

C changed to match extra and wasm for now.

C

Well, I mean if x and c change then yeah. It would be fine to change back to that. Like.

E

C

The semantics of like an aggregate passed as an argument being multiple abi arguments. What, if rabia, has that that's what went in once.

D

Is is it the case that, like you'd, then just think that the cabi that exists is like not good.

C

uh In my personal opinion, yes, but I mean the cbi, was I.

D

Understand yeah, I don't need to like quibble about the specifics of that like value judgment, I'm just trying to understand that. That's.

F

D

That's that's your issue like you, you wouldn't want to ever use a cabi, because you think that the wasm find gen api avi is is better for reasons.

C

Just for wise and mind gen's purposes, yeah not like in abstract, just like for the purposes of wise and by engine I mean like the idea is that currently there's no easy way to target a precise webassembly signature with like some with also some like nice things in between where you get to have like structs and aggregates, and things like that, it just kind of doesn't have. It has a little bit of an impedance match.

E

So it sounds like there's going to be a whole bunch of questions about this and we have a question q at the bottom. We should probably go down that list, although alex, please feel free to uh answer several at once. If there is an overarching thing that we're missing and we're still in the middle of seeing the trees rather than the forest. No that's fine.

C

I'll keep going and then we can kind of come back to this. That's okay,.

A

I guess felix's question here.

C

uh Right so felix.

B

Get addressed or not, I.

C

B

A

Oh, there wasn't really a question about make files that was just me being snarky well,.

B

I think it's a legitimate point to make that, like breaking the statement breaking the ecosystem, it's a question of how big is the customer talking about and I think that's the.

G

Way, you're raking and I think.

C

It's the point: I'm making.

B

Stating it at least.

C

Yeah, I think it's good it's important to acknowledge like if we change the c api for the unknown target that is technically breaking, but I think that's a bug fix, like I don't think anyone's going to say: please don't break it. It's just apparently, I'm the only one saying: please don't break it for wes and point you at this point anyway. So uh felix your question um is simply correct. Yes, the extern wasm would behave the same across all wasn't targets and extern c would also behave the same across all wisdom targets.

B

And it'd be support and external weapons will be supported across all western targets. Correct all.

C

Lies and targets just wasn't, I think, is the intention. I I don't think the implementation currently gives you an error error on like x86, but it should.

B

But I think I might have misinterpreted one thing in terms of the extern wasm is the way you say that the arguments get splatted across the argument list, like the structure gets um right.

C

I mean it's just a different api, so like the avi of external wasm, is that when you pass an aggregate, the aggregates it gets passes to individual arguments of the actual webassembly api.

B

Okay, I guess I need to go review what the extrinsic api is, because I would I guess I would have expected excellency to actually do the same thing. um So I'm surprised but okay, this.

C

Is where I mean.

B

C

Cabi lowering is different for all targets, obviously, and so for web assembly. It just so happens that any aggregate is passed indirectly as a parameter.

B

And that's like a definition, all right that that that's coming from outside us, maybe.

C

B

C

B

C

Made by folks with clang and there's.

A

C

In like a tool, conventions or public position,.

A

Okay, that's all I need here. Thank you, okay, but rusty presently does splat right.

C

um The current state is that rusty supports both with the splatting and the not splatting. The not splatting hung happens on every single target, except wasn't 32 unknown unknown, and the splatting happens on wisenbc the history. There is that when I first wrote it, I did splatting because I didn't understand what I was doing and then every other target doesn't use western fine gents was able to be fixed, and I know not known as the only target wiseman gen primarily uses, and so when.

A

You say other target, you mean every other wasm target. Sorry.

C

Yes, likewise in 32, wessie, myself, 32 unknown script and things like that got it.

E

So, does that mean wasm 32 wazi will not support extern wasm or will support it and it will match extern c.

C

E

C

External wasm will be supported on all western targets and will have the same definition across all asm targets so like the splat behavior is exorbitant and the non-splat behavior is excerptancy.

E

So that means on targets that already splat that it will match. There's.

C

A

C

No there's only one target where the c abi splats and that's under unknown, and this would change so why is there unknown? The cabi would be switched to be not splat and then.

F

C

Target the wise, maybe for all targets.

A

Yeah so c would always match clang right and wasm would do. The thing we think is better or alex thinks is better yeah.

C

I I I want to see better just the thing that I'm proposing here would be how I would summarize it. I don't want to pass a value judgment either.

A

You'll do the thing you want splat and multiple return values specifically.

C

Maybe we should call it extern alex. I mean here.

D

C

Just put alex wiseman where uh yeah something like that russell.

F

C

Anyway, so moving on uh felix has a question of summarizing unknown and wassy. um The only difference is the standard library where the unknown unknown target has no implementations of anything in the standard library so like if you print it, just ignores it. If you try and open a file, it just returns an error.

C

The wazi target, however, is built against the wazzy apis, so the yz target assumes that they could import a set of functions defined by wazzy, and this is like printing files, all that good stuff and.

B

The purpose is what deployments like targets in terms of where you're expecting anything to get to be launched or what that's effectively, where these.

C

Are end up being used so like on the web? You rarely can assume wisely, I mean well, I know unknown was also the original target and why azure was added later so.

F

Wazi is typically.

C

Used nowadays, sort of um non-web use cases like weizen time. uh Various engines like server style, use, server-side use cases and unknown because it is so limiting is suitable for the web, because the web doesn't have a standard runtime web assembly or like a standard set of import functions.

B

C

uh And this is also like, because wazi is so rare to use be used on the web. This is why western doesn't really target wesley that much, although there's not really reason to reason it couldn't, but that's why the wise m32 wessie c api already matches clang.

C

Okay next question: josh has.

F

Is the alternative of a.

C

Different extern c worth exploring that would allow rus one rust version to support both apis and would, and that would have different stability guarantees if we take independent targets.

E

Yeah there I remember originally, there was a proposal to have a new wasm target as opposed to a new wasm api, and I wanted to consider the alternatives there, because a different target has the advantage that, if, in the future c migrates to use the same abi, that wasm has then we don't find ourselves stuck with both eternally and we have the ability to evolve.

C

um So the reason I would say this is probably not a great alternative is the primary reason for changing. This is so it's just so c and uh russ can agree, and this is for projects that want to include both c and rust in their project, so like basically as long as extern c disagrees with clang. If you use that target, you generally can't intermix c and rust in the same project, which kind of sucks this.

A

Is a key I always kind of you said it was in your.

C

A

I kind of missed it. I think that's a key uh point.

C

Yes, yes, yes, but yeah! That is like the last number, two unknown unknown target. It's difficult, like you have to manually audit to make sure you just don't have aggregates in your parameter, lists to interrupt c and rest, and it would be great if you didn't have to do that.

E

So the goal here is that uh extern c can match see the c abi provided by clang on all targets rather than having so to clarify. It sounds like you're, saying it's not just that you want to be able to have both abis in the same rust so that you can do a transition.

E

It's that you want both abi's in the same rust, because you might actually need both for different purposes, one for calling c and one for interoperating better with other uh modules in rust or in javascript, or with wasmbine, gen or similar correct.

C

E

That's a great way to summarize it, which is c.

C

E

Very good clarification thanks, yeah.

C

And I I would explain that. That's like c, is your matching c, because you're calling c and wasm is, you are specifically doing something. That's not c or something like you're, targeting the webassembly target and inherently as part of the website. We target functions, have signatures which only take athlete2 and f64, and things like that and so you're, targeting a very, very specific signature for either importing or exporting, or something like that like that is the purpose like a function pointer with external asm.

C

Probably isn't that useful, but, like that's the general mental model for weapons or the wasm api.

A

C

A

External can continue to evolve.

C

uh So this is, um there was another question that taylor asked which about what types we allowed to be. We expect to be allowed and we could solve a couple things with this. um This is where, like I'm glad this is unstable, because I don't think there's a great answer here right now. It's just kind of like whatever and I think like a reasonable conclusion- could be that maybe we as we only s, we only accept a subset of types in the extern wiseman avi.

C

So, for example, web assembly only has i32 i64 floats, and now it has like v128 and extra ref and stuff like that. So we could limit the external wasm api to things that translate to that. So, like integers, smaller than 32 bits and aggregates- and we could say nothing else is supported like we could give you a rust error saying this type is not supported, so u128 would not be supported. You couldn't pass the u128128 and I think that would prob that that would be a.

C

I think a conservative stance saying we know how to translate these existing items into x or wisem and then, when extra ad wise on, add z128, then we just change our api and.

F

C

We start accepting that, so I think that would be a like if we stabilize exercism. I think this is required so like we define the semantics for aggregates, we disallow enums, and then we disallow all fancy types that we don't otherwise know what to do. It's like u128 f128 things like that. So.

G

Like the c types lint, but a materially different set of rules on what's allowed.

E

Right and a hard error, rather than a lint right, a compiler error, as opposed to a lint.

E

So is the intention there, then that you could add new items when the intersection of webassembly was on bind jin and rust agree on the best way to pass them.

C

um I would say wise and blind should be part of that equation, but but just I mean I would say that new items probably wouldn't be added, unless it's obvious that, like that nothing new in the future will encompass that so like, for example, uh u8, there's no wasm type for u8 as and we represent that as an i32 and like that's just a bag of 32 bits so like we would define that u8s or sine extended to 32 bits.

C

Zero extended and passed along, like that's obvious, that webassembly is never going to add a u8 type, but for u128 we could define that as like passes to u64s.

C

But web simply could add a u128 type of i128 type. So I don't think we ever want to accept that. So I think, unless.

E

We actually add that.

C

E

Web assembly, in which case right so.

C

Like anything, new here would be like it's obvious. Webassembly would never encompass this and we just forgot about it or we need to wait to add this because webassembly might add something in the future.

A

If there were a rust code that tried to use that, you would just expect an error, and so it'll be up to the rest user to translate their u128 to 264 or something.

C

Right like, if you wanted it to be to u64s, then you should convert that to a struct of two u64s and our definition says that an aggregate would be splatted.

D

So because you're defining aggregates to be spotted, that also means that um the contents of those aggregates wind up as part of the api abi, and so you wind up, checking those as well correct. um So that would mean that you know if you normally, you don't require um a wrapper c or representation on types right or or anything like that on aggregates.

C

G

C

That, with this restriction, we would require that rep c would be on these targets. I mean we could even add a repository, I'm not sure if that would be whatever yeah.

D

But the idea is, the reason is because there's sort of a subtle like potential for breaking changes. If someone, for example, adds a you know, I-128 to their type like their existing aggregate in rust that maybe even is represent right and then you use them as a library and then pass that value through awesome budget. I don't know how real that use case is or not like you know way better than I do. um I'm just trying to understand like is that another thing we need to guard against like.

C

Well, I was saying I think we want. We might want ripper c to that's kind of an indicator of saying the fields must be passed in this order, because the field order matters, because that affects the avi. But I'm not sure upper wasm makes sense, but only because I would probably want to support generics, which means that monomer, we would check the monomorphized version of a struct and.

F

C

Wouldn't actually so, if you put reproasm on something you're, just saying the field order matters, that's pretty much. It.

D

Got it okay and because you wanna you're, saying you wanna, support generics and so you're having to check the model more price types. So I I guess I'm I'm unsure. I understand, like I guess, you're saying that, like any values you pass along, there are already sort of you're not respecting any kind of like backwards compatibility guarantees about the contents of those types.

C

um I mean yeah, it's not you wouldn't be able. I mean if you added or deleted any field. You would change the api of any function but took that that aggregate by value, just because you're removing your adding.

D

Arguments right, but changing the api isn't the concern. The concern is like it wouldn't compile anymore, because you're now, like some you're now using a struct that has a non-wasm compatible, wasm avi, compatible type.

C

Yeah, oh yes! Yes, that is true um and yeah I mean that's. That's a downside like this is a thing where like. If we, if we do want to restrict the types in external asm, I could imagine it's actually going to be pretty difficult and because, like I'm, not really sure what happens, if you have like a generic function that has external wasm as the adi, it just means that certain instantiations are going to start getting errors.

C

That's kind of funky, because it's an instantiation time like monomorphization error and like you're saying it just means that, like if you happen to instantiate that with the wrong thing or like on some targets, might have been using this. But then, when you compile them, then you start getting errors like that's gonna be funky and it's gonna be very odd.

A

I I don't that seems in the weeds, I mean it seems important, but I wanna make sure we keep going. It's all.

C

Yeah I mean let's: let's go ahead.

A

C

Think we can come back to this aspect. That's okay,.

A

So I wrote, is it an accurate summary, but I think this has been covered. My previous conversation I don't want to. I don't think we need to answer that.

A

Taylor has the next question, but it seems like we were just talking about this too. Oh.

C

Yes, I was trying to talk about that the previous one, yet um the other aspect to niko in your question, though, unlikely to be updated in a reasonable time frame. I don't know that I, it hasn't changed and I'm unaware of any plans to change it.

C

um I would not say I would not pass adjustment whether it's like they're unlikely. I would want to literally confirm with the folks doing playing stuff.

B

But even if it does change, we don't know how likely this would change in a way that's compatible with what wasm wants to do right. That seems as much an issue correct.

C

That I, my impression is that the cabi has been selected based on performance and not based on expressivity so far, and so it's unclear whether that would work for these use cases.

C

But I mean I, I think, there's also a reasonable thing here of like if c picks an api and they're really sticking with it, like, especially for the multi-value aspect. At some point. Why isn't buying should just put up a shut up and actually go get fixed.

A

C

But uh let me go to taylor's next question, so what level of documentation and stability guarantees would we offer to extern wasm?

C

um So this is this is kind of what we were talking about earlier like I, I would expect that you would have documentation for what exactly like the goal of external wasm is given a rust signature. You can predict, you can predict the precise webassembly signature, and so I would expect documentation of exactly what that is so like we don't allow generics. We do allow generics. This is how they get splatted. This is how u8's get sign extended, uh because this is, I mean it's also rust specific.

C

This external asm wouldn't exist anywhere else in the business of the ecosystem, so I would expect us to have lots of documentation and pretty strict stability guarantees, because we would want to continue to migrate this with webassembly. Now whether that can all be achieved is another question: does that make sense? So we.

D

Would expect, in other words, that, like someone else, could write a wasn't, bind gen and replicate what it does in the javascript code right to line up with um that. The output of an external api.

C

uh Yeah, I I I would not expect that documentation would mention, wasn't binding at all it's more. This is all just kind of a lot of this is motivated in my mind in general. I wasn't going to use this because eisenbeing can then predictably say like given this projection of this trait of this like uh given this trait sociotype projection. I know precisely that the way that the abi is going to be this things like that.

C

That makes sense thanks.

B

I I realize now hearing your answer to this question that I was not clear on one detail uh that you, I think you said it earlier, but I just want to make absolutely clear about this.

B

um You gave the example you've, given two examples of things that aren't part of wasm um u8 and youth 128, and you I, my original interpretation was that you were saying that we just extern wasn't, would not support passing either of those things, but I now realize that what you in fact, are saying is that the plan is that things like u8 would be supported and would have a definite have a defined semantics for how they are translated into the was incompatible things, namely sign extension or whatever, while.

F

B

Like you for some reason, certain things like u128 because they might be supported in the future by webassembly they're, going to be rejected by extern wasm. Is that the idea? That's the theory I mean I. I.

C

B

C

Really stand up to a lot of scrutiny with that kind of like I, I want to do that. I think no.

B

I don't I wasn't trying to scrutinize, it was more. I was my initial impression was that you reject everything. um It doesn't.

F

Doesn't work but that's.

B

Not the plan, it sounds like because you want to make it easier for people to still um have like past trucks in and things like that, unless you don't want to just reject all you waits that are all strokes. Have you ate in them, for example, right.

C

Right right, exactly like I.

B

C

Think the goal is still to have general rus code work as long as the rust code is generally well behaved and then for types like e128, which are honestly very rare to cross between javascript and webassembly, or things like that, like that, those it just it's if we just if we reject those the time being, no one's gonna lose too much thought or tears over that.

C

C

Okay, the next question from mark are we expecting c and y.

F

I think this is answered so.

C

Okay, uh yes, yes, there will not be synonyms yeah uh next josh will extremism exist on other targets? uh My goal, I would probably say no. I don't really want to consider that I want to say it's just a compiler, like I think, there's already support for abis only existing on some targets, not others, and so I think we would just extend that.

E

So uh corollary to that, though, if we um don't define extern wasm on other targets, then I can imagine people wanting to define the same function on two different architect: two different targets, where the only difference is what's in the uh extern wasm versus extern c, and that's a bit of a pain to do right now, because, unlike config adder, you can't make the contents of what's inside the string, constant they're dependent on a config variable.

E

So we would, it makes sense to either add an attribute equivalent to extern that can be done with a config adder or tell people what the ideal pattern is like defining a macro.

C

I have done this with macros in the past, but I I.

F

C

Think it would be downside, and I mean uh scott just put their like externs blood, and, like I mean I, don't really want to be the one to add a new api to russ. Just because I disagree with splatting and wasm like I. That feels bad, but if it comes to that like, if it really is used for others, uh I think that's like that.

C

That's a possibility of like just supporting massim or supporting something like that on all the targets, I'm not sure if config adder would work because it needs to be part of the type signature of the function pointer or like of the type of the function. If you take a function pointer but yeah.

E

Fair point: it's more, I would like whatever pattern we decide is ideal for defining a function, that's identical everywhere, except that it uses wasm on wasm targets and c elsewhere. We should explicitly say here's the pattern we recommend and if that pattern is too painful, we should make it a better way to express that pattern.

G

E

G

Contains the items could hypothetically, do it right, even just a macro rules, one.

E

Yeah I mean it might even be possible to just define a macro that expands to either wasm or c, and then just do extern. That macro, I'm not sure if you can put a macro there, but we should. I.

G

Would bet you can't put a macro there right now.

E

We might be able to fix that.

F

I it does seem like from what I've heard so far that it would be pretty and like the the predominant use case, we expect for external wasm is for like wazimbang and potentially other tooling. That really precisely is intended just for this use case of you know, passing to uh across a sort of wasm api to some other language, and so it would be not necessarily typical that you would want to do this for, like a user-written function. In some sense.

C

Well, I mean so. There are hypothetical ideas like webassembly is going to get this thing called interface types which is intended for, like here's, a type grammar by which you can communicate with the outside world. In a what we're calling shared nothings like that, you have to share memory fashion and that's giving you the ability of like even in native code.

C

You could have a webassembly interface types thing and you could like define a native plugin based on that and then the same abi that you're, using for your webassembly module and theory, could be this exact same api.

C

You use for your native module and then it just so happens that, like you're using all the same stuff and like it's a very far-fetched kind of very far in the future idea, but that's a possibility where, like you, might want literally the exact same function, exp like for, if you're, defining a plug-in to be compiled, both the wasm and to native code, and that's because the the runtime besides just understands this type is serialized. This way and has this definition on this architecture.

F

Or this platform right, but that target might be a wasm target still if, in that hypothetical future right like you would have a, I don't know.

C

No, no I'm, like I mean, certainly you could run wasm on native host, but I mean, like you, write a plug-in and rust. You could compile it to webassembly, which has like the wasm api. But then you want the exact same functions to also be able to compile to x8664 linux, and I.

F

See okay uses like uses an actual native like.

C

Very unsafe could segueful kind of api like that, it's very hypothetical and this that's where like, if we only allow external asm on wasms for now it's just it's that's what I would probably say just to be conservative, just we can allow it in the future for other targets, but yeah all right um all right. uh The next question for will the cabin and was maybe emerge. I think we we'd stop by that. So uh no, they will probably not is the intention. If they do merge, then resin.

F

Doesn't make any sense.

C

We would just use the c api um I mean, but this does bring up a point about multiple returns, which we haven't talked a ton about, but this is a second motivation for the wasm api, which is the multiple returns idea of webassembly, and so the canonical c api today doesn't support it because multiple returns are weren't, supported or weren't allowed when the cvm was created- and this is this would be a way for us to roll out multiple returns, support in rust, without having like brand new targets or like brand new apis, and things like that.

C

I've I've seen that like, for example, we have arm targets for soft float and hard float, but they are entirely separate targets. In theory, you can control this with cogen flags, because the entire world has to agree it's kind of sucks to have.

C

It makes more sense to have multiple targets, and so I honestly think it would be really nice to not have different wasm targets for multi-value returns and so like. I don't want the wasm target and then the as a multi-value target, because, with the nature of webassembly features, everyone will eventually use the wasm multi-value target and there's no reason to use the original one so have using this at the abi level gives us the nice ability to say like well. It's just. This is the abi for.

F

Having multiple.

C

Returns, and so I don't have any idea what klang is going to do here- my guess is they're just going to add a code in flag and say compile the whole world with the right code in flag, but this one I think.

B

The metaphor analogy you're drawing here, because you gave the example of armed targets with soft load and harflowed and said like this is a real. That's a reality like that's something where there's just hardware support for floats and some arm systems and software and no hardware support. And thus you must and the whole world has to agree on which thing they're running on.

B

C

So, like different machine registers are used to pass, floats.

B

But my point is that the analogy here, I would think is about which virtual machine you're targeting and whether it's sufficiently new to support multi-value return right.

C

Yeah and my I would hope that if you're using like two years from now, you're using the latest greatest vm, which has multi-value return support, I would hope that you are using the wisem 32 wazi target. I don't want you to have to use like the osm32.

F

Lazy multi-value.

C

C

Is it that does that make sense.

B

I guess I'm just to me the analogy still, in my mind, works in terms of saying the whole world if the whole world has to agree in this case, it's a matter of which kind of virtual machine you're targeting then it still seems like multiple targets, makes sense.

B

C

This is where um I mean so: the multi-return is a backwards-compatible extension to webassembly, and so all existing vms are going to support this certain like it's within six months to a year.

C

It's going to be very rare to find a vm that doesn't support this, but there might still be bb people that want to compile with assembly without multi-value for something I don't know what, but I- and this is where it's slowly different- the soft float and hardflip, which is like fundamentally different runtimes, but this is something that this isn't really a fundamental difference at the run time, it's just whether runtime supports it or not. It's very easy to add support for most runtimes. I don't know if that's really answering your question.

A

Do you agree alex with what I wrote there that basically the difference is the wisdom is still in flux and we expect all vms to support multi-value return, yeah.

C

A

C

I I think so and like, but I guess the other thing I would add.

A

C

The abi is just so pervasive where effects it affects the entire program. So, like there are features you can add to webassembly like new instructions, and that could be very localized of like I just either my function either uses the instruction or doesn't use instruction, and it's a very easy, like cfg as to whether it uses that or not.

C

But this is different where, like we're talking about how I interact with the outside world or how the standard library will interact with the outside world, like, for example, eventually wazzy, the standard is going to have a specification where functions that you import will return multiple values, so the standard library is going to have to make a choice, and so I would love for the standard library to just say external, because it is binding. The signature of it returns multiple values, but interaction was like. We don't have to wait for the c api to update.

C

We don't have to wait for agreement on c, for whatever c is going to be. I honestly have no idea what c is going to be.

E

So the intent there, then, is that uh even if the standard library uses extra and wasm rather than extern c, to export some things, then that'll be fine, because rust is calling that it doesn't need to be javascript won't be directly calling stood without an intervening exported function.

C

This is more about imports of. Like the rest, the wasm module will import a function in the webassembly file that returns multiple items and that's sort of like that's the like. If we bind wazzy and wazzy changes to have functions that return multiple things, we we literally can't do that today, and so this would be the only way. This would be the way to do it is, and we can.

C

We can divorce that from c, if, like whatever clang, wants to do for the current c api, we would match it for clang, but we're not binding clang. If we want to, if we're targeting we're targeting like a web missile function,.

G

G

Silly question, perhaps, when rust is doing multiple return values? Is that like, if you return an aggregate, it puts them in multiple return, values.

C

um This is kind of not super well defined because it's not really well supported today. um The answer is, if you literally return like a rust, tuple you'll get a warning saying it's cabi incompatible and then it'll do the right thing. I think the way I so it's sort of like a question of how do we want to model this? I believe the way lvm is supporting it like just at the lvm layer.

C

Is you return an aggregate by value and then lvm translates that to a multi-value return, and so we could do that and that, probably honestly, is what we're gonna do, but we could also just as similarly say, we define the external wasm abi as supporting rust tuples in the return position, and that just naturally translates to multiple return values like we, you don't get the lint saying: that's, not extra z compatible or whatever. um So like.

C

Basically, it's up to us, we get to decide what to do here and by not trying to match c, precisely because we're targeting a specifically different avi. That gives a simply way of like supporting rust, tuples or just saying that the first level of aggregate is splattered, maybe others aren't. I don't like.

C

That does that make sense.

G

Yeah, that makes sense thanks.

A

Those two questions left in eight minutes, but alternative solutions.

C

I guess I should say.

A

The main one there is.

C

C so work with c, so the c a b I works for everyone, and this means that not only has the desired semantics that I personally want wise and blind to have for arguments, but also having some story for the migration of the cabi from what it is currently to multi-value, which I honestly have no idea what that what c is going to do there, and that would be good to hammer down so like that. That's hammer that down and see if that story, supplants the need for externalizing. That's the main alternative solution.

C

I can think of.

F

It does based on the previous conversation. It sounded like that solution doesn't quite fit the need of sort of. Obviously you can sort of hard code. What c does, but in theory at least uh it doesn't necessarily fit the desire for a very sort of simple and straightforward translation that hard lints or errors on not understood things, unlike the cabi, which currently, at least from what I know, is more like sort of best effort in some sense.

C

uh Yeah, no, I I agree like there's a that's a downside to using extern c, which is like all these problems about what like the extern c api will define what happens when you pass a u128 and that will not take into account what if u128 is added to asm in the future, and so the answer from the c side of things is it'll break. And if the cabi breaks it's like. Do we just inherit that breakage and rust?

C

Do we want to insulate users from that in rust that part's a little unclear to me because, like we could, if we separate wasm and c, we could insulate users from breakage in c by saying you just have to make sure you're using the right clang with the right rust, but if we're using extern like, but otherwise, if you're talking outside of clang, so you're talking to a host environment or to javascript or something then you're using extra wasm, and that is a very stable api which we're never going to break.

C

That's it's like we could separate. We could take that installation of breakage on ourselves or we could just follow c and say like well. They broke everyone, so we can break everyone too. That's my impression of what following extrancy would.

C

C

But I should say like naturally, that story would be very heavily influenced by what c's actual desired route of migration is, which I am unsure.

A

Last question: would there be a use for rubber razon to go with this.

C

uh That's what I was saying of, like I think so, but only like if we define the apis aggregates, are slided and splattered in the order of the fields there then represent, might be useful to say. Okay, it really is the order of the fields there, but we would still have these monomorphization errors of, like you used reproasm, where the struct had a trait and the field was a trait projection, and then only during modern organization do we realize that was e128 and should be an error.

C

So we could also just rely on remember c, for this, like rep c says the order's defined, and then the wrapper wasm on the lowering layer just gives you my monomer monomorphization errors, but either way. I would suspect that if we do validation of arguments, if you have a aggregate and a parameter, we would validate that something is on there either remember wesley or represent it's mostly just like I don't I don't represent, could disallow a raw I-128 field, but couldn't disallow like a generic I-128 field, and so I don't like yeah.

B

But it does sound like a way to to keep the error messages, because I'm understanding is without represent you're going to get those errors at the time when the call is made right, which might be actually downstream from the definition of the type.

C

My point is that that'll always be the case because even with wrapper reproasm, if you have some sort of generic parameter, sure.

B

There's cases where okay there's cases where, with generics and whatnot, where you won't, where it's hidden right behind the.

F

Level of direction.

B

But I can imagine cases where it's not where it does. It is apparent up front and without repper wasm you won't know it until somebody actually writes the code likes the call that.

C

Right so represent could front load some errors, just not all the errors.

A

Right, on the other hand, that seems to exacerbate the problems that josh was saying where, like we were concerned about functions that might want to use both wasm and c for interoperability. It seems much.

E

A

To me to have structs that you might want to pass across boundaries. That's true.

E

Yeah, um I personally would be inclined towards just use repair c and then, if you pass that in repper wasm, then we will pay close attention to what types are in it and yeah. You might get a monomersation time error, but so be it and I don't think we can do better than monomorphization time errors, because with repper wasm, uh if you have a generic, then you have to have a monomorphization time error.

B

Though the problem that josh described previously was something where that part was at rose because x turned the external c block, doesn't give you a way to say you know, I expect to be working in c in some contexts and wisem and others I feel like with wrapper the wrapper attribute. You do have a little more flexibility or we could even extend it to let you say, rep repper seek homowasm to say this struck needs to work in both contexts like it doesn't sound like as difficult a problem to solve.

B

I guess that's all I'm saying you can use configuration right.

D

The wasm thing seems like just potentially like it would be. An extra set of you know, requirements on the type right rather than as a separate, avi or separate set of like rep guarantees than c the one.

D

The one thing I do, I don't know I I feel like I've, I've been sort of convinced that this isn't necessary, but the one thing I do like about reproasm is that then libraries, exposing types with like private fields internally right, um would, as I understand it, like it's, a breaking change for them to add like a u128 to their structs, then.

E

Or something I mean it would already be a breaking.

D

E

To add a field, wouldn't it.

D

Why is it a breaking change to add a private field to a structure.

C

An abi breaking change.

D

uh So if you add up abi breakage, I'm concerned about, like my code, doesn't compile anymore right, because I was using this type on an on an avi boundary and now I'm not allowed to anymore.

D

Maybe I don't know, maybe that's not a real problem. I I'm I'm trying to understand. I mean.

A

I think I think your point is like: if you recompile the world, you don't care about the abi breaking change exactly, but you do care about this. Other change.

G

A

B

Have a I have a heart out, um I was debating whether you should take people's temperature or not about this overall at this point, um but I don't think that's a good way to end the meeting. I think we can do it on zulip, I'd like to.

A

Yeah I'd rather in the meeting and think about it. Thank you alex for your time here it's been very useful.

C

Thank you all for having me. Thank you all right. Goodbye.

C