Pitch: `borrow` and `inout` declaration keywords

[filip-sakel]

@ksluder

be a semantic change? Pattern-matching with var against an inout parameter doesn’t implicitly give the var write-through semantics. You still need to reassign to the original inout binding:

I don’t think so. If you were calling a function g(arg: inout E) within f, you’d still have to write g(arg: &arg). So the ampersand would still be required in the switch. That said, I agree it would be a very subtle change to remove the ampersand, and then have the code not save the mutation to the inout argument.

[Alejandro_Martinez]

These functionality is the one I’m most eagerly expecting. Mutable value semantics is one of the best things about Swift, but sadly it forces you to do some awkward things like use subscripts and forbids using local vars.
I hope that with ‘inout bindings’ we can write more normal looking code while still benefiting from mutable value semantics.

[tbkka (Tim Kientzle)]

@ksluder

func foo() {
  var myStruct = MyStruct()
  inout alias = &myStruct.someProp
  // from now until the end of the function,
  // myStruct is inaccessible because it is being exclusively accessed
  // via the alias to its someProp property
}

This is already guaranteed by SE-0176. inout alias here is a "read/write access" (in the language of SE-0176) for it's entire lifetime (which is defined in my pitch to extend to the closing }) and so any access to myStruct after that point is an exclusivity violation.

@pyrtsa

Is there any way to allow temporarily splitting the value into multiple distinct inout parts without any of the examples below being an exclusivity violation? With some new syntax, if need be?

That's certainly desirable and I would like to see it in the future but this pitch doesn't currently support this case.

@pyrtsa

// Future direction?
inout (a, b, ca) = &t.(.a, .b, .c.a)

I like this syntax. I'll add it to the pitch as a "Future Direction."

@fclout

I imagine that it doesn't allow using the ternary or nil coalescing operator either, but that doesn't seem to be spelled out:

// probably not legal?
inout x = foo ? &int1 : &int2

No, that would not be supported. I've been told by the folks implementing this that there is some additional complexity around any kind of conditional binding. I'll explicitly add this to the pitch.

@Andrew_Trick

But note that the following case is perfectly fine:

do { // Legal: borrow of an inout binding
  inout a = &t.a
  borrow a2 = a // ✅
}

Yes, but I believe the a2 binding here should make a inaccessible for writing (following SE-0176).

@Andrew_Trick

If we want inout bindings to have "no-implicit-copy" behavior, then we should use a different name.

@TeamPuzel

So when I see

inout x = y

I can't imagine what this keyword means.

@taylorswift

i really think we cannot use inout in the position where let or var occurs today, it just looks wrong

I'd be interested in hearing people's suggestions for alternate names for this keyword.

Tim

[cal (Cal Stephens)]

Looking forward to this! inout in particular seems useful for simplifying in-place modification of complex nested collections.

Will optional unwrap conditions using borrow and inout support the shorthand introduced in SE-0345? For consistency with let and var, I expect we'd want to support this functionality for these new introducers as well.

In the Future Directions of SE-0345, it suggested spellings like this for conditions using the new borrow introducers:

if borrow optional { ... }
if inout &optional { ... }

// shorthand for:
if borrow optional = optional { ... }
if inout optional = &optional { ... }

[ksluder (Kyle Sluder)]

@tbkka

I'd be interested in hearing people's suggestions for alternate names for this keyword.

Resurrecting my previous suggestion:

inout var x = &foo // long form of `inout x = &foo`
inout let y = bar

[taylorswift]

@ksluder

Resurrecting my previous suggestion:

inout var x = &foo // long form of `inout x = &foo`
inout let y = bar

i still feel that this needs to go where the type annotation usually goes. perhaps we can special case it so that the _ type is not needed:

var x:inout = &foo

inout before the variable name just doesn’t make sense.

[ksluder (Kyle Sluder)]

@taylorswift

inout before the variable name just doesn’t make sense.

Sorry, I simply don’t agree.

[David_Smith]

Is this basically about whether inout refers to the variable binding or the type? That would imply it should go on the left in all cases right?

[taylorswift]

@ksluder

Sorry, I simply don’t agree.

a long time ago, back when dinosaurs roamed the earth we had:

func foo(var x:T)

func bar(y:inout T)

we got rid of var x:T because it was too easily confused with y:inout T. but the principle remains that:

• whether or not something can be mutated by the caller goes to the left of the variable name (let, var).
• the effects of that mutation go to the right of the variable name, it is more closely related to the type of the variable than the binding of the variable. nowadays we call this a storage modifier. (inout, __shared, __owned.)

so i think it would be confusing to put a storage modifier where let/var usually goes.

@David_Smith

Is this basically about whether inout refers to the variable binding or the type? That would imply it should go on the left in all cases right?

exactly. inout, like __shared and __owned, is actually neither, it goes “in the middle” so to speak.

at any rate this is something that has already been settled, we don’t write func foo(inout x:T), we write func foo(x:inout T).

[tbkka (Tim Kientzle)]

@taylorswift

var x:inout = &foo

I'm concerned that this syntax looks far too much like it's "constructing a pointer" and assigning it to a "variable with reference (inout) type." That in turn might lead people to believe they can "rebind x".

var x: inout = &foo
x = &bar   //  Illegal in the pitch

[ksluder (Kyle Sluder)]

@TeamPuzel

Isn't it still conflicting with the existing meaning of inout as a copy, regardless of where it is?

I agree with @Andrew_Trick that inout should not imply “no-implicit-copy”. It just means “mutate under an exclusive borrow”. Semantically, this is a copy/modify/writeback, but the copy itself can be elided as long as didSets fire for the whole aggregate.

[David_Smith]

@taylorswift

so i think it would be confusing to put a storage modifier where let/var usually goes.

I think I disagree that inout is a storage modifier. It modifies a binding, not the storage. Basically I'm claiming that the existing x: inout T should always have been inout x: T.

[pyrtsa (Pyry Jahkola)]

@David_Smith

Basically I'm claiming that the existing x: inout T should always have been inout x: T.

Had it been that way, how would you spell the type of a function taking an inout argument? (That said, I'm all fine placing the borrow or inout where the let or var is.)

[taylorswift]

@tbkka

That in turn might lead people to believe they can "rebind x".

var x: inout = &foo
x = &bar   //  Illegal in the pitch

today, we don’t really have an issue with:

func foo(x:inout T)
{
    var y:T = ...
    x = &y // not valid
}

so i don’t see how the new scenario is that different from “rebinding” an inout function parameter.

@David_Smith

I think I disagree that inout is a storage modifier. It modifies a binding, not the storage. Basically I'm claiming that the existing x: inout T should always have been inout x: T.

it isn’t a ‘real’ storage modifier but it’s been long-established that it goes where the storage modifiers go. to change the language syntax to put inout before the variable name would be massively source-breaking. and to have a split syntax where the same construct is written one ways in a function signature, and written backwards elsewhere seems like the worst of both worlds.

[David_Smith]

func foo(inout x: T) seems logical? I have not spent a lot of time thinking this through, and I just got back from vacation, so it's entirely possible I'm missing something obvious

[taylorswift]

@David_Smith

func foo(inout x: T) seems logical? I have not spent a lot of time thinking this through, and I just got back from vacation, so it's entirely possible I'm missing something obvious

for the record, i think that you are right, and if this were the swift 3.x days, it might have made more sense to place the inout before the variable name. but these are not the swift 3.x days, and i think it is more important to be consistent with the existing language syntax.

because regardless of how you feel about where it belongs, changing the positioning of inout in 2023 is not realistic.

[pyrtsa (Pyry Jahkola)]

I mean in a type, like (inout Foo) -> Bar.

[David_Smith]

ah I see. Good question!

[taylorswift]

@pyrtsa

I mean in a type, like (inout Foo) -> Bar.

to spend a few moments in wonderland, we could rationalize this as just saying that we have “deleted” the variable name and the colon, since function types cannot have argument labels.

but this reminds me of spiral const * const * const * const in C, and i always found that very difficult to read.

[fclout]

The tension seems to be that the current inout is a type modifier because it can be nested in function types, but it can't be used anywhere else that a type is expected, so it really feels like a declaration modifier.