Manifesto: Adding memory ownership to Swift

Hit me up with any questions y'all have.

The argument for Swift's behaviour is basically: very few things actually need this guarantee, and it's bad for performance (or memory usage) for all the other types to inherit it.

Personally, as someone who has spent a lot of time trying to manage the safe/unsafe code boundary, I'm inclined to agree with you. Unsafe code in Swift has an even scarrier subtle hazard: if the last uses of a value are through an unmanaged handle, the compiler won't know and can free the managed value before those uses. You need to insert a marker saying "please keep this alive". Even worse: returning a value, after inlining, isn't sufficient to establish a use!

That said, your lock handle example doesn't matter in swift today: you really want a lock handle to be a struct, and structs can't have destructors. You also want it to have move semantics, which don't exist yet. This proposal suggests moveonly values that could adopt destructors (like Rust), and if you're already adding an annotation for destructors, it's not out of the question to add another one asking for "true" lexical destructors.

Obj-C ARC could do this with NS_VALID_UNTIL_END_OF_SCOPE, but Swift only has withExtendedLifetime(), which is probably more typing than just using defer.

(The ObjC version would break if you ever threw an exception, ARC doesn't release objects during unwinding!)

The correct way would be to use a trailing closure.

Something like

    func fizzle() {
        lock_guard(mutex) {
           if (count_ >= 3) {return; }
           count_ = count_ + 1;
        }
    }

Where lock_guard() might be then something like this, implemented on some utility library:

    func lock_guard (_ m:Mutex, action: () -> Void) -> Void {
        m.lock();
        defer {
          m.unlock();
        }
        action();
    }

This is one of the RAII approaches in functional programming, using partial function application and higher order functions, to create new types of operations.

That code executes 4 times.

That's not how you do things in Swift:

  class Dwizzle {

  	private let countQueue = DispatchQueue(label: "hey debugger! I'm here!")
  	private var count = 0 //type inference to Int

  	func fizzle() {
  		countQueue.sync {
  			if count > 3 { return }
  			count += 1
  		}
  	}
  }

See, no need for mutexes, or defers, or that lock_guard.

Just simple closures you already know.

Now you want to expose the count variable to other types, always in a non-negotiable thread-safe manner?

  	private let countQueue = DispatchQueue(label: "hey debugger! I'm here!")
  	private var _count = 0
  	public var count : Int {
  		get {
  			return countQueue.sync {
  				return _count
  			}
  		}
  		set(newValue){
  			if newValue >= 3 {
  				self.countQueue.sync {
  					self.count = newValue
  				}
  			}
  		}
  	}

And maintain the rest.

Now what if you want to clean up, and need to only one fizzling executing at a time in the whole process? Doesn't matter which process calls the fizzling?

  class Dwizzle {

  	private static let countQueue = DispatchQueue(label: "hey debugger! I'm here!")
  	private var _count = 0
  	public var count : Int {
  		get {
  			return Dwizzle.countQueue.sync {
  				return _count
  			}
  		}
  		set(newValue){
  			if newValue >= 3 {
  				Dwizzle.countQueue.sync {
  					self.count = newValue
  				}
  			}
  		}
  	}

  	func fizzle() {
  		if count > 3 { return }
  		count += 1
  	}
  }

To me, your code looks like a semaphore, let me introduce you to my over-the-knee fully-functional semaphore that can implement your Dwizzle class:

  class HackerNewsSemaphore {
  
  	private let queue = DispatchQueue(label: "sem queue")
  	private var count = 0

  	func up(){
  		queue.sync {
  			count += 1
  			if executeWhenUp && onlyExecuteWhen(count) {
  				execute(count)
  			}
  		}
  	}

  	func down(){
  		queue.sync {
  			count -= 1
  			if count > 0 && executeWhenDown && onlyExecuteWhen(count) {
  				execute(count)
  			}
  		}
  	}

  	var executeWhenUp : Bool
  	var executeWhenDown : Bool

  	var onlyExecuteWhen : (Int)->Bool

  	var execute : (Int)->Void

  	init(whenTrue: @escaping (Int)->Bool, whenUp: Bool, whenDown: Bool, execute: @escaping (Int)->Void) {
  		self.onlyExecuteWhen = whenTrue
  		self.executeWhenUp = whenUp
  		self.executeWhenDown = whenDown
  		self.execute = execute
  	}
  }


  //test
  let dwizzle = HackerNewsSemaphore(whenTrue: { (i) -> Bool in return i <= 3},
                                    whenUp: true,
                                    whenDown: true,
                                    execute: { i in print("fizzle \(i)") })

  for x in 0...10 {
  	dwizzle.up()
  }

  for x in 0...10 {
  	dwizzle.down()
  }

  //output:
  fizzle 1
  fizzle 2
  fizzle 3
  fizzle 3
  fizzle 2
  fizzle 1

Neckbeards?

Many of us who like Rust also like Swift, and there are many Swift team members who have contributed to Rust.

What I do wonder about it is Swift's plan for things like tiny binaries (no runtime), no standard library, zero-cost (or predictable cost) abstractions...

I think this argument is the real justification :

"Memory ownership model: an (opt-in) Cyclone/Rust-inspired memory ownership model is highly desired by systems programmers and for other high-performance applications that want predictable and deterministic performance"

I think it could be used to implement mechanism such as dispatch queues, which are for now implemented in C.

The Swift memory model is current incoherent; this is an attempt to fix that. (defining accesses properly, properly preventing conflicting accesses in single threaded ways)

Boring single-threaded swift code can currently be incredibly slow for no clear reason; this is an attempt to fix that.(addressors++)

The details this manifesto covers need to be settled for ABI-stability, which is still one of the primary goals for Swift. (because it enables making it a part of Apple's OSes)