Refer to previous argument in default argument list

Language Design
1

Currently this is impossible:

def substring(s: String, start: Int = 0, end: Int = s.length): String

The only way to achieve this is this:
def substring(s: String, start: Int = 0)(end: Int = s.length): String

3 Likes
2

I was also bitten by this from time to time. I agree it would be nice to fix, and it does not look that hard to do it. But it would require a spec change.

1 Like
3

@pathikrit Have you considered submitting a SIP proposal? I would also like to see this fixed, it’s a very recurrent situation when using default arguments.

4

@jvican: Before submitting the SIP proposal, decided to post here to make sure it is not a dupe or in roadmaps or was completely rules out before. But will submit a proposal shortly.

5

If you need some help getting it done or work out some of the details, please contact me. I would be happy to help you and review this proposal soon!

6

@pathikrit, I’d also be happy to provide pointers! @dwijnand also has some fresh experience getting a SIP through and as such I’m sure he’d be happy to also provide pointers :slight_smile:

7

Pointers for getting a SIP through:

  • check the mailing lists to see what people might have said in the past about this feature - often a topic has been covered many times, and there’s lots of useful information, and I would bet this feature is the same

  • try and implement it, particularly given @odersky said it does not look that hard to do

  • when you write your SIP try your best to think up all feature interactions. This will help reduce iterations with the committee. A few examples off the top of my head: varargs, implicit argument lists, and using the same feature also for type members (eg. def f(x: A, y: x.B))

  • there is an interest of this for implicits, currently worked around with the Aux pattern, and I believe there is a SI ticket / pending PR to introduce multiple implicit argument lists as an alternative workaround. Ultimately this feature super-seed both of those, imho.

  • when you respond to the SIP’s request for feedback, make sure that that feedback is very clear and not too “wordy” - for instance I’ve found the committee responds better to succinct lists over wordy paragraphs

  • work closely with your SIP sponsor, making sure he/she understands what you’re saying and/or asking, and making sure you understand what the committee wants from you and your SIP

3 Likes
8

Such a great summary. I’ll give it a more public face and open a Discourse thread so that people interested in submitting proposals can also benefit from this.

9

Thanks for the pointers @dwijnand. I will submit a SIP tonight.

1 Like
10

Just submitted an early SIP draft: https://github.com/scala/scala.github.com/pull/653

1 Like