> Wow there are some real doozy inout code examples in there, showing > aliasing much more fun than my snippet. Unfortunately I can't > understand anything else the doc is talking about. I guess I'll just > say a prayer and throw salt over my shoulder if using inout.
Sorry! Here's the money quote from that document: > ##### If you didn't catch all that... > > That may have been a somewhat intense description, so here's a simple summary > of the rule being proposed. > > If storage is passed to an inout argument, then any other simultaneous > attempt to read or write to that storage, including to the storage containing > it, will have unspecified behavior. Reads from it may see partially-updated > values, or even values which will change as modifications are made to the > original storage; and writes may be clobbered or simply disappear. > > But this only applies during the call with the inout argument: the evaluation > of other arguments to the call will not be interfered with, and as soon as > the call ends, all these modifications will resolve back to a quiescent state. > > And this unspecified behavior has limits. The storage may end up with an > unexpected value, with only a subset of the writes made to it, and copies > from it may unexpectedly reflect modifications made after they were copied. > However, the program will otherwise remain in a consistent and uncorrupted > state. This means that execution will be able to continue apace as long as > these unexpected values don't trip up some higher-level invariant. -- Brent Royal-Gordon Architechies _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
