Add the only(f, x) method, which allows users to provide a default value or customize the error message

[DilumAluthge]

Closes #43729

[simeonschaub]

I don't think that's what we decided on. I'm pretty sure we said this should behave mostly like get, meaning only(f, x) just returns f() if x doesn't have exactly one element. You can still throw from inside f, but it would support lots of other uses as well.

[tkf]

Yes, we should just call f. It's almost like the CPS approach I discussed in #43773 (reply in thread) which I think let us write more efficient and composable programs.

Also, as discussed in #43491, I strongly believe we should stop introducing ::Function and ::Callable in the public API call signature.

[simeonschaub]

Any reason to name this getonly? I don't think we have any two-arg methods for only yet, so keeping the name should be fine

[DilumAluthge]

Any reason to name this getonly? I don't think we have any two-arg methods for only yet, so keeping the name should be fine

Yeah, it was an intentional change. When I'm back at my computer, I'll write up my motivation for changing the name.

[DilumAluthge]

I have removed the restriction that f be a Function. f can now be of any type.

[simeonschaub]

Yeah, it was an intentional change. When I'm back at my computer, I'll write up my motivation for changing the name.

So what was the motivation?

[DilumAluthge]

Whoops I completely forgot to reply.

So, my thinking here is that the semantics of this new method seem sufficiently different from the semantics of the original only function. The original only function essentially had this contract: if the input collection does not have exactly one element, throw an exception. This new function doesn't promise the same behavior.

For example, we currently have getindex(collection, key). If the collection does not have the matching key, then it throws an error. If you want a function that lets you not throw an error if the key does not exist, you don't use getindex, because that's not the purpose of the getindex function. Instead, you use either get(collection, key, default) or get(collection, key) do ... end.

So I would say that getindex versus get is the same dichotomy as we have in only versus getonly in this PR. The semantics of getindex versus get are different, so we have two different functions. Similarly, I believe that the semantics of only versus getonly are different enough that they should not be the same generic function.

[simeonschaub]

It just seems weird to me to have two functions only and getonly since it's impossible to guess how they differ from just their names. getindex vs get is different since getindex allows a variable number of arguments, so we can't define separate methods for it that take a function used to get the default argument without running into ambiguities.

[ericphanson]

Maybe one can think about it like pop!. If there’s no key and you provide a default, it’s used, otherwise there’s an error. Likewise here, if you provide a function then it’s used when there’s not exactly 1 element, otherwise you get an error.

[tkf]

FWIW, if we really want to derive composable and efficient error/"missing value" handling from a first principle, I believe CPS approach #43773 (reply in thread) I mentioned above is very attractive. For example, maybe it can be done by implementing Base.CPS.only and deriving Base.only from it ¹. If we have a mechanical approach like this to solve the generic issue, we don't really need to discuss function name case-by-case basis and remember the relationships between individual functions or between different signatures/arities. We would then be able to write a combinator like

otherwise(only, x) do _
    f()
end

for arbitrary Base.CPS-compatible functions.

Footnotes

1. only is special since getonly in this PR is isomorphic to Base.CPS.only because of Iterators.map. But I think having different (qualified) names help in general. ↩

[DilumAluthge]

That sounds like a much better approach to me, instead of having to do this manually for each function of interest.

Want to make a PR showing what the implementation of Base.CPS.only would look like? As well as how Base.only would be defined in terms of Base.CPS.only?

[tkf]

I guess I can make a quick PR but it's almost surely going to cause discussion (for good reasons!) over months (or even years) so if you want to have it in the next minor bump, the best option is to ignore me 😉

So, I think the first step is to get triage's approval for #43773. But I'm not sure if we have arrived at a set of concrete decision points. For example, I don't think we have properly listed downsides of CPS (e.g., it's tedious and maybe too "infectious" to pass around continuation/effect manually; it's error-prone to enforce the return-as-is invariance manually; other languages go towards more implicit effect system and doing this manually may be too archaic in 2022).

Until then, to avoid bitrotting PR, I think I'll be playing it within a package. I've been wanting to look into CPS in https://github.com/tkf/Try.jl.

[DilumAluthge]

I'm in no rush to get this in. I'd rather we come up with a general solution, then we can apply that to other functions (first, last, etc.) instead of having to manually add methods for each function of interest.

[tkf]

I'm suggesting using Union{Ok,Err}-valued functions for this. See #45080