"Sins of the father." - I prefer consistency to having `take` return two
different result types.

I think that `Enum.one\2` is a much better idea. I expect the second
argument to default to nil and allow a default to be passed in.

There is a difference between verbose and explicit. Ruby's each is still
explicit, but doesn't include the verbosity of a C for loop. I think
abstractions are fine, and we should consider each one carefully. We need
to think about their uses and if it should be in the core, an external
library, or the code using it. Anything that makes it into the core must be
maintained in the core. In thinking through this like the explicitness of
the name, but it doesn't buy much more than utilizing `Enum.take\2`.

Amos King
Owner
Binary Noggin
http://binarynoggin.com #business
http://thisagilelife.com #podcast

=======================================================
I welcome VSRE emails. Learn more at http://vsre.info/
=======================================================


On Tue, Apr 25, 2017 at 4:06 PM, Sam Davies <[email protected]> wrote:

> I like `Enum.one/1`. Agree that it's confusing to have `take/1` return a
> single element and `take/2` returning a list, although Rails' `take` works
> like this.
>
> If the collection is empty it returns nil naturally. A bang and non-bang
> version could work, this would make it work like Ecto's `one/2` function.
> <https://hexdocs.pm/ecto/Ecto.Repo.html#c:one/2>
>
> As for keeping things explicit, if we wanted to be explicit we'd still be
> writing for loops in C ;). I like abstractions and a rich set of functions
> in the standard library, where it makes sense and doesn't duplicate
> functionality.
>
>
> On Sunday, April 23, 2017 at 5:23:38 PM UTC+1, Matt Jadczak wrote:
>>
>> I don't think this is needed, but as far as naming suggestions go,
>> perhaps `Enum.one/1` would work, as it both indicates that a single element
>> is returned, and doesn't necessarily imply ordering like `first` would.
>> However, what happens when the Enum is empty? Do we need a bang and
>> non-bang version? As others have said, I think that keeping this explicit
>> is nicer. You can always add a private helper or a function to a
>> project-level utility module if you use this often.
>>
>> On Saturday, 22 April 2017 18:49:10 UTC+1, Myron Marston wrote:
>>>
>>> I don't think this would improve Elixir.  Elixir favors explicitness
>>> over implicitness and fewer keystrokes and the only argument for this seems
>>> to be convenience.
>>>
>>> More worrying, `Enum.take/2` returns a list of items.  If there was an
>>> `Enum.take/1`, I'd expect it to simply default the number of items taken,
>>> but to still return a list (even if it's just a list of one item).  But
>>> from this thread it sounds like you're wanting an `Enum.take/1` that
>>> returns just the first item without it being wrapped in a list.  IMO, that
>>> would be incredibly confusing.  It would lead to different behavior for
>>> `&Enum.take/1` and `&Enum.take(&1, 1)` which would be very
>>> counter-intuitive.
>>>
>>> Myron
>>>
>>> On Saturday, April 22, 2017 at 7:10:27 AM UTC-7, Amos King wrote:
>>>>
>>>> You want to add a default of 1 to Enum.take/2? I personally don't mind
>>>> that but I think it takes away from the explicit nature of the module. I
>>>> prefer explicitness if we are only saving a few keystrokes.
>>>>
>>>> Amos King
>>>> Binary Noggin
>>>>
>>>> On Apr 22, 2017, at 04:12, Sam Davies <[email protected]> wrote:
>>>>
>>>> I understand the reasoning. That's why I suggest the name `take` NOT
>>>> the name `first` to make it clear there is no implied ordering.
>>>>
>>>> The use case for this is often while working in IEx. I have a
>>>> collection of _somethings_ and I want to see what one _something_looks
>>>> like. I don't care about ordering.
>>>>
>>>> Rails' ActiveRecord has a method called `take` which does much the same
>>>> thing - there is no implied ordering, it just grabs a member using some
>>>> unspecified ordering and returns it.
>>>>
>>>> We already have `take/1` which returns the "first" X elements, so it
>>>> seems logical to me to extend that to `take/0` which returns the "first"
>>>> ONE element.
>>>>
>>>> On Thursday, April 20, 2017 at 5:55:22 PM UTC+1, Allen Madsen wrote:
>>>>>
>>>>> Also hd, which takes the head of the list.
>>>>>
>>>>> Allen Madsen
>>>>> http://www.allenmadsen.com
>>>>>
>>>>> On Thu, Apr 20, 2017 at 12:44 PM, OvermindDL1 <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Two things:
>>>>>> 1. The `List` module already has a `List.first/1`.
>>>>>> 2. Not all enumerables have a concept of ordering, like a map, so I'm
>>>>>> not sure an Enum version of such a thing makes conceptual sense?
>>>>>>
>>>>>> On Thursday, April 20, 2017 at 10:33:11 AM UTC-6, Sam Davies wrote:
>>>>>>>
>>>>>>> When working with collections it's often convenient to grab the
>>>>>>> first element that comes to hand. I find myself writing this a lot:
>>>>>>>
>>>>>>> `Enum.take(collection, 1)` or `Enum.at(collection, 0)`
>>>>>>>
>>>>>>> How about a function `Enum.take/1` which takes only the collection
>>>>>>> and returns the "first" value (I avoid naming it `Enum.first/1` since 
>>>>>>> some
>>>>>>> collections may not have any concept of ordering).
>>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "elixir-lang-core" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/69a0953e-
>>>>>> 07b3-4cc6-8cc0-bee718337ea5%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/69a0953e-07b3-4cc6-8cc0-bee718337ea5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/elixir-lang-core/bd395d6b-e64d-41ef-970e-8ac33c0e279c%
>>>> 40googlegroups.com
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/bd395d6b-e64d-41ef-970e-8ac33c0e279c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/elixir-lang-core/9123abef-0f2a-47a8-8e93-
> 69626f9515b2%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/9123abef-0f2a-47a8-8e93-69626f9515b2%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAJr6D4Qnoi7OrNB%2BjNXY7COtPPEiP481vWo6eSrjuFDHrSqi0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to