Scale By The Bay 2018: Martin Odersky, Opening Keynote: New Functional Constructs in Scala 3
well thank you I'm very happy to be here I'd hear at Twitter and at scale by the way together which Alexei was right guy never did the two together I was often at Twitter and I think once it's gay by the way but never never together okay so I'm gonna tell you I can give a new talk today and I'm gonna tell you in this talk about some of the new functional constructs that are probably going to make it in Scala 3 and this functional mean I mean well they have functional programming and they work really well so I mean functional in in both senses of the word so Scala 3 what is that if in case you haven't heard yet so there's a plan have you have a plan there's a road map that has been out for a while to say well we are now at escala to 12 skaara to 13 is coming out shortly in January slated in January what's coming afterwards and what's coming afterwards will be essentially a big step it will be Scala 3-0 so there will be a parallel development scanner 213 well 213 there will be 214 and the purpose of 214 is really to smooth the migration to 3-0 so what will happen is that there will already be some joint components the first of these is the new collections which are also going to be in 213 and which we will take in 3-0 the next thing is the tasty middle end I'm going to talk a little bit about that and 214 will otherwise essentially the purpose of 214 is to put in the necessary things in place to make a migration two-30 easier and 3-0 is both a logical step in the evolution of Scala and to some degrees it's also a pretty new language a fresh version of the language and today it's my pleasure to tell you a bit more about that so why okay why why it's got a three but to ask that it's maybe better to go back to the roots and ask why Scala so what the point of Scala so for me the importance why Scala exists is really that it's a fusion of object-oriented and functional programming in a tight setting and I believe it was the first mainstream language to have achieved that and why that's important is that I believe that functions and generally functional programming is a very natural way to express the logic of your program in a very safe way to express the logic of your program on the other hand objects can be seen as a very powerful module system module systems but people tell you components are good mortal arity is good but if you look at what's actually out there what you have then most languages don't give you a lot of means to express components and modules but object-oriented languages do and they essentially the trick that scarra did was to say well we want to sort of drop from object-oriented languages all the craft which says objects need to have state and identity and all this stuff and just concentrate on the modularity aspects of objects and that led to for instance innovations like that objects could have type members which I don't have in traditional object-oriented languages but they do have in modular languages such as ml so that's the purpose of SCARA so and you could say that it was a big success well I'm talking here at Twitter so obviously that's one of the signs of be of a big success of Scala but more generally I mean here's a list of language features and they all now look pretty much common right closures yes or function types expression orientated language no statements typos local type inference pattern matching by name parameters X colon T syntax dependent types and so on so all of these are essentially features where you say yeah makes sense it's pretty standard by now but actually I would claim that scarra was the first language had introduced any one of these features in the setting that I'm talking about in a setting of a mainstream language with object-oriented features so Scala was first for every one of them and a lot of other languages have followed sweet which is great imitation is the best form of so languages that have followed sweet are c-sharp that was the first one in a lot of things and also other languages such as Courtland Swift and also Java Java is getting more of Java's features in each new release that doesn't make Java functional language by the way I think Java can get a lot of functional features like pattern matching and and lambdas but as long as Java has a separation between statements and expressions it's not a functional language think about it even something as simple as an if-then-else or a tri or a su or a switch there are statements that means that to execute them they have to mutate a variable otherwise a statement wouldn't do anything so if your basic building blocks only work by mutating variables how can you claim to be a functional language you can't so that's basically the thing that even though other languages can accumulate a lot of features I don't I think they miss the point of functional programming here cool so after this thing to say well why not rest on our laurels bye final stop here we did it lots of the industry is following sweet I could retire now right so well I don't want to retire so and I think that I've learned and generally we as a community have learned quite a bit over the 15 years of Scala usage and it's time to essentially apply what we learned in a language web if we know by now where things could work better let's do it let's do a big jump and essentially apply what we learned so what could we do well one thing is over the last 15 years usage patterns have evolved when we started basically the standard was object-oriented programming and essentially every little bit that we gave people in functional programming was like a big innovation and people we're puzzled what is this new thing now function programming is pretty standard and it turned out that some of the things that people do I mentioned algebraic data types or type classes or things like that are in Scala let's face it a bit clunky it wasn't that there was no primitive syntax for it it wasn't designed for that we were happy in the first version of gara that you could encode these things but the more people use a common pattern the more you want essentially a concise way to express these things and part of the thing the features I'm going to show you is about that the other thing is that scarra was a language that was designed for base basically extensibility so everything could be expressed as a library construct he could have Diaz ELLs so it was a very still is a very uh opinionated language he can write Scala in any style you like because the constructs of Scala are very very general and they're composed in very general ways and sometimes over the 15 years we have noted that there are certain things that we've learned and that some particular newcomers fall into where we would now classify them as traps so one of these things to be concrete is overuse of implicit conversions so that's some of the things where we say well we need to become we want to become now more opinionated we have essentially all the data to say well what is good Scala style let's give more guidance to programmers to actually write in that style in the same way we of course want to avoid puzzlers and pitfalls I love this Gala puzzlers book I really enjoy reading that but of course I make it my my ambition to eradicate as many of those and I'm sure that if we do that they will find others but let's let's keep up the work one thing that we can do now we didn't have first was foundations so over the 2008 to 2012 about we developed a calculus called dart dependent object types which is essentially now taken as the basis of what Scala is a bunch of papers no proofs that this thing is sound that these things make sense and that gives us a very good guidance to essentially say for any language features that we have do they make sense or don't they make sense for types that's very important that types really tell you something about your program not something something that is essentially true for the final value of the program so these proofs that types are correct they're honest they're called types down is theorems and we have a types on this theorem for dot and we can apply it essentially as a design guideline twofold to the full language and finally to bring out the simplicity of the language because I really believe that Scala at its heart is the simple language and I think I'm proven by several things first that I think a lot of kids like to start with skaara the other thing is we had a lot of success with our online courses by now there's more than a million people who have actually learned functional programming with Scala and you couldn't do that it's got AI was a very complicated language so imagine Scala would like C C++ that would be a very frustrating experience I think that that's what I really want to concentrate on to say Scala is fundamentally a simple language it allows to do it lets it allows you to do complex things with it which is natural and this is good but you shouldn't essentially confuse the basis with the things that you can do with it okay so that's that I just want to hear I can't tell you about all the language that would take all day so I want to essentially concentrate today on new features so what is what is new what are sort of the more exciting and important new features and I want to essentially just concentrate on those force I've talked about implicit function types a bit before but the other three I never talked about those are enums extension methods and opaque types so let's see what they are so let's start with enums so an imam at first glance it's an enumeration skaara didn't have numeration Syd had this inner enumeration class which was almost universally hated by people and everybody wanted essentially true Java enumerations so now now we have them so here's a simple enumeration that's what you write it in am color Ches red green blue so that's the three cases of enumeration and that gives you essentially values color dot red and you have operations on these like you can find out what it's ordinal value is and things like that so that's a very simple case of an enumeration you can make them Java compatible by extending java.lang you know so if your enumeration extends java.lang genome then it actually will be compiled as a java enumeration it will be visible from Java as an enumeration so that closes this interoperability problem we're up to now we have to say well if we need an enumeration that's understandable from both Scala and Java we have to write it as a Java Java class you can't write it in Scala so now you can write it in Scala so here's that that example also shows that essentially you can have more complex enumerations than just the three color values so enumerations can have parameters like here mass and they can have private but they can have members like a private field here and two public methods so and the cases of an enumeration they then essentially pass the parameters here in to lib to the base trait that's again pretty similar of the way Java does it in fact this example is taken from the from the standard Java documentation of enumeration so I just wanted to show you that yes you can express these things in scala as well good so that was the number one thing but and enums are actually more general than enumerations they also let you do algebraic data types the abbreviated to ADT s and also their generalized version GID T's generalized algebraic data types so here's an example of an ADT option the option that you all know so option you have how do you model that well you have a trait suit right and a case class sum and a case object none and they extend option op option with the right parameters right so now there's a more concise way to write that so here's what you can write right now you just say enum option it has a covariant parameter type parameter T and then you have two cases son which takes an X of type T and none which is the the option without anything you can as usual add methods to an option so you can methods to the option itself but not to the cases the cases cases are just a so any method that you have in the option goes applies to the whole option class so here for instance is a class is the option defined where you could then do a pattern match on the two cases that you have and you can have a companion object for your type so here in this comparing object you have the usual apply method for options which says well if it's now then you get none and otherwise you get some effects so this essentially gives you the analog of essentially a case class hierarchy and it's something that I think programmers write as a matter of course in Scala but they're writing quite often they're a huge number of case classes out there and sealed traits so having a DPS in your basic syntax makes that easier you don't need to write all these classes anymore you just write this simple simple ADT here's another one so result so a nicer version version of either with okay and error values so what's interesting here is that here the two values okay and error they both have explicit extends classes because in each case one of the two type parameters becomes nothing so for the okay case well you say that's a result of T and the error field is nothing and in the error value say that's a result of nothing and the error is essentially this of the type here this this e here so the usage is as usual you write result but okay and result of error so why have you chosen to put the cases inside the companion object you have to prefix it the reason is if you do that then you can always pull them out if you want with an import right you can always write import result or underscore and then you get them whereas if we had them defined them in the global namespace essentially is there's no way to squeeze the toothbrush toothpaste back into the tube right so once they're in the global namespace they're out there and you can't have the other choice so that's why we had the more conservative choice to put them in the companion object okay so you can also have generalized algebraic data types charities so the difference with a att agility is that a gelt extends the base class at a specific type so for instance for instance here you have an enum tree which is essentially a an expression tree an abstract syntax tree and T is essentially the type of the expressions so you say well here are some cases for this tree so true you say that's a tree an expression of type boolean and so it's false and zero is a tree of type int and the successor takes the tree of type int and gives you a tree of type int and so on and finally you have the if statement which is a tree of type boolean and two sub trees both of type t and it gives you a type T so the way you get a GE T is given explicit extends class and essentially tell you in what way it extends at what parameters it extends your based class here you have only one case which is actually parametric which means it's it extends the base tree at exactly the same parameter and that is if so for if sorry for if the extent extends clause here could be added and would just read extends tray of T because that's that's that's what on this is okay so here so here's a function for these that works on these trees the evaluation function that's as well it takes a tree of T and it gives you a tree at a T so that just goes through all the cases and in each case it will actually work out what what the right value is so you say here if it's a true then it gives you true if it's a zero then it essentially evaluates the value F here and ask whether it's zero and so on so the importance is this all works without type casts and that's basically the idea of these generalized algebraic data types and pattern matching for them that it makes that work good another interesting thing is so you say now with the same construct you can actually have ADT's realities and enums can you mix them well there are actually hybrids well you could say the tree was a hybrid there were some direct cases and others were indirect who could even argue enum result is that a et or a GTA charity strictly speaking it's a charity but you could say well because it's nothing here it's still essentially it's still not not a specific use case nothing on a covariant thing sort of encompasses or possible uses but what you can also do is you can mix innovations and a DTS and that shows why it makes sense to use the same construct for both so here you have a new version of your our color class which now has an RGB argument and it says well we have red green and blue which essentially give you the standard RGB values for that and then we have another case mix where essentially you just give the RGB value directly and that extends color of mix so that's strictly speaking not an enumeration because it has this third case but those three first cases they look a lot like an enumeration so essentially they're in the in the scarlet solution they they you have a it's fluid you can go from enumeration in the IDT's because we don't distinguish the two so one interesting thing to look at is what would this translate to so what it would translate to is Co trade color of course for the base class then for this one here you would have a case class and I should say for in terms all case classes that are generated are final so no no more this business that you can inherit from case classes enum enum case classes are final so that would be the mixed class that extends color in the way indicated here and then you would have three objects three instances red green and blue they share a single anonymous class that also extends color so one one thing that we have with these enums is if you have a lot of values simple values which are not parameterised and you don't create a new object or a new class a new class value for each of them they all share basically the same implementation and that means you can have large enumerations without generating a lot of code good so why add enums as a main principle reason really is convenience as I showed in the example they don't really add essential functionality you had a question yeah I was wondering what the corresponding yeah so the the giving the ordinal value of these things the integer value do you you have I think they would all have the same so one two three four you just essentially per case even if it's parameterised you have a value yeah it the values really only make sense for simple cases which are not parameterised okay so like I said enums are mostly for convenience an ADT can be translated to seal traits in case classes or case objects and simple enum values are translated to objects of a common class so why add them well it's less boilerplate then algebraic data types and at least four simple in terms none of the existing solutions was really satisfactory in particular none of them solve Java interoperability and these things so enums really give you basically that's that that missing piece of the puzzle okay status of enums is they emerged so they're in the current implementation the java interrupts still needs to be implemented and we have started to discuss them but generally I believe people are favorable to add them the second thing I want to talk about is extension methods and that's a fairly fairly new addition so an example of extension methods is this this one here so let's say you have a class circle with coordinates and the radius and you want to add an operation circumference which you want to call like like this circle dot circumference so the way you can do that is you can write circumference as an extension method it's declared as an extension method by using this as a modifier for essentially its first parameter so circumference says well it takes a C which is a circle and this is marked as a this parameter and it gives you a double and then it essentially has the usual formula and furthermore you put the circumference in an implicit object I'll explain later why why why you want to do that and if you do this then essentially you can just write it Circle dot circumference no no matter where you are you don't have to import this extension method specifically the fact that in this companion object and that that object is implicit is good enough so that means you can use it everywhere and extension methods are not magic they essentially just syntactic sugar for this thing here where you say well an extension method really translates to essentially the circle object and then you call the circumference method and you pass the circle as a parameter so you can use both calling syntaxes but the one with the dot here is of course more convenient okay so the visibility of extension so so far you say well that c-sharp d-sharp has exactly the same notion of extension methods but here's the one new thing and that has to do with the visibility of extension methods so there are two possibility and an extension method can be used if it's defined or imported in scope that's what C sharp does or an extension method is a member of an implicit value that's in scope and that's that's a new one so that's what we have used before so for instance if we write here a implicit object string seek herbs which has a thing that it takes a sequence of strings and it gives you essentially the sequence of longest strings in that so are all strings that have two that I can collectively have the longest length of all the strings in the sequence then you could use it like like this wherever you you are because essentially the implicit scope of lists looks for the sequence so if this is essentially defined code together with sequence then you get it with as the implicit object okay so why is this important so it's important because it works really well with type classes so here's an example of your standard example of type classes semigroup and mono Eid so that's sort of the first thing you always start with so semi group you say it's a trait it has a combined method and you want to use it in fix so you make it an extension method and mana it is a semigroup that has a unit value okay and money it has the supply method I'm getting to that and then you want to say you want to define an implementation so let's say strings are mono AIDS and you can do that by just defining an inclusive object spring mono it which is a mono a dove spring and you say well I need to implement those two operations so here's combined it's just concatenation and here's unit that's just the empty string right and now I want to have something which is generic over all ma needs so I did want to define a sum method which says if type II is a mono eight then essentially sum up the elements of list of the given list of T sum up all the elements okay so we start here to say sum of T context bomb on it so she must be ammonite take a list of t give me give me back our t so that's a fault left of the unit of the moderate instance of T so that employee goes to this apply method here and then the operation of the fault left is the combined operation here okay so why does that work I mean combined is an extension method normally you would say you have to import that from somewhere that would be really bad to import it because hey you don't know which combine you want it's a it's a general of T that is the T's are moderate but we say well as long as you have a mono eight instance in scope an instance of this guy here by a semigroup instance because that's where it combined is defined a combined is available as an extension method okay so do we have an instance of semigroup or mono it in scope yes of course we do there's a context pound mono it so that gives you an implicit parameter of type mono eight of t indirectly right and that parameter is of course in scope so i have a mono eight of t so I can apply combine like this so that's is essentially just a simple twist how we can combine type class syntax in in fix operations which was missing up to now so that essentially infinite varies of people and a lot of creative solutions like simulacrum which is a fairly complicated macro library that adds all sorts of magic imports to your program to make this work but it turns out with that simple twist you don't need that anymore it just works out of the box like what you want to do does it work on higher kinda types yeah sure let's do the standard higher kind of type example so we have a functor here a map function so a map now would say well it's an infix operation of course it takes that this which is of type F of a where F is defunct and a function from A to B and gives you an F of B and then a monad is a functor and it has besides map a flat map and a pure so a flat map is like map only that it essentially takes a function of F from A to F of B and it gives you an F of B and if you have pure and flat map you can actually define map already like this at this level so a map is then just a flat map where I apply the F that gives me an F of B and then essentially I call pure on the rest okay and then I can have researchy and the usual implementation of let's say a list monad for these things okay so all of this works sort of out of the box and very nicely so it actually turns out that to get type classes Scala already had basically everything in place there was just this little twist to say well we didn't it didn't really work very well within fixed methods now if now we have a notion of extension methods that works very really well with that and I think we can we can say ok now it really normal traits are type classes and implicit objects are instances of type classes and that's the end of the story so why extension methods well yes so then the method is still an extension method if you import it or you have it in scope somehow then you can use it yeah so basically you have this choice you either imported that sort of tea standard way that you know from c-sharp as well or other languages with extension methods or that's a new thing if it's part of an implicit object that you have in scope then it applies as well okay so why extension methods then well they give you a lightweight and natural way to get in fix syntax for operations then no wrappers and there's no boxing so you don't essentially have to essentially create wrapper objects to then call a method so they translate into essentially direct binary method calls you can define a single method instead of a binary method and then in fixed forward in an implicit class and that's what essentially makes the type class examples work so smoothly status so that's still an open pore request people like it generally and I think the the discussion has pretty much essentially come to a conclusion that yes that seems to be a good way a good way to do it they don't seem to be many more change requests for that so I would expect that to be merged relatively soon the third thing I want to talk about is opaque types so opaque types or opaque type aliases I should say give you type abstraction without any overhead so here's an example let's say we want to have a type for logarithms and of course a logarithm value that's a double but I want to have operations that are specific for logarithms so if I if I write type logarithm is equals double that's just a type alias but if I prefix that with the opaque modifier then I get a new type so logarithm is a type completely different from double which is implemented as a double but it's it's different and furthermore the fact that logarithm equals double is only known in the companion object of logarithms so let's have a look at that so generally if I use logarithm then it's a new type it's different from table but if I'm in the companion object so I am in the object next to it which has the same name then I know that logarithm equals double and that's why I can for instance define an apply method that essentially create gives me a logarithm of essentially a number and that returns a logarithm and here I can write math dot log D so method Rob D gives me a double of course and here I claim to return an a logarithm but that's ok because inside the companion object I know that they're the same thing so I can't do that and I can give you other operations as well such as exponent to give you a back the devil from a logarithm or I can give you one of these extension method objects that's the object we're now introduced to double plus and star as operations directly on logarithm using our syntax of extension methods here so the plus method would take a logarithm and a logarithm and it would essentially what it would do is it when she takes the exponent of X and Y and takes the logarithm of that okay so if you do that then you have essentially a safe way to use these logarithms so essentially you can multiply them you can add logarithms and these are essentially all safe operations because you have to find them in the companion object what you can't do is you can't do anything else so you can't assign a double with a logarithm or a logarithm with a double you can't take logarithm times two because two is not a logarithm it's a it's an int which can be writing to a double and you can't do L divided by L 2 you can't divide two logarithms because there's no operation for division in this compounding object okay so one really nice application of opaque types is immutable rates so opaque types in may enable immutable arrays and here's a way that can be done so we can now define a type opaque type I array for immutable array and that's the same thing as array of a okay and then what operations do we add to I array so they again go into implicit object well we would have lengths like for normal array and apply so indexing like like for a normal array but no update so because the array is immutable so essentially we take lengths and apply from the normal arrays and we drop update and here's the definition there's nothing much nothing very very amazing about it so we take an immutable array and we cast it to an array because hey we know it's the same thing we so we can do that and we just forward to the same operations on either on the normal array length and I that means we can now have a usage like this we can create an immutable array we take its length and we index it but we can't change any elements of it okay so why is that important I think it will be really enable lots of really good good things the problem of a language like Scala that operates in on the JVM and has to interoperate with Java is really that there's a tension of having a functional language in an imperative environment and for that reason arrays are of course sort of the dominant ubiquitous simple collection most performant collection that you have on the JVM but in jar in Scala we don't use them much because they are mutable so they're dirty so we shun them and we want to essentially have higher level operations like immutable sequences and maybe sometimes they map to arrays in the end everything maps to arrays but there are layers and layers on top of them so that's a problem because it actually introduces a performance overhead these things are not as fast as they could be and it's also a problem because you can't interoperate with Java very well because Java uses essentially immutable immutable arrays for these things so with immutable array sort of we break the tension and say no actually we can embrace arrays arrays are good because we don't essentially we can take away the capability to take them so we can essentially have these things safely and I think that in the end we'll make a lot of things worked worked much much better yes yes the high tea type class instances yeah yeah it's really treated as outside the companion object they're treated as two completely different types okay so one discussion that we had so OPEC types have been introduced already a while ago more than a year ago I think by Eric awesome and Jorge Quintero and have been made a sip scholar improvement proposal and it was sort of lingering for a while and we went through many many redesigns the first design was really a version of value classes so you could ask well since we have value classes why why opaque types because after although there are overlaps between the two so both of them introduced a new type and both of them avoid boxing in some cases so the main difference is only your peg types guarantee to never box rather classes don't box if you're in a monomorphic context so you know exactly what class you have but when you go generic they have to box and because you they guarantee to never box you can do things like immutable arrays where it's very important that you say no matter what happens I need to have the underlying representation of a Java array not a wrapper of a Java array because otherwise I can't interrupt so that's I think is very important the other downside of value classes is that the boxing model is sometimes hard to follow so for instance value class instances have to be boxed if they're stored in a collection or in an array if they're passed to a function value or return from it and if they're elements of a couple in all these cases basically we lose the monomorphic context and we have to box a value class and that might be surprising for some of you who didn't expect that those who thought that well that it classes there should not box in all cases but unfortunately there are many cases where they have to box so value classes can on the other hand only value classes can customize to string so seconds 12 can princess 12 seconds and only valid classes allow type tests so if you compare them then I said well given opaque types actually value classes have only very limited usefulness like giving a to string and type tests like that somehow doesn't feel to justify a feature in a language and so we could drop them we could drop them but except for that value classes are in the works for possibly a future version of Java that's a project Valhalla that would bring back valid classes but in a sort of more powerful form where value classes are sort of general structs that can have many values but that avoid boxing so if Valhalla comes up with that we want that that's a very useful construct but as long as the JVM doesn't support it with there's nothing we can do about it so if project Valhalla comes to fruition then that would give us a clear separation we say for assembling multiple fields in a struct without boxing use a value class for hiding the representation of a single type use opaque types because only opaque types guarantee no boxing in all cases so for that reason value classes I would call them currently parked so they're not deprecated they will not be deprecated they will stay around but we would sort of encourage all existing usages to consider who paid types as essentially a more and more solid and more performant alternative okay status okay of opaque types is also merged and under discussion already for a while by the sip committee who's generally in favor since I'm almost out of time I will skip implicit function types I've talked about implicit function types before so I will do a quick thing but I do want to do the last example here because it's cute and it brings it ties together several several things so here's an example that ties together extension methods opaque types and implicit function types so what I want to do is do you know about ensuring who has used ensuring already it's okay couple of you so it's in a standard library it's sort of in the contract thing it's like assert and require and ensuring so assert is just an assert you're right require it's an assert where you essentially want something from an argument and ensuring is essentially in a search where you state something about a function result so you use it like this so list of one two three some dot ensuring result equals six only right now you don't use it like this because you can't talk about the result like this you'd have to pass a lambda which says lambda result result equals six and that's kind of annoying right I mean you should you should say well in an ensuring result means the result of the functions can be somehow wire up things that this works and furthermore I want to wire up things so that this works as basically no cost so this thing should not cost more than just essentially taking the result at having a single assert and returning the result in three statements okay so here's how we can do this so we would have an in fixed method ensuring is an in six method so make it an extension of method implicit object ensuring it takes a T of arbitrary T and it takes a condition and that condition is now an implicit function from wrapped result of T to boolean and what it would do is essentially it wraps the X in this type wrapped result I search the condition and returns the X why does it so this looks law sort of like our expansions but why does it wrap the result why grabs the result because the result type is actually an implicit and implicit want very specific types otherwise you get ambiguities and you don't know what happens so having a generic type parameter T as an implicit is a terrible idea so what we want is essentially a very specific thing to say well this is the result type so that now when we have the result method that we can use in this thing well the result method just says well I need a wrapped result of T and I just tell you what it is I unwrap it and give you the value so that's how I can get at the result okay so the wrapped result implicit here is basically so that I can have a specific type that means results but I don't want to pay for it I don't want to box it so I don't want to I the ideas I don't need to do that because it's animate type wrap result of T is T and here's my rap and my unwrap method so I can back and forth but in the end all these things will compile away I mean it's it's just a type Elias so the advantage here it's absolutely zero overhead so if I have after some trivial in lining my ensuring thing would look like this and if I do some more in lining than absorb then the result goes away because after all result of an implicitly evidence of a result it's just ER so it's just the identity so that goes away and finally I have to look at I can look at ensuring well that's a really simple method as well so I can inline that and I get what I started with so I get essentially I do the sum of X at least one of one two three some assert x equals six and return okay so I will skip ahead because I'm seriously out of time it seems status of implicit function types its merged and approved in principle by the subcommittee I just want to say quickly finish to talk about essentially where we are with respect of tooling so we have a new compiler rich IDE support you have a rapper and a doctoral and all the tooling is built around tasty so tasty is a tight abstract syntax trees which is a new serialization format for Scala so it gives you complete position and type information all the implicit sar made explicit so basically it just tells you in exact in great detail what's essentially in your source and and in how the compiler sees your source the challenge is to make it compact because once you do that my initial thing was this will surely be at least ten times bigger than source once we store all this information it actually we work very hard to make it compact so the end result is it's about the same size of source and that makes it perfectly acceptable I think as as essentially your standard format so they the scholar at scholar 3 compiler will essentially produce a full tasty tree for every file it compares and that thing then can be used for many many different things so here's what it's used for currently so we have the new Scala compiler it generates the tasty and from the tasty generates class files Java it classifies it also reads the pasty for a different compilation units if you have separate compilation and the compiler needs to find out what's in this other compilation unit and it consults the Tastee for that we have a proof of concept for Scala to to do the same thing so that's currently in proof of concept stage has to be worked on but the ideas that scholars scholar - will do the same thing it will produce the same tasty and read the things from the same format why is that important because that means that we will be able to freely mix modules written in Scala - in Scala 3 they have the same intermediate format they can essentially both read what was in each other things that we can we can compile Scala - in Scala 3 together the other thing usage was tasty is if for the IDE where we use LSP the language server protocol to actually implement a an IDE for vs code and I think for some other editors as well and LSP essentially lets us consult what's in the program so you can use it for instance for find references and things like that ok now the vision is that this thing will also be the central engine on which you put macros analyzers optimizers essentially all of that will work on that format why is that good but because it's standardized it means that you think of tastings sort of like the Scala bytecode we won't change it from one year to the next we will very very carefully evolve it and we will commit to not breaking anything so in the future I think ok I guess every one of you is already faced the binary compatibility problems of some sort or another I think in the future that's an answer for it because you say well for tasty tasty will be kept stable so that means that also if you have artifacts like your your modules if you distribute them then taste is the one thing that can be kept stable and that then essentially can map into essentially whatever back-end you have whatever is the latest Java version or also to JavaScript also to to to Native and furthermore it's also a possibility then to say well if I essentially need to upgrade to a new format I can essentially recompile my versions directly without without essentially invoking the front-end compiler I'm the ideas that all of this would be integrated in the build tools that would do it automatically cool so migration so lots of new features but how do we get there so I think that it's actually but the people are sometimes scared and say Scala tools kind of three how is that gonna be better than Python 2 in Python 3 that didn't work out so well so I so hopefully we thought very hard about that but I think we have a couple of things in our favor and those are specifically static typing and binary compatibility so static typing because for us essentially any incompatibility it's a type checker that will catch you out you won't see these errors in at runtime by production failing because you get your Testament very incomplete in some way so there's much less fear to upgrade if you have a strong static type system than a dynamic typing thing and the other is the binary compatibility which is enabled by the tasty so already today we can have dotty modules which is like the current project name for Scala 3 use Scala two modules for instance our compiler uses the Scala 2 standard library we haven't recompile that that's just the 212 standard library so we can do that but in the future with tasty we can actually do much more so we can start with that and then we can have maybe a new foundation library that somebody thought it's cool already wrote in Scala 3 it can still be used from Scala too because essentially both use the same interchange format the tasty and therefore they're compatible so that means you will be able to migrate whatever modules you have at the speed that you think is appropriate without having to look at any dependencies the dependencies can be Skeletor scholar three it doesn't matter and likewise for your clients so timeline it's very ambitious so what we want to be currently in the face where we flesh out the design get feedback do refinements and we have releases to support that there and come under the name dot e0 Doric so right now we have 3000 11 every six weeks we have a new one in about mid 2019 we want to go into feature freeze that means no new features everything so far is essentially fleshed out and implemented and then we want to take a gear for stabilization the stabilization will mean right the specs get the docks out right the port library modules to use the new features work on getting out the bugs getting more tests and things like that so so that would put a release than one year later in mid 2020 so that's the plan for it we need help for that so it would be great if you could already start pouring libraries and report back what you want and maybe also join the team below Sun is a nice place and we're actually looking currently for compiler engineers to help us in that task so there's much more to discover if you want to find out more so there's a dirty documentation that I can't get to because I don't see oh yeah I do I can't get to and if you have questions or remarks I'm here all day today and sometime tomorrow as well please let let me know and let us know what you think thank you