On Wed, Oct 18, 2023 at 10:11 AM Brandon Jackson <brandonja...@gmail.com>
wrote:
>
> I get your desire to keep things simple, but IMO returning a value
> that does not conflict with possibly valid values or somehow indicates
> the value was not present is important, and should come before
> simplicity. Which likely means involving the key somehow.
>
The only portion in your email I disagree with is this ending. I believe
there are enough use-cases where if the first value is "valid null" or
"default null" it won't matter. The developer will treat them both the
same. Perhaps you disagree with this and want to avoid ambiguity at all
costs. My proposal to avoid ambiguity would be throwing an exception
instead of involving the key because involving the key can be a composition
between `array_first()`* and `array_key_first()`.
Although I would prefer the function to throw, I think it will have the
same effect as this key discussion: complicate something that can be
simple. If the developer needs to distinguish between "default null" and
"value null", they are able to do so by running `empty()` on the array
prior to asking for `array_first()`. It's actually better than a try/catch,
to be honest.
Ultimately, there's 2 parallel discussion that somewhat intertwine
themselves: Fibers ("async" code) and ambiguity ("value null" vs "default
null") and while there are options that may cater for both of them, there
are also options that cater only for each of them individually. Trying to
over-pollute a function as simple as `array_first()` to cater for these
edge cases is where I think the problem is because userland will always be
able to tackle these issues by wrapping the basic functionality provided by
core.
* If naming is an issue to you, I'd also be fine with
`array_value_first()`.
--
Marco Deleu
