diff --git a/_sips/minutes/2020-03-11-minutes.md b/_sips/minutes/2020-03-11-minutes.md new file mode 100644 index 0000000000..6574fe86ba --- /dev/null +++ b/_sips/minutes/2020-03-11-minutes.md @@ -0,0 +1,240 @@ +--- +layout: sips +title: SIP Meeting Minutes - March 11 2020 + +partof: minutes +--- + +# 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 + +* Martin Odersky ([@odersky](https://github.com/odersky)), EPFL +* Adriaan Moors ([@adriaanm](https://github.com/adriaanm)), Lightbend +* Guillaume Martres ([@smarter](https://github.com/smarter)), EPFL +* Seth Tisue ([@SethTisue](https://github.com/SethTisue)), Lightbend +* Sébastien Doeraene ([@sjrd](https://github.com/sjrd)), Scala Center + +## Sitting in + +* Jamie Thompson ([@bishabosha](https://github.com/bishabosha)), Scala Center +* Lukas Rytz ([@lrytz](https://twitter.com/lrytz)), Lightbend +* Nicolas Stucki ([@nicolasstucki](https://github.com/nicolasstucki)), EPFL +* Darja Jovanovic ([@darjutak](https://github.com/darjutak)), Process Lead +* Dale Wijnand ([@dwijnand](https://twitter.com/dwijnand)), secretary + +## Not present + +* Heather Miller ([@heathermiller](https://github.com/heathermiller)), CMU +* Iulian Dragos ([@dragos](https://github.com/dragos)), Triplequote +* Josh Suereth ([@jsuereth](https://github.com/jsuereth)), independent +* Miles Sabin ([@milessabin](https://github.com/milessabin)), independent + +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 + * Gui: from threads, used a lot by DSL libraries + * Seth: but that was in reference to the explicit-only option, which doesn't have committee support. + * Seth: most DSLs should be fine under the proposal + * +* 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 + * Martin: `for (case Foo(a, b) <- ...)` for filtering, and val pattern, same + * `case` is now be required whenever the pattern is refutable (🎉) + * +* 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. + +`@infix` is uncontroversial, 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.