[swift-evolution] Should closures support inout parameters?

[Chris Lattner]

> On Sep 18, 2016, at 8:17 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Fri Sep 16 2016, Braeden Profile <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I was writing some code that would allow transformations of values as
>> part of an expression, and I came across a strange error:
>> 
>> /// Returns the operand after a given transformation.
>> ///
>> /// Example:  `let newRect = myRect << { $0.origin.x += 3 }`
>> func << <T> (given: T, transformation: (inout T) -> ()) -> T
>> {
>> 	var result = given
>> 	transformation(&result)
>> 	return result
>> }
>> 
>> let volume = component.volume << { $0.ranges.z.width = 0 } // Error:
>> Expression type () is ambiguous without more context.
>> let volume = component.volume << { $0.ranges.z.width = 0; return () }
>> // Error: Cannot assign to property: ‘$0’ is immutable.
>> let volume = component.volume << { (x: inout SCNBoxVolume) in x.ranges.z.width = 0 } // Succeeds!
>> 
>> Obviously, this code could easily create a var for volume and mutate
>> it, but it doesn’t solve my problem.  Am I misunderstanding how this
>> could work?  This is the only overload of << that accepts a closure,
>> and even the code completion recognizes that $0 is a SCNBoxVolume.
>> It’s just strange that the compiler won’t recognize $0 as an inout
>> parameter off the bat.
> 
> I think the subject you wanted was “should we deduce closure inout
> parameters?”
> 
>> Is this a bug, or a design choice?
> 
> I've been wondering the same.  I hope it's a bug, and I suggest you file
> it.

It’s a bug, it has been filed several times, it is pretty well known at this point.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160918/e4a0eff6/attachment.html>