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 <rjmcc...@apple.com> wrote:
>
>
>> On Jun 9, 2017, at 2:42 PM, Gor Gyolchanyan via swift-evolution
>> <swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
