Structures and Classes : Quick Reference Guide

Using Swift
,
1

I made a Quick Reference Guide for Structures and Classes.
(One Pager.)
What thinks?
:rainbow::pray::rainbow:

2550×3300 262 KB

2 Likes
2

great work! a few notes:

  • all swift types, including structs and enums support typecasting, because all (copyable) types can conform to protocols.
enum E:Error
{
    case e
}

let erased:any Error = E.e

if let e:E = erased as? E
{
    ...
}

  • @_moveOnly structs do support deinitializers, at least according to the rumors.

  • letting an optional instance property use implicit initialization is a bad idea for performance reasons. write out var name:String? = nil explicitly, or better, assign it from an init. see this thread for an explanation why: What is a 'variable initialization expression'?

  • memberwise struct initializers will never be more than internal, to expose a public initializer, you have to write it out explicitly.

  • “a value type sends a copy whenever it is passed” is largely meaningless in practical swift development, both because of the prevalence of inlining, and because many structs are just values of references, which could possibly be copy-on-write references to make them behave as if they were values from a mutation perspective (e.g., [Int]).

    also, don’t confuse value types with value semantics. classes can have value semantics, if they are completely immutable, and a struct that wraps a class with mutable state can also have value semantics, by implementing copy-on-write.

  • a class value is literally a pointer. this is actually quite important when writing generic data structures, because if you can constrain the element type parameter to AnyObject the compiler is able to optimize layout more aggressively.

2 Likes
3

Structs and Classes are types. Types start with a capital letter. Properties and methods start with a lower case letter.

I'd make it clear that that is just a style convention in Swift. It's not strictly part of the language, unlike, say, Haskell.

2 Likes
4

I wish it was. The consistency PEP 8 in Python and gofmt in Go is so nice. :smiley:

1 Like
5

Boy, technical writing is hard, but I really wish we had a good resource to explain reference vs value semantics. Most mentions of "structs are value types and classes are reference types" are woefully simplistic and just cause further confusion down the road :/

See also: Question about CoW on value type - #10 by AlexanderM

3 Likes
6

I was trying to 'explain' reference vs. value types the other day. I wrote a paragraph, linked to a page on Wikipedia, then waded into actual code. It's hard to explain as everyone with even basic OOP programming knowledge knows the difference already. They just probably aren't used to thinking about it.

For the quick reference guide; classes being reference types and structs being value types is what makes them different. Everything else, such as classes having inheritance, reference counting, casting between classes, follows from it. I would mention reference v. value at the start.

1 Like
7

Firstly, thank you, @taylorswift, @AlexanderM, @JohnBlackburne, and @jeremyp for your comments.

Secondly a bit of context... I am a beginner at Swift although I have coded in several other languages and I'm excited to get up to speed quick. This exercise is to summarize and make Quick Reference Guides (QRG) from the pages found at https://docs.swift.org/ which is published by Apple Inc. so, I guess those pages are coming "straight from the horse's mouth". Anything in the QRG is said by Apple.

The goal of the QRG is to be a "Cheat Sheet" of sorts. Something quickly and easily referenced to check knowledge of a programming fact and if deeper explanations are needed, by all means see the source doc noted at the bottom of the QRG. I'm aiming for a "one pager" to summarize the contents of that long page in the source. So they might be "light on verbose explanation" but heavy on "this is how it works quickly and tersely as a reminder or review". I'm learning a lot in the process of making these and I plan on using them myself and I am happy to share them with the community because they don't seem to exist anywhere. (If you google "Swift Cheat Sheet" you will find one good four page PDF and one less-than-good document that is one page long, and that's about it.)

I'm trying not to do too much editing apart from condensing the Apple Documentation, but I like your suggestion, @JohnBlackburne to put the Value Type vs. Reference Type distinction at the beginning. There is a great Value Type vs. Reference Type explanation in the source page noted in the footer:

https://docs.swift.org/swift-book/LanguageGuide/ClassesAndStructures.html

...

@taylorswift, I would be happy to incorporate your edits, but I would like to understand them completely first before doing so.

Regarding deinit, I found this page:

Regarding @inline, I found this page:

Regarding value semantics I found this page:

Value SEMANTICS (not value types!).

And regarding pointers, I was just quoting "The Apple Textbook" via the source page in the footer.

@taylorswift I feel like you know what you are talking about and are a Swift God Tier Level. :clap:

...

@jeremyp Edit Accepted. Thank you. I added a bit about naming capitalization being a common human convention and not hard-coded into Swift.

...

Ok, so here is version 2.0, with color coding similar to the source document, and Value/Reference discussion toward the front :

1700×2200 194 KB

Also, here is an updated, colorized release (Thank you Ted Turner.) of the first QRG on Basic Operators :

2550×3300 361 KB

What thinks?

:rainbow::pray::rainbow:

1 Like
8

I'm glad it's not. Whilst I adhere to Swift style identifiers it in all languages where possible, there are other aspects of standard Swift style that I absolutely loathe e.g. K&R braces. Style should not be dictated by the language designers IMO.

Anyway, this is off topic, so I'll say no more on the subject.

2 Likes
9

On a pedantic note, Swift's remainder operator is technically not modulo. It gives a different result to what I would regard as the One True Modulo for negative dividends. You could probably just add that the result has the same sign as the dividend e.g. -7 % 4 == -3.

1 Like
10

@jeremyp Thank you. I changed "(Also known as : Modulo.)" to "(Similar to : Modulo)" because I have heard people call "%" Modulo commonly all the time.

And I added:

// The result has the same sign as the dividend.

Again, thank you, and thank everyone for a rigorous look at this fun and educational and hopefully useful-to-someone-besides-me project.

:rainbow::pray::rainbow:

2 Likes