[swift-evolution] History and future of Swift's parentheses

[Gor Gyolchanyan]

You can kinda do this already:

func foo(_ parameter: inout ParameterType) {
	var shortcut: TheType {
		get {
			return parameter.very.very.long.and.tedious.inout.member
		}
		set {
			parameter.very.very.long.and.tedious.inout.member = newValue
		}
	}
	// shortcut is of type `inout TypeType`
}

This is exactly what I imagine the compiler generating when I write this in a hypothetical Swift:

func foo(_ parameter: inout ParameterType) {
	var shortcut: inout TheType = parameter.very.very.long.and.tedious.inout.member
}

Or, using type inference:

func foo(_ parameter: inout ParameterType) {
	var shortcut: inout = parameter.very.very.long.and.tedious.inout.member
}

> On Jun 10, 2017, at 8:25 AM, John McCall <rjmccall at apple.com> wrote:
> 
> 
>> On Jun 9, 2017, at 2:42 PM, Gor Gyolchanyan via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> My answer to `inout` is to promote it to a full-fledged "storage class" (in C terminology) and allow normal variables to be `inout`.
>> This would immediately solve the problems with `inout` being a magical thing in functions, as well as a convenient way of storing "references" (in C++ terminology) to potentially huge inout expressions, not to mention returning an inout from a function, effectively spreading the getter-setter awesomeness to everything else besides properties and subscripts.
> 
> C++ implements this idea by being utterly unsafe; Rust implements it by introducing entire new dimensions of language complexity.  Are you proposing one of these in particular, or do you have your own concept?
> 
> John.