-
Notifications
You must be signed in to change notification settings - Fork 1k
November 2016 SIP meeting minutes #764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
November 2016 SIP meeting minutes #764
Conversation
|
||
### [SIP-27: Trailing commas](http://docs.scala-lang.org/sips/completed/trailing-commas.html) | ||
|
||
Dale talks about how we wanted trailing comments for multi-line elements. Should be easy. Need to discuss which parts of the syntax can use trailing comments. There are two variants of the SIP to vote on. The first is _parameters and arguments_. The other variant is _everywhere_ for consistency. Dale implemented the first one. The second one shouldn't be more hard to implement except for tuples. It needs to fail compilation somehow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comments commas
|
||
Dale talks about how we wanted trailing comments for multi-line elements. Should be easy. Need to discuss which parts of the syntax can use trailing comments. There are two variants of the SIP to vote on. The first is _parameters and arguments_. The other variant is _everywhere_ for consistency. Dale implemented the first one. The second one shouldn't be more hard to implement except for tuples. It needs to fail compilation somehow. | ||
|
||
It could be confusing if trailing comments are only allowed some places and not others. We'd need lots of error messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comments commas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otherwise LGTM
|
||
* Martin Odersky ([@odersky](https://github.com/odersky)), EPFL | ||
* Jorge Vicente Cantero ([@jvican](https://github.com/jvican)), Process Lead | ||
* Seth Tisue ([@SethTisue](https://github.com/SethTisue)), EPFL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lightbend
4d0f5e7
to
c6c9fd9
Compare
@jvican any other comments before we merge this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM otherwise.
## Proceedings | ||
### Opening Remarks | ||
|
||
**Jorge** We'll talk about the SIPS for META. Eugene will start. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/META/Scala Meta/g
|
||
**Jorge** We'll talk about the SIPS for META. Eugene will start. | ||
|
||
### [SIP-28 and SIP-29 - Inline meta](http://docs.scala-lang.org/sips/pending/inline-meta.html) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/Inline meta/Inline and Meta/g
|
||
The spec needs to be updated based on Martin's Dotty implementation. We need to split the SIPs for the next meeting. | ||
|
||
**Conclusion** More development needed. Must answer questions on PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This proposal needs at least another iteration to shape up and provide concrete implementation and specification details. This proposal is therefore under revision -- Eugene, the author, will gather and address more feedback and will resubmit the proposal to analysis when it's ready.
|
||
The main motivation is to prepare for inline. Inline won't work very well without this. Need to flesh this out in SIP. | ||
|
||
**Conclusion** Someone needs to flesh out the SIP and how it relates to inline. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is not an implementation for Scalac, but for Dotty. This proposal is on hold until the Committee decides the specifics of the Inline proposal and how it relates to it. After that, the author will resubmit the proposal for further analysis.
|
||
**Conclusion** Someone needs to flesh out the SIP and how it relates to inline. | ||
|
||
### [SIP-NN:Static](https://github.com/scala/scala.github.com/pull/491/files) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SIP-25: Static
|
||
Sébastien says binary compatibility is also an argument in favor of having explicit @static annotation. If in one version you have a static method, in the next version you add a method with same name and signature. The static implementation is not there anymore, then you have broken binary compatibility in a silent way. | ||
|
||
**Conclusion** There are a lot of edge cases when not using annotations. We need to work on this and think about cases around initialization to simplify it. Why do statics need to go first? Show surprising results. There are different implementation strategies. Is this more like @tailrec or does it change generated code? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/we need to work on this/The authors need time to work on the specifics of the proposal and address the Committee's feedback: .../g
|
||
Sébastien says binary compatibility is also an argument in favor of having explicit @static annotation. If in one version you have a static method, in the next version you add a method with same name and signature. The static implementation is not there anymore, then you have broken binary compatibility in a silent way. | ||
|
||
**Conclusion** There are a lot of edge cases when not using annotations. We need to work on this and think about cases around initialization to simplify it. Why do statics need to go first? Show surprising results. There are different implementation strategies. Is this more like @tailrec or does it change generated code? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add "This is the first review iteration of this proposal." at the beginning of the conclusion?
c6c9fd9
to
04e5e9f
Compare
No description provided.