# Searchsortedfirst and searchsortedlast
**URL:** https://discourse.julialang.org/t/searchsortedfirst-and-searchsortedlast/7084
**Category:** General Usage
**Created:** [November 15, 2017, 9:03am UTC](https://discourse.julialang.org/t/searchsortedfirst-and-searchsortedlast/7084 "2017-11-15T09:03:37Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@mottodora](https://discourse.julialang.org/u/mottodora)
#### Post date: [November 15, 2017, 9:03am UTC](https://discourse.julialang.org/t/searchsortedfirst-and-searchsortedlast/7084/1 "2017-11-15T09:03:37Z")
lt(less than) function argument order of searchsortedfirst is different from that of searchsortedlast.
Is this specification?
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [November 15, 2017, 9:06am UTC](https://discourse.julialang.org/t/searchsortedfirst-and-searchsortedlast/7084/2 "2017-11-15T09:06:42Z")
These are actually keyword arguments, so their order does not matter. But you’re right that it would be more consistent to use the same order everywhere. And the docstrings should be fixed to use `;` to separate positional arguments from keyword arguments (and stop using brackets).
A pull request to fix this would be welcome, but this API is going to be redesigned soon anyway. See [this issue](https://github.com/JuliaLang/julia/issues/10593) and [this Julep](https://github.com/JuliaLang/Juleps/blob/master/Find.md).
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [November 15, 2017, 12:45pm UTC](https://discourse.julialang.org/t/searchsortedfirst-and-searchsortedlast/7084/3 "2017-11-15T12:45:26Z")
That Julep is missing `searchsorted`.
The tables are also missing one of the possible return values, `length(vec)+1`, for `searchsortedfirst`, when the value is greater than all of the values in `vec`
A few things that would be very useful for the `searchsorted*` (that I ended up having to make my own sorted search functions for), is functions optimized for sorted _unique_ vectors, that can both return an insertion point and an indication of whether the value was found, and a `searchsortedeq` function (basically `in`, but with the knowledge that the vector is both sorted and has no duplicates).
Another thing is to expose (and document) the ability to pass in the beginning and ending indices for the search,
and have the final argument have a default in that case (now it doesn’t, it requires the final argument that combines the keyword arguments together if you want to pass in the lo and hi args)
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [November 15, 2017, 1:02pm UTC](https://discourse.julialang.org/t/searchsortedfirst-and-searchsortedlast/7084/4 "2017-11-15T13:02:14Z")
The `searchsorted*` functions are mentioned under “Particular cases”.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [November 15, 2017, 1:10pm UTC](https://discourse.julialang.org/t/searchsortedfirst-and-searchsortedlast/7084/5 "2017-11-15T13:10:32Z")
Yes, but the section: `Dimensions of Variation` needs those two extra cases, i.e. the mode of operation (return a range, which is possibly an empty insertion point), and the return when not found (return `length(vec)+1`).
Note the inconsistency (which I’d stumbled over early on) between `searchsortedfirst` and `findfirst` when not found.
It will be very nice to have these functions handled in a cleaner and more consistent fashion!