Implicit conversion: Tuple -> Seq

[Sebastian Meßmer]

Hello,

what do you think about adding an implicit conversion from tuple to seq to the
scala library?

implicit def tuple2Seq2[T](a:(T,T)) = Seq(a._1,a._2)
implicit def tuple2Seq3[T](a:(T,T,T)) = Seq(a._1,a._2,a._3)
...

It would for example allow the following use cases:

1) for(i<-(2,4,5)) {...}
2) val squareOfFirstPrimes = (2,3,5,7).map(r=>r*r)
3) val specificRows = databaseTable.getWhere(row=>(2,4,5,6).contains(row.id))
4) ...

Of course you can always achieve the same by writing Seq(...) instead of just
(...), but I think the tuple way is more concise.

The implicit conversion as given above does only work, when all tuple entries
have the same type.

Best regards,
Sebastian

[Vlad Patryshev]

Makes sense to me.

Or have an implicit conversion from TupleN[A1 <: A,A2 <: A,...] to Int =>A - not sure if it's feasible. 

Thanks,
-Vlad

[Paul Phillips]

Absolutely not. Clearly we haven't done an adequate job of advertising the downsides of these things. You can easily write one for your own usage. By the way, all the tuple elements always all have the same type - every tuple2 is a Tuple2[Any, Any].

Sent from my iPhone

[√iktor Ҡlang]

implicit def prod2Seq(p: Product): Seq[Any] = p.productIterator.toList

But it's nothing I'd recommend.

Cheers,

√

--
Viktor Klang

Director of Engineering

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Sebastian Meßmer]

Am Sonntag, 2. Dezember 2012, 16:43:28 schrieb Paul Phillips:
> Absolutely not. Clearly we haven't done an adequate job of advertising the
> downsides of these things. You can easily write one for your own usage. By
> the way, all the tuple elements always all have the same type - every
> tuple2 is a Tuple2[Any, Any].

Can you (or someone else) elaborate the downsides? I see them when converting
to Seq[Any]. But when we use the type inferencer and let it convert to the
mgu, everything should be fine. It's just like the inference when writing
Seq(...)

Regards
Sebastian

[Paul Phillips]

On Tue, Dec 4, 2012 at 7:36 AM, Sebastian Meßmer <ma...@smessmer.de> wrote:

Can you (or someone else) elaborate the downsides? I see them when converting
to Seq[Any]. But when we use the type inferencer and let it convert to the
mgu, everything should be fine. It's just like the inference when writing
Seq(...)

An implicit conversion always entails a loss of type-safety: that is their purpose. One can tolerate a loss of type-safety under some conditions; but this, a straight conversion between two widely used and inequivalent types, these are not the conditions. An implicit conversion in the default scope is something you inflict on everyone. I wouldn't want this one; I know plenty of other people wouldn't either. Tuples are tuples and sequences are sequences. The reason I use a language with types is so that either my tuples will stay tuples and my sequences will stay sequences, or the program won't compile.

You have the option to give that up if you want; as a default set of conditions, it does not fly, especially given that it's easy to add and hard to subtract. This argument applies equally well to some existing implicits; that's no reason to expand.

A more concrete reason is that it would break a lot of code - for instance, it would break any program where such an implicit was already in place.

[martin odersky]

On Tue, Dec 4, 2012 at 10:23 PM, Paul Phillips <pa...@improving.org> wrote:

On Tue, Dec 4, 2012 at 7:36 AM, Sebastian Meßmer <ma...@smessmer.de> wrote:

Can you (or someone else) elaborate the downsides? I see them when converting
to Seq[Any]. But when we use the type inferencer and let it convert to the
mgu, everything should be fine. It's just like the inference when writing
Seq(...)

An implicit conversion always entails a loss of type-safety: that is their purpose. One can tolerate a loss of type-safety under some conditions; but this, a straight conversion between two widely used and inequivalent types, these are not the conditions. An implicit conversion in the default scope is something you inflict on everyone. I wouldn't want this one; I know plenty of other people wouldn't either. Tuples are tuples and sequences are sequences. The reason I use a language with types is so that either my tuples will stay tuples and my sequences will stay sequences, or the program won't compile.

That sums it up very well, I think. more conversions -> less type safety. 

Cheers

 - Martin

 

You have the option to give that up if you want; as a default set of conditions, it does not fly, especially given that it's easy to add and hard to subtract. This argument applies equally well to some existing implicits; that's no reason to expand.

A more concrete reason is that it would break a lot of code - for instance, it would break any program where such an implicit was already in place.

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Rich Oliver]

An implicit conversion always entails a loss of type-safety: that is their purpose. One can tolerate a loss of type-safety under some conditions; but this, a straight conversion between two widely used and inequivalent types, these are not the conditions. An implicit conversion in the default scope is something you inflict on everyone. I wouldn't want this one; I know plenty of other people wouldn't either.

No I certainly wouldn't want it. Type conversion and type inference is something that needs to be evolved overtime through experience of what's worth the cost and what's not. More is not all always better.

[Sebastian Meßmer]

That makes sense, thank you.

 

Sebastian

[杨博]

How about this:

scala> implicit class TypedProductIterator2[A](product2: Product2[_ <: A, _ <: A]) {

     |   def typedProductIterator = product2.productIterator.asInstanceOf[Iterator[A]]

     | }

defined class TypedProductIterator2

scala>

scala> (Seq(1, 4), Set(1, 2, 3)).typedProductIterator

res0: Iterator[Iterable[Int] with Int => AnyVal] = non-empty iterator

在 2012年12月3日星期一UTC+8上午8时43分28秒，Paul Phillips写道：

[Paul Phillips]

On Thu, Dec 6, 2012 at 11:11 PM, 杨博 <pop....@gmail.com> wrote:

implicit class TypedProductIterator2[A](product2: Product2[_ <: A, _ <: A]) {

Product is covariant; you can write it

implicit class TypedProductIterator2[A](product2: Product2[A, A])

with the same effect.