[Discussion] Removing tuple labels from the type signature

hartbit · 2016-02-04T09:10:09.000Z

Before I start working on a proposal, I’d like to understand the problem in detail. Can someone help me understand why parts of the language treats tuple labels as type and other not?

let a: (lhs: Int, rhs: Int) = (4, 5) // works
(4,5).dynamicType == (lhs: 2, rhs: 6).dynamicType // true

But:

[(lhs: 3, rhs: 5)] == [(1,2)]
// Binary operator ‘==‘ cannot be applied to operands of type ‘[(las: Int, rhs: Int)]’ and ‘[(Int, Int)]’
[(lhs: 3, rhs: 5)].dynamicType == [(1,2)].dynamicType
// Binary operator ‘==‘ cannot be applied to operands of type ‘Array<(las: Int, rhs: Int)>.Type’ and ‘Array<(Int, Int)>'

And:

struct Foo<T> {
let bar: T
}

var foo1 = Foo(bar: (4, 5))
var foo2 = Foo(bar: (lhs: 4, rhs: 5))
foo1 = foo2
// Cannot assign value of type ‘Foo<(las: Int, res: Int)>’ to type ‘Foo<(Int, Int)>’

But:

foo1.dynamicType == foo2.dynamicType // true

So it seems that in parts of the language, they are treated with the same type, but not in generics.

Any input?

Chris_Lattner · 2016-02-04T17:27:12.000Z

Before I start working on a proposal, I’d like to understand the problem in detail. Can someone help me understand why parts of the language treats tuple labels as type and other not?

let a: (lhs: Int, rhs: Int) = (4, 5) // works

This is supposed to work because of an implicit conversion.

(4,5).dynamicType == (lhs: 2, rhs: 6).dynamicType // true

This is not supposed to behave this way. The bug here is that we’re not encoding tuple labels in the metadata record for tuples.

But:

[(lhs: 3, rhs: 5)] == [(1,2)]
// Binary operator ‘==‘ cannot be applied to operands of type ‘[(las: Int, rhs: Int)]’ and ‘[(Int, Int)]’

This is correctly rejected.

[(lhs: 3, rhs: 5)].dynamicType == [(1,2)].dynamicType
// Binary operator ‘==‘ cannot be applied to operands of type ‘Array<(las: Int, rhs: Int)>.Type’ and ‘Array<(Int, Int)>’

This is correctly rejected.

And:

struct Foo<T> {
let bar: T
}

var foo1 = Foo(bar: (4, 5))
var foo2 = Foo(bar: (lhs: 4, rhs: 5))
foo1 = foo2
// Cannot assign value of type ‘Foo<(las: Int, res: Int)>’ to type ‘Foo<(Int, Int)>’

This is correctly rejected.

But:

foo1.dynamicType == foo2.dynamicType // true

Same problem: reflection metadata isn’t being encoded, so these end up looking like they have the same dynamic type, when they shouldn’t.

-Chris

···

On Feb 4, 2016, at 1:10 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Qbyte · 2016-02-04T17:35:07.000Z

+1

Although I think almost all examples are bugs:

// As expected
let a: (lhs: Int, rhs: Int) = (4, 5) // works
(4,5).dynamicType == (lhs: 2, rhs: 6).dynamicType // true

let arr1 = [(lhs: 3, rhs: 5)]
let arr2 = [(1,2)]

// == can only be used for equatable element types. Right now Tuples are not equatable
arr1 == arr2

// doesn't work: I assume it is a bug see below
[(lhs: 3, rhs: 5)].dynamicType == [(1,2)].dynamicType

let type = [(lhs: 3, rhs: 5)].dynamicType
let type2 = [(1,2)].dynamicType

type == type2 // works!

struct Foo<T> {
  let bar: T
}

var foo1 = Foo(bar: (4, 5))
var foo2 = Foo(bar: (lhs: 4, rhs: 5))

// still an error
foo1 = foo2
// Cannot assign value of type ‘Foo<(lhs: Int, rhs: Int)>’ to type ‘Foo<(Int, Int)>’

// As expected
foo1.dynamicType == foo2.dynamicType // true

As summary: Tuples are not equatable , dynamic types of Array literals are buggy , weird generic behavior.

You should file a bug/radar.

Best regards
- Maximilian

···

Am 04.02.2016 um 10:10 schrieb David Hart via swift-evolution <swift-evolution@swift.org>:

Before I start working on a proposal, I’d like to understand the problem in detail. Can someone help me understand why parts of the language treats tuple labels as type and other not?

let a: (lhs: Int, rhs: Int) = (4, 5) // works
(4,5).dynamicType == (lhs: 2, rhs: 6).dynamicType // true

But:

[(lhs: 3, rhs: 5)] == [(1,2)]
// Binary operator ‘==‘ cannot be applied to operands of type ‘[(las: Int, rhs: Int)]’ and ‘[(Int, Int)]’
[(lhs: 3, rhs: 5)].dynamicType == [(1,2)].dynamicType
// Binary operator ‘==‘ cannot be applied to operands of type ‘Array<(las: Int, rhs: Int)>.Type’ and ‘Array<(Int, Int)>'

And:

struct Foo<T> {
let bar: T
}

var foo1 = Foo(bar: (4, 5))
var foo2 = Foo(bar: (lhs: 4, rhs: 5))
foo1 = foo2
// Cannot assign value of type ‘Foo<(las: Int, res: Int)>’ to type ‘Foo<(Int, Int)>’

But:

foo1.dynamicType == foo2.dynamicType // true

So it seems that in parts of the language, they are treated with the same type, but not in generics.

Any input?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Qbyte · 2016-02-04T18:57:25.000Z

Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?

Should it be treated as the same type as the proposal suggests?

Is there a connection to your tuple splat proposal?

Thank you in advance for clarification :)
- Maximilian

···

Am 04.02.2016 um 18:27 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

On Feb 4, 2016, at 1:10 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Before I start working on a proposal, I’d like to understand the problem in detail. Can someone help me understand why parts of the language treats tuple labels as type and other not?

let a: (lhs: Int, rhs: Int) = (4, 5) // works

This is supposed to work because of an implicit conversion.

(4,5).dynamicType == (lhs: 2, rhs: 6).dynamicType // true

This is not supposed to behave this way. The bug here is that we’re not encoding tuple labels in the metadata record for tuples.

But:

[(lhs: 3, rhs: 5)] == [(1,2)]
// Binary operator ‘==‘ cannot be applied to operands of type ‘[(las: Int, rhs: Int)]’ and ‘[(Int, Int)]’

This is correctly rejected.

[(lhs: 3, rhs: 5)].dynamicType == [(1,2)].dynamicType
// Binary operator ‘==‘ cannot be applied to operands of type ‘Array<(las: Int, rhs: Int)>.Type’ and ‘Array<(Int, Int)>’

This is correctly rejected.

And:

struct Foo<T> {
let bar: T
}

var foo1 = Foo(bar: (4, 5))
var foo2 = Foo(bar: (lhs: 4, rhs: 5))
foo1 = foo2
// Cannot assign value of type ‘Foo<(las: Int, res: Int)>’ to type ‘Foo<(Int, Int)>’

This is correctly rejected.

But:

foo1.dynamicType == foo2.dynamicType // true

Same problem: reflection metadata isn’t being encoded, so these end up looking like they have the same dynamic type, when they shouldn’t.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris_Lattner · 2016-02-04T23:11:52.000Z

Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?

I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.

Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.

Is there a connection to your tuple splat proposal?

No connection at all.

-Chris

···

On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:

hartbit · 2016-02-04T22:24:29.000Z

I'm going to start work on a proposal to treat them as the same type.

···

On 04 Feb 2016, at 19:57, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:

Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?

Should it be treated as the same type as the proposal suggests?

Is there a connection to your tuple splat proposal?

Thank you in advance for clarification :)
- Maximilian

Am 04.02.2016 um 18:27 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

On Feb 4, 2016, at 1:10 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Before I start working on a proposal, I’d like to understand the problem in detail. Can someone help me understand why parts of the language treats tuple labels as type and other not?

let a: (lhs: Int, rhs: Int) = (4, 5) // works

This is supposed to work because of an implicit conversion.

(4,5).dynamicType == (lhs: 2, rhs: 6).dynamicType // true

This is not supposed to behave this way. The bug here is that we’re not encoding tuple labels in the metadata record for tuples.

But:

[(lhs: 3, rhs: 5)] == [(1,2)]
// Binary operator ‘==‘ cannot be applied to operands of type ‘[(las: Int, rhs: Int)]’ and ‘[(Int, Int)]’

This is correctly rejected.

[(lhs: 3, rhs: 5)].dynamicType == [(1,2)].dynamicType
// Binary operator ‘==‘ cannot be applied to operands of type ‘Array<(las: Int, rhs: Int)>.Type’ and ‘Array<(Int, Int)>’

This is correctly rejected.

And:

struct Foo<T> {
let bar: T
}

var foo1 = Foo(bar: (4, 5))
var foo2 = Foo(bar: (lhs: 4, rhs: 5))
foo1 = foo2
// Cannot assign value of type ‘Foo<(las: Int, res: Int)>’ to type ‘Foo<(Int, Int)>’

This is correctly rejected.

But:

foo1.dynamicType == foo2.dynamicType // true

Same problem: reflection metadata isn’t being encoded, so these end up looking like they have the same dynamic type, when they shouldn’t.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Qbyte · 2016-02-04T23:26:12.000Z

Is this behavior intended?

What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

Thank you for clarification
- Maximilian

···

Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com>:

On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:

Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?

I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.

Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.

Is there a connection to your tuple splat proposal?

No connection at all.

-Chris

Chris_Lattner · 2016-02-04T23:56:21.000Z

Is this behavior intended?

What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not swap the elements. IMO, it is best to disallow things misleading things like this.

-Chris

···

On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:

Thank you for clarification
- Maximilian

Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com>:

On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:

Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?

I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.

Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.

Is there a connection to your tuple splat proposal?

No connection at all.

-Chris

Ondrej_Barina · 2016-02-05T06:47:27.000Z

-1 for proposal. Current behavior is fine. There is no need to change it
Ondrej b.

···

On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" < swift-evolution@swift.org> wrote:

> On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger < > m.huenenberger@me.com> wrote:
>
> Is this behavior intended?
>
> What disadvantage do I have if a conversion from (a: Int, b: Int) to (x:
Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion from
“(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not
swap the elements. IMO, it is best to disallow things misleading things
like this.

-Chris

>
>
> Thank you for clarification
> - Maximilian
>
>> Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com>:
>>
>>
>>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger < > m.huenenberger@me.com> wrote:
>>>
>>> Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs:
Int) as separate types?
>>
>> I’m not sure what you mean by “separate types”. One has labels, one
does not, so they are clearly separate.
>>
>> Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int,
b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int,
y : Int)”.
>>
>>> Is there a connection to your tuple splat proposal?
>>
>> No connection at all.
>>
>> -Chris
>>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Haravikk3 · 2016-02-05T09:12:33.000Z

I think this is a good thing to keep for safety and to avoid errors; while a tuple may indeed contain the appropriate data its purpose may not be the same so using it accidentally could result in hard to diagnose bugs.

It’s better to be explicit in the code IMO, so it’s clear that a is in fact being used as x, and b as y.

Personally my preference would be to go in the opposite direction and disallow conversion of (a:Int, b:Int) to (Int, Int) for the same reasons, as it would force programmers to either add labels to the previously unlabelled tuple type, or make the conversion an explicit one to be certain that it’s being done in the correct order.

···

On 4 Feb 2016, at 23:26, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:
What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

Taras_Zakharko1 · 2016-02-05T07:08:54.000Z

The types are clearly different and the current behaviour is fine as it is.

However, it would be nice to have more support for tuple types in the language. E.g. I’d expect something like this

let x = (a:4, b:5)
let y = x as (m: Int, n: Int)

to work (but it doesn’t currently, you have to use forced cast).

— Taras

···

On 05 Feb 2016, at 07:47, Ondrej Barina via swift-evolution <swift-evolution@swift.org> wrote:

-1 for proposal. Current behavior is fine. There is no need to change it
Ondrej b.
On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>
> Is this behavior intended?
>
> What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not swap the elements. IMO, it is best to disallow things misleading things like this.

-Chris

>
>
> Thank you for clarification
> - Maximilian
>
>> Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>>:
>>
>>
>>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>>>
>>> Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?
>>
>> I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.
>>
>> Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.
>>
>>> Is there a connection to your tuple splat proposal?
>>
>> No connection at all.
>>
>> -Chris
>>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Qbyte · 2016-02-05T12:41:19.000Z

Sleeping over it I have to give -1 to the proposal. However we should consider making explicit casts with "as" to different tuple types with and without labels (separate proposal).

- Maximilian

···

Am 05.02.2016 um 08:08 schrieb Taras Zakharko via swift-evolution <swift-evolution@swift.org>:

The types are clearly different and the current behaviour is fine as it is.

However, it would be nice to have more support for tuple types in the language. E.g. I’d expect something like this

let x = (a:4, b:5)
let y = x as (m: Int, n: Int)

to work (but it doesn’t currently, you have to use forced cast).

— Taras

On 05 Feb 2016, at 07:47, Ondrej Barina via swift-evolution <swift-evolution@swift.org> wrote:

-1 for proposal. Current behavior is fine. There is no need to change it
Ondrej b.

On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" <swift-evolution@swift.org> wrote:

> On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:
>
> Is this behavior intended?
>
> What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not swap the elements. IMO, it is best to disallow things misleading things like this.

-Chris

>
>
> Thank you for clarification
> - Maximilian
>
>> Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com>:
>>
>>
>>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com> wrote:
>>>
>>> Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?
>>
>> I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.
>>
>> Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.
>>
>>> Is there a connection to your tuple splat proposal?
>>
>> No connection at all.
>>
>> -Chris
>>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Craig_Cruden · 2016-02-05T15:17:55.000Z

At a high level, I would think that a tuple would just be considered a “typed” heterogeneous list of values - that you should be able to access the same way that you access any list - same functions (map, reduce, etc.).

I guess you could view the “labels” as a quasi-column header of some sort, which means although you might not be able to “convert” from (a: Int, b: Int) to (x: Int, y: Int) …. you would be able to `map` the values and the "column headers” to (x: Int, y: Int).

···

On 2016-02-05, at 19:41:19, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:

Sleeping over it I have to give -1 to the proposal. However we should consider making explicit casts with "as" to different tuple types with and without labels (separate proposal).

- Maximilian

Am 05.02.2016 um 08:08 schrieb Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

The types are clearly different and the current behaviour is fine as it is.

However, it would be nice to have more support for tuple types in the language. E.g. I’d expect something like this

let x = (a:4, b:5)
let y = x as (m: Int, n: Int)

to work (but it doesn’t currently, you have to use forced cast).

— Taras

On 05 Feb 2016, at 07:47, Ondrej Barina via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1 for proposal. Current behavior is fine. There is no need to change it
Ondrej b.
On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>
> Is this behavior intended?
>
> What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not swap the elements. IMO, it is best to disallow things misleading things like this.

-Chris

>
>
> Thank you for clarification
> - Maximilian
>
>> Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>>:
>>
>>
>>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>>>
>>> Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?
>>
>> I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.
>>
>> Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.
>>
>>> Is there a connection to your tuple splat proposal?
>>
>> No connection at all.
>>
>> -Chris
>>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Craig_Cruden · 2016-02-05T15:20:17.000Z

At a high level, I would think that a tuple would just be considered a “typed” heterogeneous list of values - that you should be able to access the same way that you access any list - same functions (map, reduce, etc.).

I guess you could view the “labels” as a quasi-column header of some sort, which means although you might not be able to “convert” from (a: Int, b: Int) to (x: Int, y: Int) …. you would be able to `map` the values and the "column headers” to (x: Int, y: Int).

Shameless plug: which of course would make the concept of `cases` within the mapping of values within the tuple (heterogeneous list) very useful :p

···

On 2016-02-05, at 22:17:55, Craig Cruden <ccruden@novafore.com> wrote:

At a high level, I would think that a tuple would just be considered a “typed” heterogeneous list of values - that you should be able to access the same way that you access any list - same functions (map, reduce, etc.).

I guess you could view the “labels” as a quasi-column header of some sort, which means although you might not be able to “convert” from (a: Int, b: Int) to (x: Int, y: Int) …. you would be able to `map` the values and the "column headers” to (x: Int, y: Int).

On 2016-02-05, at 19:41:19, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sleeping over it I have to give -1 to the proposal. However we should consider making explicit casts with "as" to different tuple types with and without labels (separate proposal).

- Maximilian

Am 05.02.2016 um 08:08 schrieb Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

The types are clearly different and the current behaviour is fine as it is.

However, it would be nice to have more support for tuple types in the language. E.g. I’d expect something like this

let x = (a:4, b:5)
let y = x as (m: Int, n: Int)

to work (but it doesn’t currently, you have to use forced cast).

— Taras

On 05 Feb 2016, at 07:47, Ondrej Barina via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1 for proposal. Current behavior is fine. There is no need to change it
Ondrej b.
On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>
> Is this behavior intended?
>
> What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not swap the elements. IMO, it is best to disallow things misleading things like this.

-Chris

>
>
> Thank you for clarification
> - Maximilian
>
>> Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>>:
>>
>>
>>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>>>
>>> Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?
>>
>> I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.
>>
>> Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.
>>
>>> Is there a connection to your tuple splat proposal?
>>
>> No connection at all.
>>
>> -Chris
>>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

hartbit · 2016-02-05T18:38:22.000Z

All of this discussion has given me food for thought and I’m not so sure it’s a proposal I’d still like to pursue.

···

On 05 Feb 2016, at 16:20, Craig Cruden via swift-evolution <swift-evolution@swift.org> wrote:

At a high level, I would think that a tuple would just be considered a “typed” heterogeneous list of values - that you should be able to access the same way that you access any list - same functions (map, reduce, etc.).

I guess you could view the “labels” as a quasi-column header of some sort, which means although you might not be able to “convert” from (a: Int, b: Int) to (x: Int, y: Int) …. you would be able to `map` the values and the "column headers” to (x: Int, y: Int).

Shameless plug: which of course would make the concept of `cases` within the mapping of values within the tuple (heterogeneous list) very useful :p

On 2016-02-05, at 22:17:55, Craig Cruden <ccruden@novafore.com <mailto:ccruden@novafore.com>> wrote:

At a high level, I would think that a tuple would just be considered a “typed” heterogeneous list of values - that you should be able to access the same way that you access any list - same functions (map, reduce, etc.).

I guess you could view the “labels” as a quasi-column header of some sort, which means although you might not be able to “convert” from (a: Int, b: Int) to (x: Int, y: Int) …. you would be able to `map` the values and the "column headers” to (x: Int, y: Int).

On 2016-02-05, at 19:41:19, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sleeping over it I have to give -1 to the proposal. However we should consider making explicit casts with "as" to different tuple types with and without labels (separate proposal).

- Maximilian

Am 05.02.2016 um 08:08 schrieb Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

The types are clearly different and the current behaviour is fine as it is.

However, it would be nice to have more support for tuple types in the language. E.g. I’d expect something like this

let x = (a:4, b:5)
let y = x as (m: Int, n: Int)

to work (but it doesn’t currently, you have to use forced cast).

— Taras

On 05 Feb 2016, at 07:47, Ondrej Barina via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1 for proposal. Current behavior is fine. There is no need to change it
Ondrej b.
On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>
> Is this behavior intended?
>
> What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not swap the elements. IMO, it is best to disallow things misleading things like this.

-Chris

>
>
> Thank you for clarification
> - Maximilian
>
>> Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>>:
>>
>>
>>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <m.huenenberger@me.com <mailto:m.huenenberger@me.com>> wrote:
>>>
>>> Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?
>>
>> I’m not sure what you mean by “separate types”. One has labels, one does not, so they are clearly separate.
>>
>> Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.
>>
>>> Is there a connection to your tuple splat proposal?
>>
>> No connection at all.
>>
>> -Chris
>>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Andrew · 2016-02-05T22:42:51.000Z

A related anecdote, a colleague and I found a bug yesterday in our project.
We only realised because the compiler had an error because the tuple labels
didn't match. The error message was not useful, but we would not have
noticed the bug without the compiler error.

I'd support a proposal for a better error message :)

let rgb = (hsbToHsl • hslToRgb)(h, s, b)

*error: cannot invoke '•' with an argument list of type '(Float, Float,
Float)'*

*let rgb = (hsbToHsl • hslToRgb)(h, s, b)*

*note: expected an argument list of type '(T)'*

*let rgb = (hsbToHsl • hslToRgb)(h, s, b)*

// it should have been this:

let rgb = (hslToRgb • hsbToHsl)(h, s, b)

// The type signatures:

func hslToRgb(hsl: (h: Float, s: Float, l: Float))

-> (r: Float, g: Float, b: Float)

func hsbToHsl(hsb: (h: Float, s: Float, b: Float))

-> (h: Float, s: Float, l: Float)

infix operator • {

associativity left

precedence 100

}

public func •<T, U, V>(g: U -> V, f: T -> U) -> (T -> V)

As an aside: we removed the composite operator in the end because it
greatly reduced performance, we tried to force inlining, it didn't make a
difference. I haven't been able to work out a good reason why, hopefully
someone here knows, otherwise I'll have to look at the compiler output.

···

On Sat, Feb 6, 2016 at 5:38 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:

All of this discussion has given me food for thought and I’m not so sure
it’s a proposal I’d still like to pursue.

On 05 Feb 2016, at 16:20, Craig Cruden via swift-evolution < > swift-evolution@swift.org> wrote:

At a high level, I would think that a tuple would just be considered a
“typed” heterogeneous list of values - that you should be able to access
the same way that you access any list - same functions (map, reduce, etc.).

I guess you could view the “labels” as a quasi-column header of some sort,
which means although you might not be able to “convert” from (a: Int, b:
Int) to (x: Int, y: Int) …. you would be able to `map` the values and the
"column headers” to (x: Int, y: Int).

Shameless plug: which of course would make the concept of `cases` within
the mapping of values within the tuple (heterogeneous list) very useful :p

On 2016-02-05, at 22:17:55, Craig Cruden <ccruden@novafore.com> wrote:

At a high level, I would think that a tuple would just be considered a
“typed” heterogeneous list of values - that you should be able to access
the same way that you access any list - same functions (map, reduce, etc.).

I guess you could view the “labels” as a quasi-column header of some sort,
which means although you might not be able to “convert” from (a: Int, b:
Int) to (x: Int, y: Int) …. you would be able to `map` the values and the
"column headers” to (x: Int, y: Int).

On 2016-02-05, at 19:41:19, Maximilian Hünenberger via swift-evolution < > swift-evolution@swift.org> wrote:

Sleeping over it I have to give -1 to the proposal. However we should
consider making explicit casts with "as" to different tuple types with and
without labels (separate proposal).

- Maximilian

Am 05.02.2016 um 08:08 schrieb Taras Zakharko via swift-evolution < > swift-evolution@swift.org>:

The types are clearly different and the current behaviour is fine as it
is.

However, it would be nice to have more support for tuple types in the
language. E.g. I’d expect something like this

let x = (a:4, b:5)
let y = x as (m: Int, n: Int)

to work (but it doesn’t currently, you have to use forced cast).

— Taras

On 05 Feb 2016, at 07:47, Ondrej Barina via swift-evolution < > swift-evolution@swift.org> wrote:

-1 for proposal. Current behavior is fine. There is no need to change it
Ondrej b.
On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" < > swift-evolution@swift.org> wrote:

> On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger < >> m.huenenberger@me.com> wrote:
>
> Is this behavior intended?
>
> What disadvantage do I have if a conversion from (a: Int, b: Int) to
(x: Int, y: Int) is allowed?

If that were allowed, then it also stands to reason that a conversion
from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would
not swap the elements. IMO, it is best to disallow things misleading
things like this.

-Chris

>
>
> Thank you for clarification
> - Maximilian
>
>> Am 05.02.2016 um 00:11 schrieb Chris Lattner <clattner@apple.com>:
>>
>>
>>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger < >> m.huenenberger@me.com> wrote:
>>>
>>> Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs:
Int) as separate types?
>>
>> I’m not sure what you mean by “separate types”. One has labels, one
does not, so they are clearly separate.
>>
>> Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int,
b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int,
y : Int)”.
>>
>>> Is there a connection to your tuple splat proposal?
>>
>> No connection at all.
>>
>> -Chris
>>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution