Solidity 2020 Roadmap by Chris Reitwiessner

okay so I will talk about syllabus roadmap for 2020 having said that the solidity project is not a project that has fixed roadmaps and this is also one reason why we're having this summit here to yeah talk about future features and agree if we want to have them and how so there is one thing we very much focus and and that is completely set and that is the reimplementation of the code generator using our intermediate language you'll we are currently yeah roughly at 50% implementation of the full language features yeah we'll talk more about that later and then a second important thing is the SMT checkers or our formal verification tool we would also like to get almost full coverage of the whole language until the end of the year but yeah for both these topics we'll have to see how far we get and then maybe more interesting for you we plan to have at least one maybe two breaking releases with new breaking features some features can of course also be introduced in non breaking releases and yeah I would like just like to highlight some of the breaking features that I myself find interesting and for one this is a feature that makes the copying semantics more explicit and also makes at least reference types immutable by default so if you want to have a memory array where you can change values then you have to specifically mention that at the point of declaration there will be a discussion session on the topic on day 2 7:00 p.m. CST and then another topic safe math by default this is arithmetic overflow checking at runtime by introduced automatically by the compiler we were we did not introduce that for a long time for two reasons the first is that we think that the existing optimizer has a hard time dealing with that and the second is that it can introduce new bugs but we see that everyone is just using the safe math library and because of that we would like to have discussion on whether we should introduce that by default or not and that discussion will be on yet today at 3:40 p.m. then another interesting feature is called data variables we already have the the call data location specifier for function parameters of external functions but we there's no really big reason why called it I cannot be used for any other variable so local variables and parameters and internal functions and I think this could yield nice performance improvement because it does not so because when you have a memory variable and just use that for call data content then you always need a copy to memory which could be unnecessary and it in addition it guarantees that you can modify such the content of such variables then another interesting topic is language server so during the last actually it's last week's few months we noticed that people have a hard time debugging solidity code and just in general working with so in general the development process could be better and because of that we thought about implementing a language server as part of the compiler language server is an initiative started by Microsoft to standardize the interface between compilers and debuggers and I des and as soon as you have in a language server for a language implemented then any IDE that also has language server support can work with that language so this is a nice generic way to provide access to compiler features and the cool thing about that is things like go to definition are probably rather easy to implement for us and while several IDs already might have that feature the interesting thing about implementing it in the compiler itself is that when you used to go to definition future in the IDE it uses exactly the same code that does the identifier resolution during code generation so you're 100% sure that it goes to exactly the same definition that is referenced in the final code yeah tomorrow at 4:30 p.

m. and then yeah also in the same direction we want to improve the output of the compiler that can be used for debugger or more general I don't know how would you call it code inspection routines this is an initiative that was started by the truffle team last year or maybe even two years ago and some more teams joined in the meantime and I get the discussion about that will be today at 8:50 p.m. and yeah two things that we always do in parallel regardless of specific features is improving the new you will baste optimizer and improving the webassembly output and these two are kind of interconnected and yet talking about you'll let's go a bit more to detail about you because I there are still some misconceptions around about Yool Yool is a simplistic intermediate language we have been using for quite a long time at least for parts of the compiler and the idea behind you'll is that it should be human readable and not only machine readable and we hope that we can build our you'll optimizer are currently yeah we hope that it has that feature to be to generate code that is still readable by humans even after the optimization there will be two sessions around you'll one of them is about you'll plus that is an extension of you'll develop an ik Dotson and that is today at ten past five and then right after that at five forty a discussion group about new features for you'll and yeah our hope with you will is that it allows people to understand much more what is happening behind the scenes in the compiler that it allows to actually inspect the generated optimized dual code that is then very very close to EVM bytecode and it allows this dual code to be fully audited and because of because of that you do not have to rely on yeah a definition of the solidity language or absence of bugs in the compiler yeah you just could you check the time okay yeah and the the nice thing about you'll is that it has [Music] very few features but it is a structured language so it has four loops user-defined functions and so on and it is extensible and typed which allows it to use for different different purposes for example we're thinking about yeah adding memory allocation features through the optimizer that allows lifetime tracking of memory objects and out-of-bounds access and so on and yeah all this will hopefully be covered in the discussion later today as far as the yule code generation in the solidity compiler is concerned we are pretty far already so early I said 50% but yeah 50% of the features does not mean 50% of the small contracts out there so please try it out whether it already works for your smart contracts and you can try it with so C minus minus IR this shows you the yeah originally generated intermediate code for the smart contract but this is usually not something you would like to look at because we are writing the code generator in a highly modular way which means we have many many different functions for each time a functionality that that constantly call each other and the optimize of it will in line all that and most of these functions in the end just do nothing so what you would like to look at is the output of salsa - mums optimized - - IR - optimized this is a bit weird the so if you just use - - IR - optimized it will show you the intermediate code after optimization but if optimization means no optimization so if you did not switch on the optimizer then it will be the same as before optimization so please always use these two flags together and having said that you will output from solidity is still experimental so we might change any of these flags in the future we might introduce different built-in functions and so on so this is still experimental while you'll itself is not experimental anymore so if you want to yeah take you a code and use it as input then this is pretty safe I never say it's foolproof because yeah no software ever is but it should be pretty safe and it's being used out there already then one last thing about the SMT checker there is a session that they - on 6:00 p.m.

about yeah more or less formal aspects of solidity a formal specification language and I'm not the expert on the SMT checker in the solidity compiler that would be leo but he told me that it can do already quite a lot it does function abstraction which is really nice so it does not always so when you call a function internally it does not always inline it but instead it tries to infer properties of the function and just use these functions and I think invariants are not yet implemented but this is something on the roadmap and also one of the main topics of this session on there too