Naming elements of tuple parameters to defs

[Meglio]

P.S. I have not found better place for language feature proposition.

If it is not a right place, please let me know.

Currently we can do:

  def x( p: (Int, Option[String]) ) { val (i, s) = p }

What if we could do this:

  def x( p: (i: Int, s: Option[String]) ) {  }

I'm not sure if this is possible in the theory of Scala implementation.

Regards,

Anton

[√iktor Ҡlang]

You mean local aliases for _1 and _2?

Cheers,

√

 

Regards,

Anton

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Anton Andriyevskyy]

Yes, the idea is to get rid of val (i, s) = p assignment.

I know that a tuple is translated into the type by compiler.

So I thought that the compiler could also assign local aliases.

I'm not sure it happens often in the code - e.g. when a tuple (a, b) is passed instead of two parameters a, b.

[Anton Andriyevskyy]

Going further, we may be not interested in p at all, then we maybe declare so:

  def x( (i: Int, s: Option[String]) ) {  }

.... or, just to release namespace and get rid of unwanted identifier (and making code micro-little-more-maintainable?), maybe:

  def x( _: (i: Int, s: Option[String]) ) {  }

- in this way we "declare" that we are not interested in p, but only in its values.

[√iktor Ҡlang]

you mean like:

def x(i: Int, s: Option[String]) ?

[Anton Andriyevskyy]

Yes.

[Chris Marshall]

i think Viktor is implying that the unification of tuples and argument lists will be a help here. Or alternatively just declare x as he suggests and then use (x _).tupled to turn into a function which accepts a tuple.

Chris

[Anton Andriyevskyy]

Interesting, I did not know about tupled.

Looks like "tupled" will not help with this declaration below?

  def x(k: Book, p: (Int, Option[String]) ) { val (i, s) = p }

Also, I'm not sure what do you mean with this text:

  > the unification of tuples and argument lists will be a help here

Does this mean that we just have to design functions better to avoid such needs?

[√iktor Ҡlang]

On Thu, Jul 26, 2012 at 8:37 PM, Anton Andriyevskyy <x.me...@gmail.com> wrote:

Interesting, I did not know about tupled.

Looks like "tupled" will not help with this declaration below?

  def x(k: Book, p: (Int, Option[String]) ) { val (i, s) = p }

how about: def x(k: Book)(i: Int, s: Option[String]) { ... }

 

Also, I'm not sure what do you mean with this text:

  > the unification of tuples and argument lists will be a help here

Does this mean that we just have to design functions better to avoid such needs?

[Chris Marshall]

My unification point was about a long-wished-for feature of scala. That is, a method's argument list was essentially a tuple and they were interchangeable. Not sure this will ever happen.

As for your comment on the utility of tupled; indeed, it will not "flatten" nested tuples. I think this would violate the principle of least surprise tbh

Chris

[Anton Andriyevskyy]

Thank you all so much for explanations.

But at the end, is it right place for such propositions/questions?

Anton

[nafg]

Probably a better place would be scala-debate.

[Rich Oliver]

I used to think I wanted such a feature, now I'm not so sure. Too much type inference is a bad thing.I try and design my paramater lists so as to maximise type errors where there might be a bug. Also I think it might conflict with my own control of overloading particular on apply methods.

On Thursday, July 26, 2012 8:34:35 PM UTC+1, oxbow_lakes wrote:

My unification point was about a long-wished-for feature of scala. That is, a method's argument list was essentially a tuple and they were interchangeable. Not sure this will ever happen.