I'm so excited to see this moving forward. I think it's one of the last few things that Swift lacks to make it powerful enough for world domination. ^^
I have to say that the only and very little experience I have with ownership control is mostly from Rust so please bare with me if I say nonsense things. Also sorry for the long post, seems like I got late to the party (>60 replies! nice!).
This seems sensible.
If I understand correctly this means we won't have to "strongify" weak bindings to keep them alive during the same lexical scope? It always felt too extreme to have to do that.
What is not really clear is if a binding is no longer used after the middle point of a scope, will it still be "released" at the end of it or it will be immediately after its final use? I have a disconnect between what assumptions can be made as a general rule vs. in specific code. And I wonder what Rust does here.
I've been following the other thread and naming aside this looks very nice. But I have a question about the array example...
I'm still not sure I understand what provokes a change on the behaviour.
Are you saying that right now there is no copy when sorting because the values lifetime ends before the sort call and so we get the good performance we want? and that with the changes that won't be true anymore and thus we will have to explicitly move ownership to get avoid the copy?
If so, even tho I understand the overall goals, this feels like a regression on the smartness of the compiler/language :(
This feels very good. I didn't know inits and setters used "consume" on their arguments already! Being able to improve appends on data strcutures is awesome. And I think that it seems to have the right level of progressive disclosure since this bit doesn't seem something we will need on "normal" Swift code.
It will be interesting to see the bikesheddingon names. I thought that Rust naming was quite clear but consuming seems like a good analogy too. :)
As explained, this is in place in the standard library already (and a recent post has shown how prevalent is in the community too) so I'm just glad it's becoming public.
One thing I'm wondering tho is if there is a way the language can expose a more consistent view on coroutines. If I'm not mistaken, won't we have now multiple "coroutine like" systems? async/await and read/modify. It feels like those features are in reality just one. (I remember the starting days of async discussions and how it was decided to give them more specific names, now it feels like a more general was a better idea). I'm thinking other places of the language/stdlib would benefit from it.
This looks quite powerful to control copies in our code. My comments are just about naming so not really important: the @ annotation for no implicit copy feels out of place with the rest of this roadmap. And the copy function in my eyes reminds me too much of copy constructors on other langs which is not really what this is.
This is awesome! Letting the compiler force that parms on certain APIs can escape is something that has been needed for a while. Right now you just have to rely on docs and making sure you don't do weird things.
I think is the place where more benefit we will get as "normal" Swift programmers, specially the inout bit.
One thing I would like to get clarified is: does this effectively let us take an inout variable to an element in an array and mutate it trough the binding?
var array = ...
array.mutatingFunc() // super nice to use!
var element = array[1]
element.mutatingFunc() // doesn't change the original element... sometimes annoying
New:
inout element = array[1]
element.mutatingFunc() // did it change the original element inside the array? <3
This is one of the pain points I have still with arrays being value types. Sometimes makes it very awkward to work with them cause you need to go trough the indices and subscripts to have in place mutations. One of the best things about swift is how value types have "safe" mutability so it would be awesome if we could get that with bindings too :)
(EDIT: I see same question above, sorry for the dupe)
With this said I love this direction. I'm just a bit unconvinced by the naming which I guess can be discussed on the respective proposals. I think that looking for a word that can be used in all places will be better. That ref is very weird looking.