[swift-evolution] [Discussion] Removing tuple labels from the type signature

Fri Feb 5 16:42:51 CST 2016

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 at 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 at 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 at 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 at 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 at 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 at 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 at swift.org> wrote:
>
>>
>> > On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger <
>> m.huenenberger at 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 at apple.com>:
>> >>
>> >>
>> >>> On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger <
>> m.huenenberger at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160206/e65f4f0a/attachment.html>