> On Dec 21, 2015, at 11:07 AM, Matthew Johnson <matt...@anandabits.com> wrote:
>
>
>> On Dec 21, 2015, at 12:43 PM, Dmitri Gribenko <griboz...@gmail.com> wrote:
>>
>> On Mon, Dec 21, 2015 at 10:40 AM, Matthew Johnson
>> <matt...@anandabits.com> wrote:
>>>
>>>> On Dec 21, 2015, at 12:36 PM, Dmitri Gribenko via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 10:34 AM, Joe Groff <jgr...@apple.com> wrote:
>>>>>
>>>>>> On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <griboz...@gmail.com> wrote:
>>>>>>
>>>>>> On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgr...@apple.com> wrote:
>>>>>>>
>>>>>>> On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <griboz...@gmail.com>
>>>>>>> wrote:
>>>>>>> There's also a possibility that we add 'out' parameters in the future,
>>>>>>> and
>>>>>>> if 'inout' would be spelled '&', then we would need to find another
>>>>>>> sigil
>>>>>>> for 'out'.
>>>>>>>
>>>>>>> We have multiple returns. Why would we ever add out parameters?
>>>>>>
>>>>>> I don't want to turn this thread into a discussion about out
>>>>>> parameters, but one reason would be to replace
>>>>>> AutoreleasingUnsafeMutablePointer.
>>>>>
>>>>> IMO we should eventually import out params from C as multiple returns.
>>>>>
>>>>>> Another one is to add labels to
>>>>>> the output parameters:
>>>>>>
>>>>>> let (day, month, year) = parseDate()
>>>>>> let (year, day, month) = parseDate() // bug?
>>>>>
>>>>> Labeled tuples seem like they could help with that, with compiler QoI to
>>>>> catch cases like this where you obviously permuted the return names.
>>>>
>>>> Currently they don't help:
>>>>
>>>> (swift) func parseDate() -> (day: Int, month: Int, year: Int) { return
>>>> (0,0,0) }
>>>> (swift) let (year, month, day) = parseDate()
>>>> // (year, month, day) : (Int, Int, Int) = (0, 0, 0)
>>>
>>>
>>> Looks like they help to me:
>>>
>>> func labeledMultiReturn() -> (string: String, int: Int) {
>>> return (string: "hello", int: 42)
>>> }
>>>
>>> let (string: boundString, int: boundInt) = labeledMultiReturn()
>>>
>>> print(boundString)
>>> print(boundInt)
>>
>> Well, they don't *force* you to use labels at the use site,
>> allowing bugs to happen even if the API author went out of their way
>> and used labels.
>
> Got it. Objection understood. That said, wouldn’t it be a relatively small
> change to require their use at the call site when the API author includes
> them in the return type, at least when the result is directly bound to
> variables?
That, or require either the label be explicit or that the binding name match
the label. 'let (foo: foo, bar: bar)' would be a bit unfortunate.
-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
