The way to achieve that is to have two function heads, one that matches on the struct and one that matches on the changeset. You can have the calculate logic in a separate private function and just extract the fields and put the result into whatever structure in each of the function heads.
And where are you going to get the other values for the calculation, if they’re not being passed as args? Passing required arguments to functions is not an antipattern 
As @D4no0 said, it really sounds like you are trying to create class-like code. The problem with the code you showed us is that it just doubles down on why you think you need access. The real question is: “Why do you need a function that works on both in the first place?” The reason people are questioning you is because there shouldn’t be any reason to need to manually update a key of a schema’s struct, all changes should be done through changesets.
No such thing! Changeset constructors can look however you need to them to. The fact that cast_assoc will automagically look for a changeset/2 function is just a convenience. I won’t name names (@dimitarvp 
) but some people think this in-of-itself is a mistake and the :with option should always be used. Which is just a lot of words to try and re-enforce my point.
This and put_assoc will haunt me to the end of the days. Nowadays I avoid them altogether for my mental health 
.
I used to feel this way! I definitely came around to them. I usually just use put_assoc for tenant-like relationships, or really just anything I don’t want the user to have control over changing, otherwise I just cast the ids directly. And I came to love cast_assoc for many types of nested relationships, but not all! But ya, we don’t have to get into this in this thread
I think one thing is missing from this discussion and that‘s the notion of violating DRY by having ways to calculate the computed value from various sources of data. Instead of trying to avoid repetition by limiting the number of inputs (only struct or only changeset) you can also keep both inputs, but delegate the business logic in question to a shared helper.
def with_computed(%Ecto.Changeset{} = cs) do
a = get_field(cs, :a)
b = get_field(cs, :b)
put_change(cs, :x, compute_x(a, b))
end
def with_computed(%Struct{} = struct) do
%{struct | x: compute_x(struct.a, struct.b)}
end
defp compute_x(a, b), do: a + b
You are overthinking this, like a lot. As others have pointed out, have a private function that does the calculation and then only work with a Changeset that calls it. You don’t want the calculation being directly applied to the struct when you have Ecto in the picture; the Changeset is the perfect way of, a-hem, accumulating sets of changes before putting them in the DB.
Not sure where your analysis paralysis comes from but it’s likely that you are used to doing this in a very different way and trying to shoehorn it in Elixir. It can be a struggle to reshape some neural pathways, admittedly, but you should give our way a chance.
Just to drive the point harder, I would say even if you aren’t going to persist you still want to change through a changeset!
@7rans, think of changesets as ActiveRecord’s validations along with its instance methods+callbacks (validations just being another form of callback, of course). What you’re proposing is roughly the equivalent of calling model_instance.instance_variable_set from a controller. It’s not an exact mental mapping but not too far off! So just as you have a public API for for assigning attributes in AR, changesets are Ecto’s version of that.
Thanks everyone for the input. Really helpful! Btw, this also helps answer a prior question I had too.
(I still think there is something to be said for the Changeset being interchangeable with the Struct, but at this point I think that’s a larger question for another time.)
So to sum up, the answer is to work with the changeset. If you need to work with the struct too, then extract out the manipulating code to shared functions and have two interface functions that call on those.