4 ms·

That's awesome! I must have missed that announcement where it will come sooner than the next several years. Can you point me to it? The last I heard was in the

• frowaway001 12y ago
  I think this is the announcement I had in mind, I'd just take the published roadmap with a grain of salt, because usually things ship when they are ready and fit into the whole picture. As seen in dotty, the basic stuff around union types is already working, so I'd be pretty surprised if it didn't ship earlier, especially because there is a demonstrated need for HLists, and shipping HLists without union types ... could be done, but why? Additionally, a lot of things mentioned in "Don Giovanni" are already ready-to-ship today (sans a few minor requirements). For instance Giovanni's 1.3, 2.1, (some parts of 2.4 already shipped with 2.11), (approaches for 5.1 were already discussed and benchmarked), 5.1/5.2 (will happen when targeting Java 10). My recommendation is to take that roadmap as a bottom line, but be prepared for drastic changes. My current guess is that if work gets done at the current speed, it might be possible to move things to earlier releases and subsequently eliminate a whole release in between, e. g. shipping the features of three releases in two. But that's all just my educated guess.
  • benjaminjackman 12y ago
    Sweet I will definitely check out dotty then! Thanks for taking the time to catch me up. I'll move to guardedly optimistic we'll see union types in Scala this decade :) Are HLists shipping soon too? I was under the impression they would have to wait for Giovanni as well, I need to start reading internals again I guess. Re: 5.1/5.2(miniboxing/value classes) => Java 10 is going to get structs then I am guessing? I read the rough draft of that a few months back, looks pretty complicated but it seems to have thought through the corner cases. It is a godsend if you need that level of performance. As an aside: it's funny you mention 1.3(Procedure Syntax) and 2.1(Result types are mandatory for Implicit definitions). They are actually the two changes that are far and away the worst for us from Giovanni so it's frustrating to see them be implemented first. This is because we have thousands of lines for our serialization framework that run afoul of 2.1 which look like this: object Foo {implicit val ser = SerBuilder.forCase(this.apply _)} case class Foo(x : Int) And thousands upon thousands that use procedure syntax. (We should write with less side-effects, I agree.) However when we do have side effects we want them to visually separate themselves from all the non unit returning methods. Procedure syntax does that and conveys the inherit difference between a procedure and function, via quickly scannable visual signaling. So that the procedures don't blend in to the : Blah = .... sea of functions, and all while being 8 less keypresses.
    • frowaway001 12y ago
      I don't want to cause false hopes, but I think the roadmap is quite conservative and designed to no disappoint people if things don't go according to the plan. (Especially with people complaining that the next few releases don't improve things they care about ...) HLists are planned for Giovanni, but I considering that even Typesafe-related projects are now either depending on shapeless or shipping with their own HList implementation, I think there is a lot of desire to standardize on one (probably compiler-known (to deal with the huge increase of compile-time)) implementation. As far as I know 1.3 and 2.1 are blocked by the need for a migration tool. Scala developers are certainly not expected to fix their code by hand, but let a "go fix"-like tool handle everything for them. I think having the IDE assign Unit-returning methods a special color would retain some of the benefits of procedure syntax while fixing the issues caused by procedure syntax. Tests are one case where procedures might be heavily used, but I think this can either be handled by a better API. (I never understood the reason why testing frameworks required the "assert + return Unit" pattern. Why don't they just allow tests to return Boolean and get rid of the assert boilerplate in simple cases?) def someTest("foo should equal bar") { assert(foo == bar) } | v def someTest("foo should equal bar"): Unit = foo == bar | v // or even: `foo should equal bar` test { foo == bar }
      • benjaminjackman 12y ago
        Well having just written a unit test framework[1](because we needed one that cross compiled to ScalaJS and couldn't use utest for reasons relating to difficulty of getting it to produce reasonable output for all our legacy tests) I side stepped the issue by using a FunSuite style. I prefer using a series of assertions to simply returning true or false because often times you want to put multiple assertions in the same test. However the unit test case alone is a pretty valid one. I am all for making it a compiler flag (opt-in or opt-out). I still haven't been given a single real problem with procedure syntax other than "it's different" and because "it's different" it therefore confuses new users and increases the complexity of the language. I don't think that follows logically and in my experience empirically. For the programmers I have introduced to Scala, or that I have talked to who use it none of them have gotten caught up by procedure syntax. This includes traders taking the Scala course that have never programmed before in their life. The color/formatting is a good idea, that should just be done already. However given that the intellij guys still don't give an option[2] to color member variables defined in a constructor differently than ones defined in a method I'm not hopeful about that. 1: https://github.com/cgta/otest https://github.com/cgta/otest 2: https://youtrack.jetbrains.com/issue/SCL-2811 https://youtrack.jetbrains.com/issue/SCL-2811