SIP Meeting Minutes - March 11 2020

Language

    Minutes

    The meeting took place with the following agenda:

    1. Quick setup, reviewing expectations for the retreat
    2. Review a list of “easy” dotty features/changes (see section below)
    3. Review enums
    4. Review creator applications
    5. Review @infix and @alpha
    6. Review dependent and polymorphic function types

    Date and Location

    The meeting took place on the 11th March 2020 throughout the day at EPFL in Lausanne, Switzerland, and Zoom.

    The meeting wasn’t broadcast.

    Minutes were taken by Dale Wijnand.

    Committee Attendees

    Sitting in

    Not present

    Miles notified the committee that he wouldn’t be available. Josh, Heather, and Iulian were all unable to participate because of coronavirus-related travel restrictions and disruptions.

    Proceedings

    Expectations

    • Martin: The plan is still to release Scala 3 this year, at the end of December.
    • Martin: However, TASTy won’t be stable until 3.1 - it won’t be a 3.0 promise.

    • Martin: Ideally the features would be voted on with the following 3 outcomes

    • accepted, either for 3.0, or some future 3.x release, depending
    • accepted, but put behind some kind of “preview” flag, like Java is doing
    • rejected
    • postponed to after 3.0

    Review a “easy” dotty features/changes

    This is the list, with any notable comments added.

    We called features ‘easy’ if there was already substantial agreement in the pre-retreat straw poll we conducted beforehand, and if no one present felt that feature needed extended in-person discussion.

    • Context functions
    • Drop auto application
    • Drop auto tupling
      • Martin: this is probably the most breaking change, so weakly against it
      • Seth: could it be behind -Scala2? Martin: no, that would be difficult
      • There’s some difficulties in implementing a rewrite rule for it
    • Drop class shadowing
      • Seb: this is binary breaking for existing libraries
      • Seth: it’s already deprecated in 2.13.2, which ships shortly
      • Seth: so let’s make it strong (not under -Xlint) w/ opt-out
    • Drop compound types
    • Drop DelayedInit
      • most of the committee is for dropping it
      • but a number of usages of it have been reported
      • Guillaume: the implementation isn’t a big deal, but it affects TASTy
      • ScalaTest, specs2, and cats-effect use it, but our understanding is that they can work around it
      • Let’s drop it and hopefully someone can write a compiler plugin for it
      • Lukas: DelayedInit was the source of lots of bugs in nsc, most fixed by now, though
    • Drop do..while
      • Seb: it’s added because of indentation syntax; how many more like this one?
      • Martin: actually it’s mainly because of the new control syntax
    • Drop early initializers
    • Drop existential types
      • Guillaume: some cases can be replaced by using opaque types, with explicit wrap and unwrapping
    • Drop non-local returns
    • Drop package objects
      • Lukas: what’s wrong with package objects, or it having parents? Don’t exports suffer the same problems?
      • Seb: package objects are the only thing where you can extend something “in you”. Exports don’t have that.
      • Lukas: what about implicit prioritisation w/ exports?
      • Martin: there’s a change in implicit resolution so you can add dummy implicit parameters and prioritise those (with companion object prioritisation)
    • Drop procedure syntax
      • Guillaume: it’s dead
    • Drop Symbol literals
      • Seb: it’s basically done
    • Drop XML literals
      • Guillaume: Dotty supports XML literals (under -Scala2 flag?)
      • Seb: it doesn’t leak into binaries/TASTy, can remove later
      • Nic: we have a replacement but just without unapply/pattern matching
      • Martin: and that isn’t used much, so you’d just need to do something else there
    • Eta expansion
      • no _ any more
      • Gui: issue with println, you println(myMethod) and it’s not a type error (b/c no args) it prints the function
      • Martin: multiversal equality fixes == for functions, previously always false
    • Implicit conversions with Conversion
    • Implicit resolution changes
      • Seb: so many changes
      • Gui: need to discuss them 1 by 1, important to discuss them individually
      • Gui: some are common sense, some are for ambiguity, adding parameters (prioritisation)
      • Martin: would be good to discuss the details with Miles
      • Seb: shouldn’t be in the “easy” list, then
    • Intersection/union
      • Seb: no choice, and it’s good
    • Opaque type aliases
      • Seth: pushback from at least some users, don’t ship, wait for Valhalla
      • Seb: they’re not to replace value classes. They have the runtime characteristics of type aliases.
      • Lukas: can it be ported back to nsc? Gui: no, sadly
    • Open classes
      • Seb: summary: overall seems good, but details
      • Seb: should it be scoped at the package? when should we warn/error?
      • Gui, Seth: seems not easy
      • Martin is against the counter-proposal of having it as an opt-in annotation
    • Parameter untupling
      • Gui: the strong version is that anything on the left is a pattern (rather than just tuple)
      • Seth: not crazy about it, seems like another thing you need to learn
      • Gui: on the contrary, the status quo (having to add a case) forces you to learn this detail early
      • Seb: but we’re dropping auto-tupling?
      • Martin: it’s related to the pattern bindings changes (below)
    • Pattern bindings
    • Toplevel definitions
      • Gui: details around private. top-level private type and private class, the type is in a synthetic object, the class is really top level
      • that also impacts opaque types
      • Seb: then let’s force users to put in object and export instead
      • but, boilerplate…
    • Trait parameters
      • Gui/Seb: yes, everyone wants them
      • Gui: something about mixing in multiple traits and them having implicit parameters (that need hand-wiring?)
    • Type lambdas
      • Gui/Seb: yes, everyone wants them
      • Gui: something about variance
      • Seth: I’ll look into whether kind-projector is on track with the changes on their end
    • Drop type projection (over abstract types)
      • Gui: it’s unsound
      • Martin: Under -strict (i.e. how Scala 3.1 will behave by default) it’s a compile error. Will migrate from -strict to -Xsource:3.1
      • Gui: we might change it so it’s just lower-bounded, not upper-bounded, proposed by Lionel
      • Martin: actually, let’s put that change under a -Y option
      • Seb: Seems to me match types are the replacement for this
    • Weak conformance -> harmonization
      • Seb: with overloading weak conformance is back
      • Seb: Long and Any overloading, nsc conforms Int to Long, dotc picks Any
      • Seb: JUnit assertEquals overloads, and Integer/Long aren’t equals
      • Seb: two parts to this change: the List case (inference) and overloading when primitives are present
      • Seth, Adriaan: some people weren’t happy with weak conformance, but it’s unclear this is really the right thing either, is it progress or mostly sideways motion?
      • Seth: I need to re-study this in light of the new numeric-literals proposal
    • Wildcard types
      • ? instead of _

    Review enums

    Martin: most seem happy with the current design decisions

    two pushbacks:

    1. should apply return the precise type?
    2. support nested enums

    Martin says he’s received a lot of feedback about the apply question that isn’t reflected in the forum discussion. Guillaume says he’ll post something.

    Seb: these conflict. If apply returns the wide type, then enums can never have nested enums.

    Most of the committee don’t feel strongly for hierachical enums (“nested” enums).

    Disallow extending java.lang.Enum outside of enums.

    Review creator applications

    Seb: what’s the point? Martin: avoid having to explain the difference

    Aka “optional new”.

    Seb and Seth have misgivings and are at least somewhat attached to using new C to indicate things that have identity (e.g. ordinary classes), but C(...) for things with value semantics. Martin: that sail has shipped - there are many mutable classes with a case class-like companion def apply.

    Review @infix and @alpha

    • @infix: you are allowed and encouraged to call infix
    • @alpha: very different. 2 things:
    1. it gives the platform encoded (simple) name of the method
    2. canonical name of the method (it’s “Googleable” name)

    But you can’t invoke that alpha name. It’s just for reference, like documentation. (So why not just use scaladoc?)

    @alpha is trying to address the problem of overuse of symbolic methods.

    Martin: so, 2 questions:

    • should it be mandatory?
    • is it useful?

    Most believe it to be useful, but multiple committee members vocally opposed making it mandatory.

    Also can it be merged with @jsName? Seb: Yes, but Scala.js’s symbol variant of that would have to remain separate. Seth et al considered that sufficient unification.

    No one in the committee who has registered an opinion is against @infix, but there is a question of whether to allow non-@infix-annotated methods to still be used infix before a curly brace, e.g. xs map { .....

    Conclusion: allow that in 3.0, maybe crack down harder later.

    Review dependent and polymorphic function types

    • Seb: Dependent function types are good, probably will be accepted.
    • Seb: it uses existing concepts (namely refinement types) and adds syntax sugar
    • Seb: it’s in a more restricted form at the moment, but it can be made more generic later

    • Martin: and we fixed a problem with variance

    • Seb: polymorphic function types, on the other hand, are in a completely different realm because “function type” would no longer just be sugar for trait+apply, they become an independent concept.
    • Seb: It’s a new encoding. Should we support all sorts of methods? It opens an entirely new world.
    • Seb: IMO if we do them, we should go all the way, in 1 go. In particular vararg function types, for Scala.js.
    • Gui: even with limitations, they’re really useful
    • Gui: I have a prototype for this

    Next

    The next meeting will be tomorrow, 12 March.

    Scala Improvement Proposals (SIPs)
    SIP Meetings
    Submitting a SIP
    Problem with this page?
         Please help us fix it!