My first intuition would be to call this copy_with, as I think it reads better. I really like the idea though, I used groovy's copyWith a fair bit.

Please allow the rest of the team to weigh in on the design before making any changes though. Right now, the formatter is failing (please use make crystal followed by bin/crystal format to format your PR)

I could live with copy_with, but how about update?

IMO, update carries a notion of mutability, or is ambiguous. copy is a bit more explicit; regardless of whether the receiver is mutable or not, you understand a copy is being made.

The primary contract for this method is not copying though, it's creating a new instance with some values changed. For copying we have dup and clone already. I would tend to argue that the copy is "just" a (necessary) side effect of changing values on an immutable object.

update's heritage would be Hash#update.

Scala calls such a method as clone. I misunderstood, copy is correct.

I'm happy with update. clone implies there's nothing actually modified about the clone, same with copy.

We don't even need dup, because a record is a struct; just b = a; b.y = 9 copies the record and updates a field.

Honestly, I don't see the benefit of a copy with some new values in a mutable, non functional language.

Furthermore, why should the feature be restricted to record? What about structs and classes ?

@ysbaddaden with the difference that record defines attributes as getters, thus making it immutable.

Yes, this is exactly the point. Records are immutable objects and this is a nice and clean abstraction for "mutating" them.

Records are just structs (sugar definition), they can have methods that mutate instance variables; they're not immutable.

@ysbaddaden but by default they are immutable. People typically use them as immutable, or they would just define a struct with property macros, as it's shorter than a record when it's mutable.

Please consider the typical usecase.

What I'm saying is that nothing is immutable in Crystal, and that records are just sugar for defining pseudo-immutable structs. Crystal doesn't know about them being records, hence doesn't treat records differently than structs, and documents them as structs, because this is what they really are. Shall we specialize records under these conditions?

If we add that one method only, I guess it's okayish and fits into the concept, but it's one step that makes it harder to change a record into a struct —because someone may rely on the copy method, even thought the concept doesn't stand anymore (or never did).

BTW: #update is confusing (feels like it's mutating the object), better keep #copy or specialize #dup to accept arguments, which would fit better and avoid adding a new concept.

@ysbaddaden sure it doesn't enforce immutability per-se but it means you have to go out of your way to mutate the struct in-place.

Regarding the substitutability of a record and a struct with getters, that's a really good point. Perhaps it would be possible to add a def_copy_with method which would work on any class or struct (as long as it has the right ctor which accepts named arguments for all ivars).

Have formatted the code. About the naming, I couldn't find many other functional languages that have a named method for this:
groovy: copyWith
kotlin, scala: copy
elm, haskell, erlang, elixir: don't have a function, it's done with syntactic sugar though the process is generally referred to as "update"
My personal favourite is still copy.

Personally I'd favor to instead create a dup that takes an argument, ie record.dup(y: 4). Easier to remember, and doesn't really create any ambigousness that I can see.

So is that a consensus that this should be called dup then? Would be happy to make the change to get this merged. I still think this is a useful feature and have wanted to use it in code.

I don't think it should be called dup. Maybe dup_with... Even then I prefer copy_with. I don't care too much though, as long as it's in I'll bear the naming.

Why not just call it with? It's short and precise. I don't think it necessarily needs a verb.

point = Point.new(3, 4, 5)
point.with(y: 9)

copy_with would be okay as well, but longer.

I've renamed it to copy_with and rebased. Anything else I can do to get this merged?

Apart from the docs, it's a big +1 from me

Ok, I've updated the docs

I still think merge should be the name of the method. If we don't then named tuples and records will have different api.

Changing a variable from NamedTuple(x: Int32, y: Int32) to a record(x: Int32, y: Int32) will requiere extra changes.

Yes, they do have a different API since reader are different tuple[:foo] vs record.foo. That difference is to capture which properties exists or not. Maybe it could go away, or not. But making merge and copy_with different is an unnecessary IMO. And is also consistent with Hash#merge.

The fact that a merge in tuple can return a tuple with more components and that the merge in records prevents extra properties does not change that the operation is merging self with subset.

I completely disagree. Named tuples and records's APIs are different because they're two different data structures: one is an immutable Hash, and the other is an immutable OO struct with it's own class and can be inherited and have methods. Working to make the APIs the same makes no sense: you can restrict for NamedTuple and be sure whatever you're operating on has an update because it's a named tuple, but no such type restriction exists for "all records". You'll never be operating on "all records" the same way you can write a method that operates on all named tuples. That's because a named tuple is a collection, and a record is not, it's just a plain class.

These classes and usecases are so different that making the APIs the same doesn't make sense. If you want to do that, lets have that discussion in another PR.

And thinking about it more, this PR is the first instance of record adding any API which is specific to records. Records don't have an API because they're just a shortcut for defining a struct.

So we should add a includeable module that adds copy_with for any class or struct, and then use that in record, to avoid giving records any special API.

@RX14 I generally agree.

Records don't have an API

I'd consider the constructor receiving named arguments a API method specific to records. And copy_with is just a variant of that: It creates a new instance with self's properties as defaults.

We could certainly discuss a generalized copy_with, but I'm not sure how that's supposed to work as a re-usable module method, because the implementation is very specific to record and only works with it's special constructor.

But, I'd rather just merge this PR as is, adding `copy_with´ to the record macro. Then we can talk how this could be fit in a re-usable module.