Manifesto: Adding memory ownership to Swift

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.

Something like

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

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

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

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
  		}
  	}
  }

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
  				}
  			}
  		}
  	}

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
  	}
  }

  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

"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.

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)

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...