Hacker News Reader

Comment by mikeash | Hacker News Reader

There's a ton of discussion in the Swift world about when to use structs and when to use classes. And I just don't understand why.

Use structs when you want value semantics. Use classes when you want reference semantics. Boom. Done.

All the confusion and discussion and fighting seems to be because people don't understand the implications of value versus reference semantics, and instead of learning they try to come up with ad hoc rules and guidelines that will let them decide without understanding the actual differences.

View on HN

"And I just don't understand why."

I think you've correctly identified the source of confusion -- value vs reference. To you, that might be plain as day. But, to many iOS devs, they really couldn't explain the nuances.

I mean, look how much trouble beginner programmers have with the concept of Pointers for pete's sake.

But, I think you're right -- weird rules and guidelines just confuse the issue.

Andy Matuschak's functional swift talk puts the ref vs value discussion in practical terms of a Khan Academy drawing app:

http://2014.funswiftconf.com/speakers/andy.html

The issue is that most of the cocoa framework requires classes to work with it. For anything UI, you are going to be dealing with reference semantics unless apple gives us an alternative to cocoa touch like http://componentkit.org

The other issue is that too many programmers these days don't have a solid computer science background... I'm all for people being self-taught and learning programming on their own... But the downside of that prevents individuals from learning how things work at a lower level.

I've never written a line of Obj-C or Swift in my life, but all you have to tell me is "struct = value based, class = referenced based" and I immediately know how it works...

I'm going to take issue with this. This has nothing to do with having a solid computer science background -- in fact, I've seen way more architecture astronauts with CS degrees.

It has to do with learning stuff on a lower level -- whether or not you attend a school to do so. Us autodidacts who grew up on assembly language and C code will beg to differ on your use of the word "prevents".

I presume he's not talking about long-time autodidacts. He's talking about the many programmers who have six months of JavaScript experience from a bootcamp and are learning Swift.

I guess I'll ask this here, since you seem to know what you're talking about. I'm a cs major, and I just finished my first c class. I quite enjoyed getting my feet wet with the lower level aspects of c, c doesn't hold your hand much (compared to java or python at least) and I liked that you really have to think about what you want, and the best way to get it with c.

Do you have any books or exercises to recommend to help further my understanding of low-level computing? I'll be taking too and compilers in the fall, but I'd like to keep digging on my own.

I don't doubt that a lot of people fail to understand value versus reference semantics. What I find weird is how, rather than learning it, people keep trying to come up with crazy rules to avoid learning it. I guess they don't realize that it's the key here.

Agreed. You see the same vague cargo-culting in C#. The popularity of both (as the de-facto standards on Windows and OS X/iOS) has just led to a lot of people who've learned enough to "get things done" rather than understanding both practical and theoretical underpinnings of the systems that they're using.

It worries me, to a degree, because there's probably no way to make a programming language smart enough to protect users from these people.

In C#, there's a lot more issues though with val vs ref. The CLR JIT had some serious issues with structs. OTOH, there still is no way to stackalloc reference types, so in many cases you're forced to use structs so you can get decent performance. But I've zero formal training, and I've never found val vs ref particularly confusing. Though I did wonder why VB needed ByVal at all; couldn't it all be done ByRef?

But wow, this post... I've no idea how he came to the conclusion structs=functional. He just sorta dives into it? If you aren't sure on something, why not read up a bit more? Guess C is a really functional language since it's got structs everywhere.

There is no way to allocate objects of reference types on stack because references can easily outlive objects, leaving you with dangling references. And as I understand ByVal in VB.NET is redundant since it's the default option. It's just a leftover from VB6 where the default was ByRef. Crazy language.

> There is no way to allocate objects of reference types on stack because references can easily outlive objects,

That's simply due to a lack of analysis. In many cases it's easy to show the object is short lived. Yet there's no way to annotate this and AFAIK, the JIT doesn't even try to figure this out.

I think the problem is that most people coming to Swift come from languages like Ruby and JS where just about everything is a reference (or pass by value where every value is a reference anyway). The distinction between value and reference is really hard to grasp when your background is in languages that are opaque like that. I remember Go had tons of questions of this nature early on in its adoption upswing.

That's odd. You'd think most people would be coming from objc

Just the same in Objective C, unless you're dealing with a C struct (not being passed by pointer) or a primitive type you're in a sea of Objective C references. Value types are brand new to the non-Foundation framework ecosystem as far as writing new, stylistically correct, code is concerned. This in my experience does seem to be a sticking point for people without a good bit of experience in languages with the same or similar value and reference type split (C++, Java, C#, Rust, etc).

The thing is, every language I'm familiar with has some types with value semantics. Numbers, for example, are pretty much always values. Pretty much nobody is surprised at the behavior of code like this in languages like Ruby and JS:

    var x = 42
    var y = x
    x++
    print x // 43
    print y // 42

It seems that, for whatever reason, people understand this but have a really hard time generalizing it. It's not even a matter of custom types being a confounding factor, as I've seen deep confusion over the fact that Swift collections have value semantics.

Warning: I haven't learned Swift yet. So let's say you want to use value semantics so you choose a struct. But later you find that you have to change state of the values. Is your only resort then to switch to using classes? Because if that's true that's a false choice.

Values can still be mutated. Value versus reference isn't about mutable versus immutable. It's about whether when you do a = b you get a new instance or just a new reference to the same instance.

Values can't be mutated if they're Ivars and you're in a non-mutating func. Non-mutating funcs are unique to value semantics.

True but I'm not sure what your point is. If you need a mutating struct method then of course you have to mark it as mutating.

The point is that you don't always want to mark the method as mutating. This is explained in the article.

This is described in the article. I wouldn't say that it's explained. It makes no sense to me. Whether a method mutates state should be evident when you make it. The very concept of a value-type method which mutates state but isn't marked as mutating makes no sense at all. It sounds like it might be a case where you actually wanted reference semantics but accidentally used value semantics and are trying to make it work anyway.

One does not "simply" mark a method as mutating.

A) One must ensure that one's callers are also mutating, or otherwise have an assignable reference, all the way up the stack

B) One must mark the applicable function in the protocol interface as mutating, which may or may not be under your control

C) One must now repeat step A for all consumers of the protocol in step B, even if none of the other implementations of that protocol mutate their own state

Of course one can design one's architecture specifically with a view toward making ABC trivial, but in the general, unrestricted, default, I-had-other-problems-that-day-and-didn't-think-about-it case, they are hard.

That is why I find calls to "just learn value semantics" necessary but insufficient. Value semantics will not refactor my code when I discover-by-surprise that 18 functions need to become mutating, breaking API compatibility across several build targets, because I failed to forsee a necessary mutation 8 months ago.

I have trouble imagining a scenario like you describe. "All the way up the stack" should be, what, two or three levels at most? And whether or not a particular method is one that changes state or just fetches it should be evident from its semantics. What are you doing where you would suddenly discover that a method is mutating, months after you originally created that method?

Ok thanks. Looking at this from a Lisp programmer's perspective values are by definition immutable. The Swift ecosystem seems very complex.

Variables can be mutated in Lisp. That's all this is.

Variables are not values.

Thr point is, this is a matter of definition, in that people often use the word "value" where "variable" or "object" could be used, especially as to distinguish from references. This is common usage in other languages too. It has nothing to do with Swift being complex.

OK, I can appreciate your stance, but can you explain the difference? (Or at least point to a reference that does?)

  let a = MyStruct(x: 1, y: 2)
  let b = a // Creates a copy of `a`
  b.x = 3 // Won't compile because you used "let", so its properties are immutable
  var c = a
  c.x = 3
  println(a.x) // Prints "1"; the original instance doesn't get changed

  let d = MyClass(x: 1, y: 2)
  let e = d // Refers to the same object as `d`
  e.x = 3 // Allowed, even though you used "let"
  println(d.x) // Prints "3"

That's a basic illustration of the difference between value types and reference types, but there are other differences between structs and classes as well (for instance, structs don't support inheritance or deinitializers).

Nice example, thanks!

It comes down to equality. Values have "extensional equality" which means that values A and B are equal exactly and only when they look the same and can be used in the same way. On the other hand, most people are used to "referential equality" which is more strict. It lets me distinguish "your copy" of A from "my copy" of A via their names.

Without referential equality things like mutation fail to have any sense, but programs are in general simpler.

Cool, thanks for the distinction! Gives me some terms to look up for more info, too.

Reply on news.ycombinator.com