SIP minutes: 2020 March 12 #1660
Conversation
_sips/minutes/2020-03-12-minutes.md
Outdated
| * Martin: I feel good about how it is now, I wouldn't change any detail on it | ||
| * Adriaan: it would be good to add a type ascription when exporting (`export A.T: Foo` to only export Foo's methods) | ||
| * Martin: that wouldn't be big, we could add that | ||
| * Gui: we could add refinements to the import, to select exactly the method used (`import A.T { def foo(x: Int): Int }`) |
There was a problem hiding this comment.
I'm pretty sure @smarter's comment here was about exports, not imports. So something like export A.T: { def foo(x: Int): Int }.
There was a problem hiding this comment.
Also the syntax is:
export (A: Foo).T // already mentioned in https://contributors.scala-lang.org/t/request-for-comments-on-exports/4051/17
export (A: { def foo(x: Int): Int }).fooYou put the ascription on the value who's being upcasted, just like in regular code.
I think we also briefly touched on the fact that once we allow these sort of ascriptions for export, we could allow them on imports for symmetry, but that's not a very important point.
| * Gui: why `inline msg: String`? Seeing as the semantics match just use `msg: => String`, just as the syntax, with the current codegen implementation. | ||
| * Gui: inline interacts with overriding | ||
| * Nic: if in a subclass (say Range) you override a method (say foreach) with `inline` it only inlines if the type is cast | ||
| * Seb: I need both, inline if statically the type is Range, and use the optimised override if it's a Seq that's a Range at runtime |
There was a problem hiding this comment.
This eventually led to scala/scala3#8543 and scala/scala3#8564. I suggest pointing at least to the former as it contains concrete results of the discussion that happened during the SIP meeting.
dwijnand
force-pushed
the
sip-minutes-2020-03-12
branch
from
8fc93b0
to
d6526ea
Compare
|
I'll merge this as is for now. Feedback still welcome and we'll adapt in another PR. |
No description provided.