SIP minutes: 2020 March 11

_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
+    * <https://contributors.scala-lang.org/t/proposal-changes-to-implicit-conversions/4101/7>
+* 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 (🎉)
+    * <https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html>
+* 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.