Skip to content

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

Merged
merged 1 commit into from
May 19, 2017

Conversation

travissarles
Copy link
Contributor

No description provided.

@travissarles travissarles requested a review from jvican April 18, 2017 10:49

### [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.
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comments commas

Copy link
Member

@SethTisue SethTisue left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lightbend

@travissarles
Copy link
Contributor Author

@jvican any other comments before we merge this?

Copy link
Member

@jvican jvican left a 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.
Copy link
Member

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)
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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)
Copy link
Member

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?
Copy link
Member

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?
Copy link
Member

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?

@travissarles travissarles force-pushed the novembermeetingminutes branch from c6c9fd9 to 04e5e9f Compare May 19, 2017 08:44
@travissarles travissarles merged commit d68dbbf into scala:master May 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants