SIP-68: Reference-able Package Objects

[lihaoyi]

No description provided.

[odersky]

Overall I am in favor. It clearly improves on the status quo that we can refer to a package object in the natural way, without using the .package encoding.

My only concern is that accepting this proposal would effectively bury the idea of dropping package objects. But on reflection I don't think we will be able to drop package objects anyway for the reasons that were stated here.

[odersky]

I don't think this limitation is necessary and it would be hard to implement. I think we can simply say that in selection path a.b.c, a.b means the full package, not just the package object. But it's OK to have operators. By the time we check valid package object use, we have already expanded out all these operators to selections.

[smarter]

This means accepting this SIP is conditional on not dropping package object and therefore reworking how we teach top-level definitions, in particular https://docs.scala-lang.org/scala3/book/taste-toplevel-definitions.html# and https://docs.scala-lang.org/tour/package-objects.html need to be adapted. I guess we need to compare and contrast three kind of definitions:

1. Regular class/object definitions in a package
2. Top-level definition (including the special case of a companion object to an opaque type which is not treated like case 1)
3. Package object

These three concepts behave differently with respect to:

• Regular scope
• Given scope
• Accessibility modifiers

For these three cases we need to consider:

• What happens in the scope where the definition is written
• What happens in a different scope in the same package

So there's a lot of hidden complexity here, which is currently under-documented, eventually deprecating package objects would have provided some relief here, but if we don't deprecate them I believe we'll need to do a much better job of explaining all these subtleties and providing guidelines on when to use what feature.

[odersky]

I think we can avoid some of the complexity by changing the approach. The compiler treats package objects and toplevel definitions mostly the same. The only thing to explain is that toplevel definitions are partitioned: Classes and objects are treated as if they live directly in the package and all other definitions are treated as if they live in a synthesized package object. That needs to be explained anyway. (Maybe it is already explained? If not, a PR would be great.) After that, resolution proceeds the same for members of explicit and synthesized package objects.

[sjrd]

I have no strong feeling on this proposal. It's a bit sad that we could not actually get rid of package objects, but oh well.

One comment: the proposal argues that it improves regularity: objects and package objects become more the same. While that is true, it also degrades another regularity aspect. Now, a package that has a package object does not behave the same as a package that doesn't have one. If there is a package object, one can use a.b as a value; but if there isn't, we cannot.

I don't think this is a deal breaker, but it should be clearly acknowledged in the proposal, IMO.

[lrytz]

Another inconsistency that this proposal introduces: a.b.c (where a.b is a package) can now sometimes be refactored to val x = a.b; x.c. Not if c is defined in the package (a top-level class / object / term definition).

IIUC, the motivation for this proposal is to improve the ergonomics when package objects are deliberately used for building the API of a library. Like package object requests extends requests.BaseSession, which is useful for import requests._ but also a useful first-class value. That seems fine with me, like others said it cements the status of package objects with inheritance in the language. (sbt uses it too).

The Mill use case I don't understand so well as there's additional magic going on in the build tool. I looked a bit at

• https://mill-build.org/mill/fundamentals/modules.html#_rootmodule
• https://mill-build.org/mill/large/multi-file-builds.html

Again, the SIP seems fine and helpful if we keep package objects. (I wonder why in the examples they are declared as package x; object `package` instead of package object x, and what the magic import $packages._ is.)

[lihaoyi]

I have removed the unnecessary limitations, added text mentioning the irregularity brought up by @sjrd and @lrytz, and added open questions related to our discussion about package objects participating in .apply and .type syntax. I think this proposal is good to go now