# Function to check all arguments are the same and return their value

**URL:** <https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253>\
**Category:** Internals & Design\
**Tags:** proposal\
**Created:** [February 27, 2019, 8:01am UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253 "2019-02-27T08:01:42Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![mfsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mfsch/32/7242_2.png) [@mfsch](https://discourse.julialang.org/u/mfsch)\
**Post date:** [February 27, 2019, 8:01am UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/1 "2019-02-27T08:01:42Z")

</div>

I’ve observed that I often encounter this pattern where I have several ways of getting a value I need that should be equivalent. The most typical case is getting some array dimension.

```julia
function f(data, x, y, z)
    nx = length(x)
    size(data, 1) == nx || error("Dimensions must match")
    ...
end

```

In these cases it would be nice to have a small function in Base that does this in one step:

```julia
    nx = same(size(data, 1), length(x))

```

It’s just a small papercut and I don’t know if it would be something worth considering, but for me it would make the language just a bit more comfortable to use since I end up writing code as above in many of my functions. It would reduce the mental overhead of picking one value for the assignment (vs the other ones for the assertion) and encourage checking for consistency since it can be done in one statement rather than two.

It would be especially useful in cases where you want to use a value directly without assigning it to a variable first, but have several ways of getting it that should be equivalent, e.g.:

```julia
for i=1:same(size(data, 1), length(x))
   ...

```

It would also be somewhat analogous to type parameters where these sort of consistency checks can be done implicitly by using the same parameter name for multiple types.

I know I can easily write this function myself, but I probably wouldn’t add it to most code since it’s such a small improvement. I would, however, use it all the time if it was in Base. A possible complication is when the arguments are of a different type (as in `same(1, 1.0)`) – maybe it would have to promote the values first?

Any thoughts?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 27, 2019, 8:16am UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/2 "2019-02-27T08:16:32Z")

</div>

`LinearAlgebra.checksquare` implements a very special case of this pattern, namely

1. get various attributes of objects,
2. check that they are equivalent/conformable,
3. return the one that is relevant for further use.

I am in two minds about this approach: it does make code shorter, but it conflates calculations with checking. There are suggestions for disabling `@assert` and similar with runtime flags and I am not sure they would interact well. I also like the informative error messages from eg `ArgCheck.@argcheck`.

---

<div class="post-metadata">

**Author:** ![bennedich](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bennedich/32/4894_2.png) [@bennedich](https://discourse.julialang.org/u/bennedich)\
**Post date:** [February 27, 2019, 8:43am UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/3 "2019-02-27T08:43:40Z")

</div>

I think this can be quite useful, to reduce the clutter and verbosity of repeatedly verifying arguments. But I wonder if it doesn’t better belong in one’s own project? The reason is that I’ve often used constructs like this myself, and I find that they tend to be quite problem-specific: I want to specify the error message, I usually want to include what the compared values actually are in the error message, and I want to throw a specific type of Exception (e.g. `DimensionMismatch`), not just generic `error`. And what should `same` return, the first or second argument? Just because they’re equal doesn’t mean it’s the same object.

Is it really such a burden to add it to your code? In it’s simplest form, it’d just be a one-liner:

```julia
verify_equal(a,b) = a == b ? a : error("dimension mismatch")

```

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 27, 2019, 1:26pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/4 "2019-02-27T13:26:37Z")

</div>

I like the idea—it is a really common pattern.

---

<div class="post-metadata">

**Author:** ![mfsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mfsch/32/7242_2.png) [@mfsch](https://discourse.julialang.org/u/mfsch)\
**Post date:** [February 27, 2019, 4:12pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/5 "2019-02-27T16:12:27Z")

</div>

I agree that introducing a version of this function to Base only makes sense if there’s a sufficiently general version that makes sense for most use cases. I’m not sure that’s the case, for example with regards to which of the arguments should be returned. Maybe the equality check should be strict enough that it doesn’t matter?

However, I do think it’s a big difference whether a function is part of Base or not. Defining your own functions always has some overhead. You have to think about whether it’s worth it, you have to think about the naming, you have to think about what sort of equality you want to enforce… Defining a lot of little functions can make it hard for others to follow your code because they have to look up all those definitions too when reading the code. I therefore try to stick to “vanilla” Julia whenever possible. I also tend to write a lot of prototypes in Jupyter notebooks when writing new code, so I’d end up redefining these functions over and over again (or more realistically: just not using them at all).

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 27, 2019, 4:25pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/6 "2019-02-27T16:25:16Z")

</div>

> [@mfsch](#):
>
> Defining your own functions always has some overhead. You have to think about whether it’s worth it, you have to think about the naming, you have to think about what sort of equality you want to enforce…

But if you put it in a package, all this overhead is a fixed cost.

> [@mfsch](#):
>
> I therefore try to stick to “vanilla” Julia whenever possible

If you mean `Base` + standard libraries, you may be missing quite a bit of functionality.

Having no (performance or syntactic) overhead for user-defined functions was a key design principle in Julia from the very beginning. The language is intended to be extended, and makes this very, very convenient.

The best way to develop something like `same` is to

1. put it in your projects as @bennedich suggested,
2. if you find repeating patterns, wrap it up in a package with unit tests, document, and release,
3. polish it based on user feedback if necessary.

---

<div class="post-metadata">

**Author:** ![mfsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mfsch/32/7242_2.png) [@mfsch](https://discourse.julialang.org/u/mfsch)\
**Post date:** [February 27, 2019, 5:40pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/7 "2019-02-27T17:40:46Z")

</div>

Well, I see the question of when to extract common pieces of functionality into functions within your project, shared packages, and functionality that is part of the language as one of the hard design problems of programming. Every time you extract functionality this way, you also add a layer of abstraction/indirection – sometimes that’s worth it, sometimes it isn’t. I love the power of Julia functions and packages, and I use both a lot, but for something small like this I think the benefit of using Base-only functionality familiar to everyone looking at the code is greater than the cost so I would stick to the more verbose code I’m using currently.

It’s similar to functions like `all` and `any` – they are pretty much just wrappers performing a reduction, but they make the code more clear and I like that they’re part of Base.

---

<div class="post-metadata">

**Author:** ![bennedich](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bennedich/32/4894_2.png) [@bennedich](https://discourse.julialang.org/u/bennedich)\
**Post date:** [February 27, 2019, 6:20pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/8 "2019-02-27T18:20:05Z")

</div>

> [@mfsch](#):
>
> Defining your own functions always has some overhead. You have to think about whether it’s worth it, you have to think about the naming, you have to think about what sort of equality you want to enforce… Defining a lot of little functions can make it hard for others to follow your code because they have to look up all those definitions too when reading the code. I therefore try to stick to “vanilla” Julia whenever possible.

I don’t understand this perspective at all. I consider extracting functionality into separate functions one of the cornerstones of good coding style, making it _easier_ to follow your code since the function is given a descriptive enough name that readers hopefully don’t feel the need to inspect the source code, and the surrounding code then becomes more concise and focused on its task. And you also open up for code reuse and unit testing of individual functionality.

(Note: I consider choosing descriptive names very important to achieve self-documenting code. Don’t worry so much about the length of the function name. In your example I would go with something like `verify_equal` or `assert_equal` instead of `same`. IMO `same` is even misleading here if you use `==` and not `===` to check for equality.)

---

<div class="post-metadata">

**Author:** ![mfsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mfsch/32/7242_2.png) [@mfsch](https://discourse.julialang.org/u/mfsch)\
**Post date:** [February 27, 2019, 7:45pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/9 "2019-02-27T19:45:44Z")

</div>

I didn’t mean to imply that functions (even short ones) should be avoided, it’s just my experience that every abstraction comes with a cost that may or may not be worth it. I see good coding style not as a set of fixed principles but as good intuitions about which principle should be followed to which degree. Every “best practice” (comments, extracting common functionality, unit testing, descriptive variable/function names) can become counterproductive if overdone. In the case of a function like `same` (or `all` and `any`) I think I prefer the style of not defining your own function if it’s not part of the language but I think either way is fine.

I agree that `same` is not a great name, I just couldn’t think of a better one. I don’t think `verify_equal` is that great either, because it places a lot of focus on the comparison and I would rather place the focus on the value that is returned. I wish there was a good short word that means “any one of these because it shouldn’t matter which one, they are all the same”.

For assignments, my ideal syntax would probably be `nx = size(data, 3) = length(x)`, which is similar to mathematical notation, but that would be too big of a change of the language for such a small feature (and probably impossible anyway).

---

<div class="post-metadata">

**Author:** ![mfsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mfsch/32/7242_2.png) [@mfsch](https://discourse.julialang.org/u/mfsch)\
**Post date:** [February 27, 2019, 7:55pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/10 "2019-02-27T19:55:13Z")

</div>

> [@bennedich](#):
>
> IMO `same` is even misleading here if you use `==` and not `===` to check for equality.

Oh, and you’re right, it should be `===` for the comparison in every case I can think of. That should also remove the ambiguity of which argument should be returned.

So the function would be something like this (possibly with a better name and a better error):

```julia
same(x, xs...) = all(map(xi -> xi === x, xs)) ? x : error()

```

Another use case that I would use this for is when a function takes two composite types as argument that both have a field that should be the same and I access this field, something like `same(a.grid, b.grid).dx`.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 28, 2019, 8:58am UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/11 "2019-02-28T08:58:41Z")

</div>

> [@mfsch](#):
>
> every abstraction comes with a cost that may or may not be worth it

This is an unusual point of view; as @bennedich said, abstractions are introduced precisely to economize on mental costs, by hiding the _implementation_ behind the _intent_. Eg `A \ b` is much, much easier to grok than understanding that a bunch of loops does LU and substitution.

Of course, as every other tool, they can be abused/overdone, and it takes time to build the experience to use them well.

---

<div class="post-metadata">

**Author:** ![jne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jne/32/6341_2.png) [@jne](https://discourse.julialang.org/u/jne)\
**Post date:** [March 15, 2019, 8:35pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/12 "2019-03-15T20:35:56Z")

</div>

@mfsch and @StefanKarpinski, perhaps the right Base naming you’re looking for is something that, rather than sounds like an equivalence check, _presumes_ equivalence:

> `nx = equivalently(size(data, 1), length(x))`

(taken from OP)

---

<div class="post-metadata">

**Author:** ![mfsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mfsch/32/7242_2.png) [@mfsch](https://discourse.julialang.org/u/mfsch)\
**Post date:** [March 15, 2019, 8:45pm UTC](https://discourse.julialang.org/t/function-to-check-all-arguments-are-the-same-and-return-their-value/21253/13 "2019-03-15T20:45:44Z")

</div>

I like that name! A short word would be nice, but it’s better to have it a bit longer and more clear I think.