Hello, Jose.
Thank you. :)
I was thinking about adding an Access.find!/1, but since there's no
equivalent Enum.find!/2 I stopped thinking about it. But yes, in deep
updates it might make more sense than in the Enum.find/2 case.
Best regards,
Oliver
On Wednesday, March 20, 2024 at 12:44:08 PM
Thank you. It seems the major objection was "waiting for a use case".
There is a question about: what happens if you try to update an element
that does not exist. But the behaviour in the PR mirrors `at`. We may want
to introduce `find!` in the future to mirror `at!` as well.
On Wed, Mar 20,
This is what I found:
>From the original PR: https://github.com/elixir-lang/elixir/pull/6634 (this
has a lengthy discussion on the merits).
The original discussion about including
both: https://groups.google.com/g/elixir-lang-core/c/LlZCz0iYgfc/m/5XLRvg8XAgAJ
(not very detailed, discussion
Can you please provide a link to the previous discussions? I recall dealing
with some complexities around finding and not finding elements as well.
Thanks!
On Wed, Mar 20, 2024 at 11:37 AM 'oliver@googlemail.com' via
elixir-lang-core wrote:
> Hello, okay I checked.
>
> Well, there was a
Right now I’m a bit drowning in work but IIRC there already was a proposal for
this, has anyone searched the mailing list?
On Wed, Mar 20, 2024, at 12:17 AM, Jean Klingler wrote:
> I like it. It would be to `Access.filter` what `Enum.find` is to
> `Enum.filter`.
> I think it would be a nice
Hello, okay I checked.
Well, there was a discussion 7 years ago when Access.filter/1 was
introduced but Access.find/1 was not.
Maybe opinions might have changed since then?
When going into the PR from back then I find the reasoning not very strong
on not merging Access.find/1 because "it
&(&1) ... sigh. In the project where I work I generally argue against
these constructs because it really reduces readability. There's a limit of
special character the brain can process correctly in a row. (My personal
opinion, though.)
In general, two constructs are more common in our code:
