Resource access and lifecycle

As Swift continues to evolve, it has become difficult to prevent multiple accessors from modifying all resources in a coordinated manner such that copies of accessors to memory (variable value assignment) in multiple concurrent or reentrant code wind up with inconsistent data because the value was changed “behind the back” of other accessors.
This is currently a major problem in Swift 5.1 and we have an opportunity in Swift 6+ to fix this.

Just to throw out an opinion and possible solution, Swift has so many options and implicit “timesavers” in it now that it is ranked by many that I’ve spoken with as being so all-encompassing and catering to non-explicit fans that it has become one of the hardest languages to master and more importantly, maintain. The next Ada.
To solve the multiple accessor conflict I would like to see all variables, be true class types. All access to a memory location containing the attributes of that variable type would have all methods like +,-,= and so on, would be defined as methods of types in a module that would require an ‘IMPORT Int, Float’ or an entire module import as in ‘IMPORT Numerics’. This flags the compiler and users of exactly where these object types are defined. The definitions could be done ala Modula 2 as a definitions module and implementation module pair.
This would allow libraries and and other proprietary code to remain hidden yet code that uses these modules be compilable but not linkable. The object nature of data types would allow allow access and lifecycle control via a single point instantiation, eliminating multiple copies of variables in memory and therefore no hidden changers of value or other attributes.
This should simplify garbage collection and allow for a finer grained cleanup perhaps eliminating performance slowdown transients.
I’m also in favor of removing implicit behavior or finding a way for code maintenance to find these instances. I feel they are contrary to the entire hard typing paradigm as one of its most useful side effects, other than preventing incompatible use of types, is clarity of exactly what is being done by code.

Terms of Service

Privacy Policy

Cookie Policy