 So, let's see, Maurice more or less tricked me into this, he came to say, hey, we haven't seen that, do you have something to talk about in the set? Yeah, no, but we could make a Q&A. Yeah, so we wanted to release 050 in May or something like that, but then some things came up and some other things came up, but we finally released it some weeks ago and we even released 051 in the meantime, so we're making progress. I don't know, are there already some questions, otherwise, oh yeah. I don't need a mic for that, but I was saying maybe you should, for those who are not in DevCon, maybe you should summarize what is new in 5.0. Yeah, so most of the changes were already part of the previous releases and you could, I mean 050 is mostly just enforcing you to be more strict, more explicit about things, and most of these things you could already activate in older versions with the pragma, and among these are explicit visibility for functions, a special keyword for the constructor, a special keyword to emit events, forcing you to provide the data location of variables, so either storage, memory, or call data, because that was always a little bit confusing, because the default was different depending on the context of the variable. What else do we have, I mean ABI encode and ABI decode, that's more like features, so you can now get access to the ABI coder from within your code, so you can turn a byte array into structured data and back. Scoping? Yeah, we have seen 99 scoping for variables now and not the weird JavaScript scoping anymore, but I think there was a question. Yes, so I tested 0.5.0 and I really like features, the only thing I hate is the address table, because yeah, I tried to port my project to 0.5 and there were some weird addresses that came up, and why am I not allowed as a developer to cast an address to address table, but yeah, it's not allowed to cast you from address to address table. So address table was something that was not part of the previous reases and the reason we added it was because, so contract types, they have fallback functions and the fallback functions can be payable or they cannot be payable, and depending on that property you can send either to the contract or not, so the send or the transfer function is only available on contracts that have a payable fallback function, and one change we did is we removed all the address members from the contract type, because you might have a function that is called transfer on your contract and that would conflict with the function that is part of the address type, and so if you want to use transfer, this is a little bit, needs a little bit of working out, so and now this effect of whether the fallback function is payable or not, that is lost, so yeah, so remove the members from the contract type, so you have to convert the contract to address first to use the transfer function, but if you convert it to address then the fact whether you have a payable fallback function or not is lost, and because of that we introduced the address payable type, and so contracts with a payable fallback function can be converted to address payable, contracts without a payable fallback function can be converted to address, okay, that's the reason why we introduced it and we did some testing, so we run the compiler against quite a lot of existing projects and we needed to make these changes to the existing products before we could run the compiler against it, and while updating these contracts we noticed that there's not too much you have to change, and the reason is that usually you use the transfer function, for example if you use the with drop-in then you call the transfer function or not on address that is stored somewhere, but you call it an MSG.Center, and MSG.Center is payable by default, and if you really want so you can convert address to address payable when you go through the digit type. Yes, I did that. Okay, and so my question would be, what are the situations in which you do the version? I inherit a contract from some other source, some library or some let's say open Zeppelin or anything, and there the address is specified as address, not as address payable, but I have one specific use case where I need to pay something to this address that was specified in the library. That's basically, there was one thing where I wanted to self-destruct something to the owner, and I imported owner board, and in owner board there is, in owner board it's an address, and I had some part of the code where it says self-destruct to owner, and that wasn't possible. And why do you know whether the owner can accept Ether? Actually, I didn't even care because there shouldn't be any money on the contract anyway, but I needed to provide some address to the self-destruct function, but anyway, this is a very different situation. But yeah, did you need to make lots of changes there? No, this was the only fringe scenario where there was some problem with the address payable function. Okay, so in general, you probably know that, okay, most people who write compilers write them in a self-hosted manner, which means that the compiler is written in its own language, so in the language the compiler is to compile. This creates tons of problems and just, yeah, but anyway, even without these problems we can't do it because running the Solidity compiler inside the event would be kind of weird, and this leads to a situation that we as compiler engineers don't really use the language a lot, and because of that we always are happy about any feedback that we get from the people that actually use it. I think I talked too much, right? That was another question. Was there? Do you have a question? I think I saw a hand somewhere. So what question, guys? All right, just a quick question. Could you explain the point of view? What? What about it? What's the point, really? So that's something I noticed in your talk. You were saying something like, perhaps I got it wrong, but it's something like we still need the EVM and Solidity due to some reasons, and WebAssembly will not destroy it, and the thing is, the reason for you all is to be able to compile Solidity to WebAssembly. Right, okay. So we're preparing for, I don't know, already over a year now to compile Solidity to WebAssembly and you will see the intermediate step to go there. And, yeah, I mean, if you say you and you mean Solidity in LandAssembly, then this is another use for it, which allows you to write more low-level stuff that is not available in the language. Yeah, and the other use of UL is as an intermediate language inside the compiler, and the cool thing is, so with 0.5.0, we, getting back to the topic, with 0.5.0, we disallowed the so-called loose dialect of LandAssembly or of UL, and the strict version, so the difference between loose and strict is that in the loose version, you have direct access to the stack, you can run, you can use opcodes that manipulate the stack, and in the strict version, we only have variables and function calls, essentially, and this fully abstracts away whether or not there actually is a step. And WebAssembly does have an expression stack, but it's different than, so yeah, it also has native function calls, and because of that, the stack is different from the one that is used in EVM, and if we introduce UL as an intermediate language, then everything will compile to UL, and there, we don't use any features of the EVM, and instead, we don't use the stack, and because of that, we can easily compile to both WebAssembly and EVM. Does that answer your question? Yes. Do we have some more questions? Yeah, I just want to ask if having an estimations plan, 0.5 is going to replace 0.4 whatever, or are they going to get along together, or 0.5 is going to take over 0.4 somewhere, and what is the plan to have? So we have no plan to maintain older releases. I'm not sure I understand your question. So 0.4 is over, so there is no going to be any more. There won't be any patch releases for 0.4x. Okay, because so far it's quite relaxed. I think we had no release for six months, and that was because we were preparing for the record change. So there was one intermediate backfix release, but that was just to fix a very important one. So can you say something about how the inheritance structure works? Because this changed quite dramatically in 0.5. I saw that you're now able to inherit automatically generated getter functions in 0.5. So it used to be that automatically generated getters don't comply to the interface they inherit. But what I also didn't see is that you can inherit interfaces from other interfaces. We didn't make too many changes to inheritance, actually. So the getter functions might have been one of the smaller changes, and actually in 0.5.1 we added another change that allowed more function overwriting. I think that the main reason that allowed getter functions to override interfaces was that interfaces are now required. So interface functions now have to be external and cannot be public anymore. And we allowed public functions to override external functions. But I thought that was only part of 0.5.1. Do we have some more questions? Maybe one last question? Perhaps one word on inheritance in general. So we plan to do an overhaul of inheritance in 0.6.0. And the idea there is not to change the inheritance model itself too much. So we will still keep Python C3 linearization multiple inheritance model. It's more likely it will be more restrictive, especially when it comes to overwriting. So you can't just have two functions incoming from two different base contracts, two functions with the same name. And you will have to specifically state whether you want the function to be overriding or not. I just want to ask another question. I'm not a developer and most of what you just said I didn't understand. So what is the state or what's going to happen with WebAssembly? I heard in a podcast that there was some plans that in the end we will have different charts on Ethereum and some will run on the EVM and some will run Wasm because I guess converting Solidity contracts into Wasm is not really an option. So I just would like to know how that will all work out like the coexistence. So on the Solidity side the plan for next year is to be able to compile to eWasm. So that's not a problem. On the chain side, I mean the compiler just will generate some bytecode and you can use it on every chain and on every sidechain, whatever you want. Yeah, I can't really say much about the adoption of WebAssembly in Ethereum Mainnet or Ethereum 2.0. Yeah. I'm personally worried about claims about performance because that hasn't been really vetted yet. But it will probably be faster due to it having native functions and it having 64 bit types. We have to see. All right. Do I have maybe a last question? No? Well, I have one. Are you taking one more question? Yes, but I'm out of smart questions. Yeah, so it's not really taking more questions but you said from 4 to 5 there's quite a lot of changes in the language and I would be interested if you had a couple of words of wisdom of how you handle potentially compensability breaking changes. How did you handle that? How did you manage that? I'm not sure if I really understand the question but I can say something about breaking changes. There are different types of breaking changes. There is the one breaking change which is a contract that compiled before does not compile anymore. That's a easy breaking change but there are some breaking changes also between 4 and 5 where the contract compiled before and it still compiles but it's behavior changes. These are tricky and they should be kept to a very, very basic minimum when everyone using language has to know about them. I hope that's the case. Was that basically your question? Yeah, it's more like did you document those changes, for example, those second case changes? So there is a... We have a dedicated page in the documentation that says these are the changes and this is what you have to do to your source code to update it to be compatible 050. So I hope that documentation is enough for everyone. If not then please talk to us. We didn't get too much feedback on that yet so I'm not sure if that's a good or a bad sign. We have used different changes. Okay. Perhaps also some meta information that came out of the audit with what do you say, had made, whatever, that was made. They said we should make breaking changes more often and we don't have a specific plan yet but we're thinking about perhaps every 2, 2, 4 or 6 months. Yeah, let's see how that will work out. So the definition of a breaking change is that contacts need to be rewritten. There is at least one contract that does not compile anymore or at least one contract whose semantics change. What happens when they release do these contacts go offline? It's just about the source code so if they have been deployed then it's not source code anymore, it's bytecode and their breaking change is a hard fork. So that's out of the scope either. Otherwise it's a break in the runtime. Do we have another question? Okay, I think the question answer session is over for now. Thank you so much, Christian.