Should I use a Swift struct or a class?

http://faq.sealedabstract.com/structs_or_classes/

by ingve • 11 years ago

53 52 11 years ago

faq.sealedabstract.com

kaonashi2• 11 years ago

or: how I stopped worrying and accepted making programs that are hard to reason about

nickbauman5• 11 years ago

Right? I've always been amazed at how people just accept this state of affairs.

durandal1• 11 years ago

If you want to contribute, write why you disagree instead of attacking the author as a person.

kaonashi2• 11 years ago

Wasn't trying to attack; sometimes trying to create a perfect mathematical model for your program can get in the way of having a program at all.

zephyz• 11 years ago

This post is basically saying "I don't understand programming and I won't even try"

chowells• 11 years ago

Functional programming isn't about eliminating state. You can't write programs without state. Functional programming is about eliminating hidden state changes.

State changes are fine! They just aren't allowed to be hidden.

Despite all that - I agree that move semantics are weird. He's got a point there.

grabcocque2• 11 years ago

In the presence of concurrency, shared mutable state is a disaster. There are two ways to fix this:

1) Make it not mutable 2) Make it not shared

But these are still "state", so I'm not really sure what the hell the article is on about.

oldmanjay• 11 years ago

3) synchronize correctly, which is fraught in nearly all languages. Rust has some very nice facilities for this, however, that make shared mutable state very usable indeed.

seanmcdirmid• 11 years ago

If you don't have shared mutable state or shared resources, then you don't really have concurrency. Concurrency is actually defined as this problem, as opposed to parallelism which is just about splitting up work.

grabcocque2• 11 years ago

One thing I've learned, if you want to convince people you're right, best to insult them and tell them they're "on crack".

Guaranteed to work.

mikeash7• 11 years ago

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.

eropple• 11 years ago

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.

MichaelGG2• 11 years ago

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.

nickbauman5• 11 years ago

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.

mikeash7• 11 years ago

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.

rubiquity• 11 years ago

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.

blazespin• 11 years ago

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

mikeash7• 11 years ago

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.

gdubs• 11 years ago

"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

masters3d• 11 years ago

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

ajg360• 11 years ago

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

mikeash7• 11 years ago

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.

holyjaw3• 11 years ago

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

RussianCow• 11 years ago

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

tel2• 11 years ago

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.

nickbauman5• 11 years ago

If your understanding of functional programming regarding state management is monads, I'd argue you don't understand. Monads are the guided nuclear missile of functional state management. If you don't know why you need them you don't need them. There are simpler ways to manage state in FP.

tel2• 11 years ago

Monads aren't nouns. When you build a state transformer you can choose whether or not to recognize that it is a monad (or maybe strong profunctor, depends upon your design) but it always just IS one.

oulipo• 11 years ago

Not sure though why you justify the fact that you should'nt use singletons embedded in a struct because they are copied by reference? If it is a singleton, you want it to be copied by reference. And you actually expect it to be since you want all the structs to refer to the same object?

You should not use an embedded class in a struct if it is not a singleton, as in the UIBezierPath example, where when you copy the struct, you expect to do a copy-on-write of the class to avoid mutating all copies in all structs

alexjarvis2• 11 years ago

What a stupid, long blog post

alexjarvis2• 11 years ago

Also why no mention for the enum, the other value type that allows for pattern matching?

lyinsteve• 11 years ago

Surprisingly salient and cogent points for an article that's so hostile and willfully ignorant.

The author is correct about when to use both, and I'm glad he doesn't discount structs entirely like I've seen from some OOP strongholds.

"The way they write functional programs for decidedly non-functional problems is through a trick called a monad, which I will not explain and nobody understands anyway,"

Maybe you'd be less hostile if you actually took the time to learn about generic abstractions and how they can greatly simplify a codebase.

Hint: Optional is a monad, and you can use it as such.

josteink• 11 years ago

So ios devs, who supposedly need to write in a memory unsafe language because that's just better, don't understand the basic difference between pass by reference and pass by value.

Nice. What can possibly go wrong?

Looking forward to seeing the questions in the swift SO site.

WoodenChair2• 11 years ago

Seems like a pretty good article, but as a blog, his site is violating the "put a date" principle: http://www.observationalhazard.com/2014/09/put-date-on-your-...

MakeMake• 11 years ago

Ah, an excuse why two almost identical language constructs exist. Welcome to the list of cluttered programing languages.

Should I use a Swift struct or a class?

Related Stories