[swift-evolution] [Pitch] Replace 'inout' with '&'

[Matthew Johnson]

> On Dec 21, 2015, at 12:43 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> On Mon, Dec 21, 2015 at 10:40 AM, Matthew Johnson
> <matthew at anandabits.com> wrote:
>> 
>>> On Dec 21, 2015, at 12:36 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> On Mon, Dec 21, 2015 at 10:34 AM, Joe Groff <jgroff at apple.com> wrote:
>>>> 
>>>>> On Dec 18, 2015, at 6:52 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>>>> 
>>>>> On Fri, Dec 18, 2015 at 6:21 PM, Joe Groff <jgroff at apple.com> wrote:
>>>>>> 
>>>>>> On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <gribozavr at 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?

> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/