Swift struct custom deinit

Using Swift
1

Hello, is it good or wrong idea to have custom deinit in structs?
Possibly, one use case of custom deinit is to implement smart pointers in swift using structs.
What are consequences of allowing declaration of deinitializers in structs?
Btw: is it good idea to have smart pointers in swift stdlib?

2

Basically, Swift uses smart pointers all over the place since day one — at least as I understand that concept (a pointer that does not need to be freed manually).

3

could you, please, point out smart pointers used in swift?

4

All (or at least many — Swift can be quite complicated ;-) objects except simple structs have a retain count, which is incremented on assignment, and decremented when a variable ceases to exist.
For me, that is a smart pointer.

UIView, NSNumber, NSArray... all smart pointers.
CGRect, Float, Double are some types that are not.
Stuff like String and Array is more complicated because of copy on write, but basically, those are (or use) smart pointers as well.

5

primitive example of what i mean "smart pointer":

struct UniqueSmartPointer<T> {
	private var unsafeMutablePointer: UnsafeMutablePointer<T>?
	private var is_locked = false// semaphore/mutex
	
	init() {
		self.unsafeMutablePointer = UnsafeMutablePointer<T>
	}
	
	init(unsafeMutablePointer: UnsafeMutablePointer<T>?) {
		self.unsafeMutablePointer = unsafeMutablePointer
	}
	
	deinit{
		self.unsafeMutablePointer?.deallocate()
	}
}
6

Normally, you should avoid anything that has a "Unsafe"-prefix ;-) - but of course, it's fine to play with those to get a better understanding.
In production code, there's rarely need to "invent" such structs.

Swift is trying hard to become as complicated as C++ ;-), but it currently lacks some features you will probably need when you want to guarantee uniqueness, though.

7

Normally, you should avoid anything that has a "Unsafe"-prefix

yes, the user of such smart pointer(from my example) dont need to care that Unsafe is used inside smart pointer.
The user simply uses those smart pointers like this:
var smartPointer: UniqueSmartPointer<Int> = UniqueSmartPointer()

8

That's a perfect use for a class. I don't see a need to add deinit to structs.

1 Like
9

in swift class is ref type, and if one uses class then ARC is involved, but if there would be smart pointers implemented using struct, then the performance would be increased

10

Smart pointers are reference counted. That's how the pointer knows when to dealloc whatever it's pointing at. If you wrap an Unsafe*Pointer/Buffer in a class, you're just moving the reference counting to the wrapper, but you're not changing the fundamental performance characteristics of a smart pointer.

11

could you, please, tell why The Swift standard library and Foundation use structures(and not classes) for types such as numbers, strings, arrays, and dictionaries?
Is it because of performance difference between struct and class?

12

Value semantics.

13

I think that you might want to look at the Array documentation Apple Developer Documentation and look for the bit about copy-on-write. Then isKnownUniquelyReferenced might be of interest How to safely use reference types inside value types with isKnownUniquelyReferenced() - free Swift 5.4 example code and tips

Chances are that, with all of that, you'll see that you can get most of what you're after. If not, could you clarify what smart pointers provide that you want available in swift?

1 Like
14

what smart pointers provide that you want available in swift?

one of idea was to add smart pointers in swift stdlib for those who not want to use class type because of possible performance issues(of ARC): if inside smart pointer struct would be UnsafePointer then that smart pointer would be faster than class type managed by ARC

15

Then the Ownership manifesto is probably what you're looking for.

16

maybe some attribute like @noncopy will be needed for smart pointer struct:

@noncopy struct UniqueSmartPointer<T> {
....
}

@noncopy means move semantics(something like in rust lang) instead of copy

17

We have talked about move-only types in Swift for years. They are discussed in the ownership manifesto TJ linked above.

18

thank you, something what i thought