Hello Ilija and Larry, You both touch upon some interesting and similar thoughts, and it may be worth sharing how I arrived here; at least so we have some shared context:
Personally, I feel that classes are quite bloated with features and what feature works with what is quite confusing for new developers; I would rather see features removed than added to them at this point. This isn't why I chose the "record" keyword or a new syntax, to be clear. However, it was one of many strong reasons as to why I felt it would be an ok deviation from "tacking on more features to classes." One of the main reasons for the alternative creation syntax is because I felt that "new" was misleading at best, and just plain wrong at worst. It is also why I chose "&", to make it clear you are not getting "a new one" but one that "just happens to exist with the values you asked for." I'd be open to a different keyword or something else entirely. It's just that "new" is the wrong one for records. I did explore "data classes" to a degree, and I can see why Ilija created the new "mutating" syntax for their RFC. It gets really weird, really fast. Records are the other side of structs, though. They are (nearly literally) arrays with a class entry on them, and thus, essentially, typed structured arrays with behavior. In fact, I was originally going to pitch it as such, but decided it would either stand on its own or not; but it is what they were designed to be from the beginning; hence the short declaration syntax. In other words, I see this being used anywhere you'd normally use a structured array but want some type safety, without all the boilerplate of classes or dealing with equality. For example, DTO's, configuration, etc. They solve a different problem than Ilija's structs, which makes more sense for collections, but I see records as being good candidates for values in those collections. As I shopped this RFC around to coworkers, old coworkers, other maintainers on the projects I work on, and (nearly) random strangers on the internet, it became clear that people liked it and understood them, but wanted more power. Things like better custom (de)serialization than what we have with readonly classes, custom initializers for computed properties, etc. Furthermore, as I thought about these new features for records, I also thought about how people would use them. They would most likely start with a simple record (or not), but when changing them, I also thought about the diffs they would create in code reviews. In fact, this is a large reason behind the rules for traditional constructors. Adding a traditional constructor to an already existing record should look exactly like that in the diff, without shifting around a bunch of properties. Eventually, we ended up with the RFC you are reading today. (To be 100% transparent, some people also thought it was pointless and wondered what was wrong with readonly classes, but I'll come back to that). Now, with that context in mind... On Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote: > Plus, having another fixed type creates questions any time a new feature is > added. I think this would happen even if I scoped out some of the RFCs you hinted at. I don't think there is any way around this. Adding new features complicates future features, and it doesn't matter where you put them. Or rather, it matters, but not as much as you'd think. For example, my nameof RFC is basically on hiatus until we have pattern matching. We simply lack the grammar necessary to do it correctly, and it doesn't seem like the place to define that grammar because then it may pigeonhole pattern matching. I think that is fine, but these are normal things to go through when working on an RFC, in my limited experience. My point is, we constantly have to make this decision process, and we just have to 'figure it out' as we go. On Sun, Nov 17, 2024, at 01:15, Ilija Tovilo wrote: > I personally do not think immutable data structures are a good > solution to the problem, and I don't feel like we need another, > slightly shorter way to do the same thing. On Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote: > As Ilija notes, immutable objects are not always the answer. I like them, > and use them frequently, but they're not always appropriate. And we already > have them with either readonly classes or now private(set) (which is close > enough to immutable 99.4% of the time) To be clear, this is another tool in the developer's toolbox and not meant to replace classes (even readonly classes). They are strictly immutable value objects, which makes sense for numbers, time, custom values (see: the UserId example in the RFC), etc. These aren't as good for generic collections like maps, sets, vectors, etc. or even things like services or controllers. For these types of things, classes (or structs) make more sense. Like Ilija mentioned in their email, there are significant performance optimizations to be had here that are simply not possible using regular (readonly) classes. I didn't go into detail as to how it works because it feels like an implementation detail, but I will spend some time distilling this and its consequences, into the RFC, over the coming days. As a simple illustration, there can be significant memory usage improvements: 100,000 arrays: https://3v4l.org/Z4CcV 100,000 readonly classes: https://3v4l.org/1vhNp and what we would expect from records: https://3v4l.org/4nYXG which is on par with the array example. Naturally, real life won't see that kind of reduction in memory consumption (nobody is creating an array of all the same items, most of the time), but hopefully it gives you an idea of what can be gained. On Sun, Nov 17, 2024, at 08:21, Larry Garfield wrote: > I can see the benefit of an inline constructor. Kotlin has something > similar. But I can see the benefit of it for all classes, even service > classes, not just records. (In Kotlin, it's used for service classes all the > time.) I think this would be a good future scope. If people like it, an RFC to extend it to regular classes makes sense. > There's already been an RFC for clone-with that works on any object; it just > never made it to a vote. I could see an argument for an even more dedicated > syntax (eg, eliminate "clone" and just do "$foo with (bar: 'baz')"), but > again, useful on all objects, not just records. I feel like this is similar to my nameof RFC and doomed from the start. Classes are just too featureful to pin down what a "with" actually means. The discussion went into depth on this, and nothing definitive came out of it (IMHO). In a sense, records get a "fresh start" and can define exactly what it means and how it can be used. > The alternate creation syntax... OK, this one I can't really see a benefit > to, and Ilija already noted it may cause conflicts. And from Ilija: > A small note: The $test = &Test(); syntax is ambiguous, as it's > already legal. https://3v4l.org/CE5rt I originally had something about this in the RFC but removed it at the last minute. I'll add it back! For now, it will live in "open issues" in case someone has a better idea. As to the reason for it, I covered it briefly above, but as a reminder, it boils down to my reluctance to use "new" to get a record. If anyone has any better ideas, I'm open to it. And again, from Larry: > Value-based strong equality, in cases where I want that, I also want to be > able to control it. That goes back to Jordan's operator overload RFC, and > specifying a custom == and <=>. I'd rather just have that. I originally wanted to add operators. For (I hope) obvious reasons, I decided to just wait for them. I think something like records (with value semantics built-in) would be much more palatable for people worried about the "abuse" of operators. I'm just going to steer clear of that topic and leave it "undefined" for now--with the expectation that someone (Jordan?) may come along to define operations on objects. > Value-style passing is the really interesting one, but I want to be able to > use it without being forced into all of the other features here. I don't think there is much way around it. You either need a special syntax (structs) or immutability (records). For regular classes, there is always "==" if you have control over how they are compared. Sadly, I don't think this is possible for regular classes, but I could be wrong. And... that's a book. I'm really sorry about the length of this email, but hopefully I've addressed both your questions and concerns as best I can. Sincerely, — Rob
