Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should I use a Swift struct or a class?

faq.sealedabstract.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Should I use a Swift struct or a class?

#41

Post by MichaelGG »

dfkf wrote: post #40
MichaelGG wrote: post #33

Earlier quoted context omitted.

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 wo…

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.

Re: Should I use a Swift struct or a class?

#42

Post by SamReidHughes »

nickbauman wrote: post #18
mikeash wrote: post #12

Earlier quoted context omitted.

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.

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.

Re: Should I use a Swift struct or a class?

#44

Post by WoodenChair »

ezy wrote: post #31
ajg360 wrote: post #29

Earlier quoted context omitted.

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…

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.

Re: Should I use a Swift struct or a class?

#46

Post by mikeash »

gdubs wrote: post #25
mikeash wrote: post #7

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…

"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 fu…

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.

Re: Should I use a Swift struct or a class?

#47

Post by mikeash »

drewcrawford wrote: post #21
mikeash wrote: post #17

Earlier quoted context omitted.

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.

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 tha…

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?

Re: Should I use a Swift struct or a class?

#48

Post by mikeash »

yawaramin wrote: post #19
mikeash wrote: post #17

Earlier quoted context omitted.

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.

Re: Should I use a Swift struct or a class?

#49

Post by mikeash »

rubiquity wrote: post #22
mikeash wrote: post #7

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…

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.

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.

Re: Should I use a Swift struct or a class?

#50

Post by holyjaw »

RussianCow wrote: post #30
holyjaw wrote: post #27

Earlier quoted context omitted.

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 diff…

Nice example, thanks!
Post reply on HN